AX-1837: Add tag/release mechanism - #3
Merged
Conversation
…on check - Seed VERSION at 0.1.1 (current .devin-plugin/plugin.json version) - release.yml: on push to main with [major/minor/patch], reads VERSION, creates vX.Y.Z git tag, publishes GitHub Release with repo zip - validate-version.yml: PR check — fails if VERSION != plugin.json version - CONTRIBUTING.md: add Releasing section documenting the new flow Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…tep comments Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ION file .devin-plugin/plugin.json already carries the version Devin reads, so a VERSION file was a second copy that validate-version.yml then had to police against it. Both are gone; release.yml reads the manifest directly. Also refuses to re-tag a version that already shipped (the one mistake a marker-triggered release allows) and reads the commit message from env rather than interpolating it into the script.
YoniMelki
changed the title
These repos squash-merge, and GitHub pre-fills the squash message body from the branch's commit messages (or the PR description). Both of those quote [major]/[minor]/[patch] while only documenting the flow, so matching the whole message meant merging this very PR would have cut a release nobody asked for. Matching the subject line alone keeps the trigger deliberate: a release happens when someone writes the marker in the subject they are merging, not when a marker happens to appear in generated body text.
![github-actions[bot]](https://github.githubassets.com/images/gravatars/gravatar-user-420.png){kind=avatar}
… release Three fixes from review, all in release.yml. An orphan tag was possible: the tag was pushed in its own step before `gh release create`, so a failure in between left a tag with no release behind it. The re-run then hit the "already exists" check with nothing actually wrong but the tag, and it needed deleting by hand. The tag is now created by `gh release create --target "$GITHUB_SHA"` in the same API call as the release, so there is no window between the two. Nothing pushes over git anymore, so the write token is gone from the checkout step. Releases were not gated on validation. The validate workflow triggers on the same push, but as a separate workflow with no relationship to this one, so it could still be red while a release went out. The same check now runs here, before the release is created. `zip -r release.zip .` packed the working tree, so anything an earlier step left on the runner would ship inside the artifact. Replaced with `git archive`, which exports tracked files at HEAD, still excluding .github.
…TRIBUTING Review feedback: the per-step comments in release.yml had grown into several paragraphs of rationale, which is documentation rather than a code comment. Each step now carries at most two lines - what it does, or the one constraint a reader could otherwise undo by "simplifying" it: subject-line matching, env rather than interpolation, git archive rather than the working tree, --target creating the tag. A pointer at the top of the file sends readers to CONTRIBUTING.md for the full flow. CONTRIBUTING.md gains the parts the comments had that it did not already say: what the workflow does in order, what ends up in the release zip, why validation runs inside the release job instead of relying on the separate validate workflow, and why the tag is created by the release rather than pushed before it. No behaviour change - the release.yml diff is comments only.
yanivt-jfrog
approved these changes
Aug 10, 2026
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
2 participants
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
Adds a tag/release mechanism. The version lives in exactly one place:
.versionin.devin-plugin/plugin.json, the manifest Devin already reads.release.yml— on push tomain, if the commit subject carries[major],[minor]or[patch], reads the version from the manifest, tagsvX.Y.Z, and publishes a GitHub Release with a repo zip attached.VERSIONfile, and so novalidate-versioncheck either. A duplicate copy of the version is the only thing such a check would have policed.CONTRIBUTING.mdgains a Releasing section.Notes for reviewers
The version comes from the manifest, not from the marker. The marker only decides whether to release; it does not compute a bump. The version change stays reviewable in the PR that makes it, and no bot ever pushes to
main.The marker is matched on the subject line only. These repos squash-merge, and GitHub pre-fills the squash body from the branch's commit messages or the PR description, either of which can quote a marker while merely documenting the flow. Subject-only keeps the trigger deliberate.
Merging a marker without bumping the manifest fails the release rather than re-tagging a version that already shipped — which matters here, since
v0.1.0is already tagged and the manifest currently reads0.1.1.The commit message is read through
env, not interpolated into the script, so a crafted commit subject cannot inject shell.Test plan
validatepasses on this PRrelease.ymlshows up in Actions and no release fires — the squash subject defaults to this PR's title, which carries no marker[patch]in the subject while the manifest still reads an already-tagged version fails with a clear error[patch]in the subject, produces the matching tag and GitHub ReleaseCloses AX-1837 / part of AX-1733