[chore] tag releases automatically

[mdaniels5757]

This makes things easier for packagers :).

I did assume that you only want to publish by default when pushing to the default branch (now main). You can still trigger publishing from another branch by running the workflow manually. If I'm wrong, let me know and I'd be happy to change it back.

Summary by CodeRabbit

• Chores
  • Streamlined automated release pipeline to run on the main branch and via manual dispatch.
  • Added write permission for repository contents during the publish job.
  • Made publishing conditional so package publish only proceeds for the intended repository.
  • Added steps to extract the package version and create a GitHub release using that version.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[coderabbitai]

Note

Other AI code review bot(s) detected

CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

📝 Walkthrough

Walkthrough

GitHub Actions publish workflow updated: triggers set to push on main and workflow_dispatch; publish job granted contents: write. Workflow reads src/partial_json_parser/version.py to expose VERSION, conditionally runs PyPI publish and release steps only when repository is promplate/partial-json-parser (replacing the previous continue-on-error usage), and creates a GitHub release using GH_TOKEN and the extracted VERSION.

Changes

Cohort / File(s)

Summary

GitHub Actions workflow /.github/workflows/publish.yml

Replaced generic triggers with push on main and workflow_dispatch. Added permissions: contents: write to the publish job. Added step to extract VERSION from src/partial_json_parser/version.py and export it. Wrapped PyPI publish (and release) steps behind a repository-name conditional for promplate/partial-json-parser (removed continue-on-error: true). Added step to create a GitHub release using GH_TOKEN and the extracted VERSION, producing release notes from dist/*.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Verify the version extraction command matches the exact content/format of src/partial_json_parser/version.py.
• Confirm the repository-name conditional is correct (promplate/partial-json-parser) and applied to both PyPI publish and release steps.
• Validate permissions: contents: write and GH_TOKEN usage for release creation and that secrets/permissions align with organizational policies.
• Check any logic or environment variable propagation for publishing steps (e.g., VERSION export and usage).

Poem

A tiny workflow wakes on main,
It reads the version, speaks its name,
Guards the publish with repo truth,
Tags the release and shares the proof,
CI hums softly — build in frame.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title '[chore] tag releases automatically' clearly describes the main change: automating release tagging in the GitHub workflow.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 5f55179 and 0b215b6.

📒 Files selected for processing (1)

• .github/workflows/publish.yml (3 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• .github/workflows/publish.yml

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Sourcery review

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[CNSeniorious000]

Thanks @mdaniels5757! Just a few nits.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

.github/workflows/publish.yml (1)

10-25: Minor edge case with shallow git history.

Line 19 uses git diff --quiet HEAD~1 HEAD, which will fail if HEAD~1 doesn't exist (e.g., first commit or shallow clone). While fetch-depth: 2 mitigates this in normal circumstances, manual workflow_dispatch triggers on limited history could encounter this. Consider adding a guard, e.g., git rev-parse HEAD~1 >/dev/null 2>&1 && git diff --quiet HEAD~1 HEAD || echo "CHANGED=true".

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between c860319 and 2452de9.

📒 Files selected for processing (1)

• .github/workflows/publish.yml (3 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)

• GitHub Check: test (windows-latest, pypy3.11)
• GitHub Check: test (macos-latest, pypy3.10)
• GitHub Check: test (windows-latest, 3.11)
• GitHub Check: test (macos-latest, pypy3.11)
• GitHub Check: test (macos-latest, 3.7)
• GitHub Check: Sourcery review

🔇 Additional comments (2)

.github/workflows/publish.yml (2)

3-7: Trigger configuration looks good.

Listening for pushes to main and workflow_dispatch provides both automatic and manual release control, which aligns with the PR objectives.

---

44-61: Excellent resolution of past concerns.

The publish job now correctly:

• Removes continue-on-error so failed PyPI publishes halt the workflow (preventing orphaned releases)
• Uses the defined VERSION variable instead of undefined tag (line 59)
• Extracts version via grep instead of Python (line 50), matching the PDM backend convention
• Includes dist/* as release assets (line 61)
• Restricts PyPI publishing to the official repository (line 45)

All prior review feedback has been successfully incorporated.

[CNSeniorious000]

I will merge it later.