ci(release): auto-tag and publish when package.json version changes on main#27
Merged
Merged
Conversation
…n main Replaces the manual "tag v* triggers deploy" flow with one that fires on every push to main: a check-version job diffs package.json against HEAD~1 and skips the release entirely when the version is unchanged. When the version changes the deploy job builds, creates and pushes the matching v<version> tag, then publishes to the Chrome Web Store. Releases now need only a package.json bump in the merging PR — no separate tagging step. Tag creation runs before publish so a failed Chrome Web Store upload still leaves a release point on the repo, and the step short-circuits if the tag already exists so reruns are idempotent.
WalkthroughThe workflow deployment pipeline has been updated to create and push an annotated Git tag prior to publishing to the Chrome Web Store. The new step implements idempotent tag creation by first checking whether the tag already exists on the remote repository; if present, the step exits gracefully. If absent, the step configures the GitHub Actions bot Git identity, creates the annotated tag with the version string, and pushes it to the origin repository. The existing version-checking logic remains unchanged. Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/deploy.yml:
- Around line 14-16: Replace the current commit comparison that uses "HEAD~1"
when checking package.json.version with the push-base SHA from the event payload
(use ${{ github.event.before }}) and ensure the checkout step fetches sufficient
history (e.g., set fetch-depth to 0 or large enough) so the diff between the
pushed commits is accurate; update the checkout "uses: actions/checkout@v4"
block to fetch full history and change the version comparison logic that
references HEAD~1 to reference ${{ github.event.before }} wherever the
package.json.version comparison (the version check step) appears.
- Around line 72-75: The current tag existence check only verifies presence of
refs/tags/v$VERSION and can accept a tag that points to a different commit;
change the check to resolve the remote tag's commit hash (via git ls-remote for
refs/tags/v$VERSION), compare that hash to GITHUB_SHA, and if they differ emit a
clear error and exit non‑zero; if the tag does not exist continue to create it.
Use the variables/commands shown (VERSION, GITHUB_SHA, and git ls-remote --tags
origin "refs/tags/v$VERSION") to locate and implement the
hash-existence-and-equality check.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 731ecc8d-1037-43b2-8be5-7586832bec60
📒 Files selected for processing (1)
.github/workflows/deploy.yml
Comment on lines
+14
to
+16
| - uses: actions/checkout@v4 | ||
| with: | ||
| fetch-depth: 2 |
There was a problem hiding this comment.
Use push-base SHA instead of HEAD~1 for version comparison
Line 27 currently compares against HEAD~1, which can skip a valid release when a push contains multiple commits and only earlier commits changed package.json.version. Compare against ${{ github.event.before }} (and fetch sufficient history) so the check reflects the entire push delta.
Suggested patch
- uses: actions/checkout@v4
with:
- fetch-depth: 2
+ fetch-depth: 0
@@
- id: check
run: |
set -euo pipefail
current=$(jq -r .version package.json)
@@
- if previous=$(git show HEAD~1:package.json 2>/dev/null | jq -r .version 2>/dev/null); then
+ before_sha="${{ github.event.before }}"
+ if [ "$before_sha" = "0000000000000000000000000000000000000000" ]; then
+ previous=""
+ elif previous=$(git show "$before_sha:package.json" 2>/dev/null | jq -r .version 2>/dev/null); then
:
else
previous=""
fiAlso applies to: 27-37
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/deploy.yml around lines 14 - 16, Replace the current
commit comparison that uses "HEAD~1" when checking package.json.version with the
push-base SHA from the event payload (use ${{ github.event.before }}) and ensure
the checkout step fetches sufficient history (e.g., set fetch-depth to 0 or
large enough) so the diff between the pushed commits is accurate; update the
checkout "uses: actions/checkout@v4" block to fetch full history and change the
version comparison logic that references HEAD~1 to reference ${{
github.event.before }} wherever the package.json.version comparison (the version
check step) appears.
Comment on lines
+72
to
+75
| if git ls-remote --tags origin "refs/tags/v$VERSION" | grep -q .; then | ||
| echo "Tag v$VERSION already exists on origin; skipping tag creation." | ||
| exit 0 | ||
| fi |
There was a problem hiding this comment.
Fail if existing tag points to a different commit
At Line 72, existence-only checking can silently accept a mismatched v$VERSION tag and still publish artefacts from another commit. Verify the remote tag resolves to GITHUB_SHA; fail on mismatch.
Suggested patch
- if git ls-remote --tags origin "refs/tags/v$VERSION" | grep -q .; then
- echo "Tag v$VERSION already exists on origin; skipping tag creation."
- exit 0
- fi
+ remote_commit="$(git ls-remote --tags origin "refs/tags/v$VERSION^{}" | awk '{print $1}')"
+ if [ -n "$remote_commit" ]; then
+ if [ "$remote_commit" != "$GITHUB_SHA" ]; then
+ echo "::error::Tag v$VERSION exists on origin but points to $remote_commit (expected $GITHUB_SHA)."
+ exit 1
+ fi
+ echo "Tag v$VERSION already exists on origin for this commit; skipping tag creation."
+ exit 0
+ fi🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/deploy.yml around lines 72 - 75, The current tag existence
check only verifies presence of refs/tags/v$VERSION and can accept a tag that
points to a different commit; change the check to resolve the remote tag's
commit hash (via git ls-remote for refs/tags/v$VERSION), compare that hash to
GITHUB_SHA, and if they differ emit a clear error and exit non‑zero; if the tag
does not exist continue to create it. Use the variables/commands shown (VERSION,
GITHUB_SHA, and git ls-remote --tags origin "refs/tags/v$VERSION") to locate and
implement the hash-existence-and-equality check.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Replaces the "tag → deploy" flow with one that fires on every push to
main. The new pipeline diffspackage.json'sversionagainstHEAD~1; if it's unchanged, the deploy job is skipped, otherwise the deploy job builds, packages, creates and pushes the matchingv<version>tag, and publishes to the Chrome Web Store. Releasing now needs only apackage.jsonbump in the merging PR.v<version>already exists on origin, so re-running the workflow is idempotent.contents: write(the workflow default elsewhere is unchanged) so the bot can push the tag.Test plan
should-release=false, deploy job is skipped, no tag is pushed.package.jsonto1.5.2(or whatever is next) → tagv1.5.2is created automatically and the extension is uploaded to the Chrome Web Store.Summary by CodeRabbit