ci: update V1_LATEST_TAG repo variable on stable releases#125
ci: update V1_LATEST_TAG repo variable on stable releases#125
Conversation
After creating a stable (non-prerelease) release, update the V1_LATEST_TAG repo variable so the hermes v2 release workflow can restore 'latest' to the correct v1 tag.
|
auggie review |
| - name: Update V1_LATEST_TAG variable | ||
| if: ${{ !contains(inputs.version || github.event.client_payload.version, 'prerelease') }} | ||
| env: | ||
| GH_TOKEN: ${{ github.token }} |
There was a problem hiding this comment.
Could we avoid using github.token for this API call? The repository variables endpoint requires repository Variables: write permission, which the workflow GITHUB_TOKEN does not expose/grant here, so this step is likely to fail with Resource not accessible by integration after the release has already been created.
Current code:
GH_TOKEN: ${{ github.token }}Suggested improvement:
GH_TOKEN: ${{ secrets.VARIABLES_WRITE_TOKEN }}Consider using a GitHub App token or fine-grained PAT secret scoped to repository variables write access (plus metadata read) for just this update step.
There was a problem hiding this comment.
Good catch. Instead of a separate PAT, I added variables: write to the job's permissions block, which grants the GITHUB_TOKEN access to update repo variables. Verified the API call works — pushed in d3b28b6.
The GITHUB_TOKEN needs variables: write permission to update repo variables via the API.
There was a problem hiding this comment.
Review completed. 1 suggestion posted.
Code Review Triage 🛡️ · Requires Review
Justification
This PR changes release automation behavior by updating a repository variable from a GitHub Actions workflow (in an opted-out `.github/` directory), which can impact release pipelines.Reach out to #feedback-code-review-agent for feedback
Comment augment review to trigger a new review at any time.
| GH_TOKEN: ${{ github.token }} | ||
| VERSION: ${{ inputs.version || github.event.client_payload.version }} | ||
| run: | | ||
| gh api --method PATCH "repos/${{ github.repository }}/actions/variables/V1_LATEST_TAG" \ |
There was a problem hiding this comment.
There was a problem hiding this comment.
The required permission is variables: write, not actions: write. Per GitHub docs, the fine-grained token needs "Variables" repository permissions (write). This has been added to the job's permissions block in d3b28b6.
There was a problem hiding this comment.
Review completed. 1 suggestion posted.
Code Review Triage 🛡️ · Requires Review
Justification
This PR changes a release workflow under `.github/` and adds new write permissions plus a post-release API call that mutates a repository variable.Reach out to #feedback-code-review-agent for feedback
Comment augment review to trigger a new review at any time.
| artifacts/* | ||
|
|
||
| - name: Update V1_LATEST_TAG variable | ||
| if: ${{ !contains(inputs.version || github.event.client_payload.version, 'prerelease') }} |
There was a problem hiding this comment.
contains() in GitHub expressions is case-insensitive, while the prerelease detection in the Create GitHub Release step uses a bash glob match that is case-sensitive; mixed-case versions could cause the release type and the V1_LATEST_TAG update decision to diverge.
Severity: low
🤖 Was this useful? React with 👍 or 👎
Problem
The hermes
release-auggie-v2workflow publishes v2 releases to this repo and needs to restore "latest" back to the v1 stable release afterwards. It reads a repo variable (V1_LATEST_TAG) to know which tag to re-point to.Solution
After the bun-compile workflow creates a stable (non-prerelease) v1 release, update the
V1_LATEST_TAGrepo variable to the newly released version. This keeps the variable in sync automatically.Changes
variables: writepermission to thereleasejobSetup
V1_LATEST_TAGrepo variable has been created with initial valuev0.24.0gh api --method PATCHCompanion PR
V1_LATEST_TAGand re-points latest after each v2 release