Skip to content

ci: update V1_LATEST_TAG repo variable on stable releases#125

Merged
kjiang-ac merged 2 commits intomainfrom
kjiang-ac-update-v1-latest-tag
Apr 17, 2026
Merged

ci: update V1_LATEST_TAG repo variable on stable releases#125
kjiang-ac merged 2 commits intomainfrom
kjiang-ac-update-v1-latest-tag

Conversation

@kjiang-ac
Copy link
Copy Markdown
Contributor

@kjiang-ac kjiang-ac commented Apr 16, 2026

Problem

The hermes release-auggie-v2 workflow 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_TAG repo variable to the newly released version. This keeps the variable in sync automatically.

Changes

  • Added variables: write permission to the release job
  • Added "Update V1_LATEST_TAG variable" step that runs only for stable releases

Setup

  • V1_LATEST_TAG repo variable has been created with initial value v0.24.0
  • Verified the API call works via gh api --method PATCH

Companion PR

  • hermes PR #176 — reads V1_LATEST_TAG and re-points latest after each v2 release

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.
@kjiang-ac
Copy link
Copy Markdown
Contributor Author

auggie review

Copy link
Copy Markdown

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review submitted with one comment about ensuring the variable update step uses credentials that can write repository variables.


🤖 Automated review complete. Please react with 👍 or 👎 on the individual review comments to provide feedback on their usefulness.

- name: Update V1_LATEST_TAG variable
if: ${{ !contains(inputs.version || github.event.client_payload.version, 'prerelease') }}
env:
GH_TOKEN: ${{ github.token }}
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Copy Markdown
Contributor

@augment-app-staging augment-app-staging bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review completed. 1 suggestion posted.

Fix All in Augment

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" \
Copy link
Copy Markdown
Contributor

@augment-app-staging augment-app-staging bot Apr 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This step updates a repository Actions variable via the Actions API, but the release job only grants contents: write; with restricted job permissions, GITHUB_TOKEN may lack actions: write and this call can 403 at runtime.

Severity: medium

Fix This in Augment

🤖 Was this useful? React with 👍 or 👎

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@kjiang-ac kjiang-ac marked this pull request as ready for review April 17, 2026 00:18
@kjiang-ac kjiang-ac requested a review from tulga-bytes April 17, 2026 00:19
Copy link
Copy Markdown
Contributor

@augment-app-staging augment-app-staging bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review completed. 1 suggestion posted.

Fix All in Augment

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') }}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 👎

@kjiang-ac kjiang-ac merged commit affbc21 into main Apr 17, 2026
@kjiang-ac kjiang-ac deleted the kjiang-ac-update-v1-latest-tag branch April 17, 2026 19:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant