fix(ci): pass GitHub App token to checkout for workflow triggering

[paulbalaji]

Summary

• Generate GitHub App token BEFORE checkout in release workflows
• Pass the token to actions/checkout for git credential configuration
• Add setupGitUser: false and git config to publish-release job
• This fixes two issues:
  1. CI not triggering on commits pushed by the workflow
  2. Commits being authored by github-actions[bot] instead of hyper-gonk[bot]

Problem 1: CI Not Triggering

When the release workflow pushes commits (e.g., "Version Packages"), CI doesn't run on those commits. This is because:

1. actions/checkout configures git credentials at checkout time
2. By default, it uses GITHUB_TOKEN which cannot trigger other workflows (GitHub security feature)
3. GitHub App tokens can trigger workflows, but only if used for git authentication

Problem 2: Wrong Commit Author

The publish-release job was creating "Version Packages" commits as github-actions[bot] because:

1. It didn't have setupGitUser: false set
2. changesets/action defaults to configuring git as github-actions[bot]
3. It then force-pushes to changeset-release/main, overwriting hyper-gonk's commits

Solution

Generate the token before checkout and pass it via the token parameter, then configure git for both jobs:

steps:
  - name: Generate GitHub App Token
    id: generate-token
    uses: actions/create-github-app-token@v2
    ...

  - uses: actions/checkout@v5
    with:
      token: ${{ steps.generate-token.outputs.token }}

  - name: Configure Git for Hyper Gonk
    run: |
      git config user.name "hyper-gonk[bot]"
      git config user.email "...[bot]@users.noreply.github.com"

  - name: Changesets Action
    uses: changesets/action@v1
    with:
      setupGitUser: false  # Use our git config, not default
    env:
      GITHUB_TOKEN: ${{ steps.generate-token.outputs.token }}

Changes

• release.yml:
  • Move token generation before checkout in prepare-release
  • Add token generation, git config, and setupGitUser to publish-release
• rust-release.yml: Same fix for release-pr job

Note: combine.yml and update-hyperlane-deps.yml in hyperlane-registry already do this correctly.

Test Plan

• Merge this PR
• Trigger a release (e.g., merge a changeset)
• Verify CI runs on the "Version Packages" commit pushed by hyper-gonk
• Verify commits are authored by hyper-gonk[bot], not github-actions[bot]

🤖 Generated with Claude Code

[changeset-bot]

⚠️ No Changeset found

Latest commit: 4a1f77d

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[coderabbitai]

📝 Walkthrough

Walkthrough

Both release workflows now generate a GitHub App token early (before checkout) and reuse that single token for checkout, git configuration, changesets, and PR creation; duplicate token-generation steps were removed and publish-release additionally derives the bot user-id for git identity.

Changes

Cohort / File(s)	Summary
Release workflow token & git config ​.github/workflows/release.yml, ​.github/workflows/rust-release.yml	Add an upfront "Generate GitHub App Token" step and inject its output into actions/checkout (token: ${{ steps.generate-token.outputs.token }}); remove duplicated token-generation blocks; update publish-release to derive app user-id and configure git author using token-derived slug/user-id; set changesets setupGitUser: false and pass the generated token as GITHUB_TOKEN where applicable.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Areas to check:
  • Consistency of steps.generate-token.outputs.token references in both workflows and all checkout/PR/changesets steps.
  • Correct derivation and use of app-slug → user-id in publish-release git config.
  • That setupGitUser: false with explicit git config produces correct commit author/email for the bot.

Possibly related PRs

• fix: use Hyper Gonk identity for git commits in release workflows #7482 — Adds token-derived app-slug usage to set git commit identity for the release bot (closely related changes to git config).
• fix: use bot user ID for proper avatar attribution in commits #7491 — Fetches GitHub App/bot user ID and applies it to git identity in release workflows.
• fix: use hyper-gonk bot for release PRs #7472 — Consolidates GitHub App token generation in release workflows and removes duplicate token steps.

Suggested reviewers

• xeno097
• Mo-Hussain
• yjamin
• ameten

Poem

Ah, the token's moved up front — no more faffin' about,
One little secret now handles the bout.
Checkout's pleased, commits sing with proper name,
No duplicates left to muddy the game.
Roll on, tidy workflow — that's how we do the release shout.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title directly and clearly summarizes the main change: fixing CI workflows by passing the GitHub App token to checkout for proper workflow triggering.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description check	✅ Passed	PR description comprehensively covers all template requirements with clear problem statement, solution, changes, and test plan.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/release-workflow-trigger-ci

---

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.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

.github/workflows/release.yml (1)

68-72: Minor consideration on gh api calls for user ID fetching.

You're makin' API calls to fetch the bot user ID (lines 68-72 and 186-190) without explicit error handling. The GH_TOKEN env var is set properly, so it should work, but if that API call ever fails, the workflow'll keep goin' (since there's no set -e or explicit exit handling). In practice, if the user ID fetch fails, the subsequent git config will just set a partial/empty email, which might not cause an immediate visible error but could cause confusion later.

Not a blocker — the security model's sound and these API calls are straightforward — but if you wanted to tighten it up, you could add error handling or make the user ID output a required step.

If you'd like to make this more defensive, you could add set -e or explicit error checks, but it's not essential given the straightforward nature of the API calls.

Also applies to: 186-190

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f374616ff0cbaa95f7a3cb4466f374bd1470d404 and 4a1f77d.

📒 Files selected for processing (2)

• .github/workflows/release.yml (3 hunks)
• .github/workflows/rust-release.yml (1 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). (54)

• GitHub Check: cli-evm-e2e-matrix (warp-rebalancer)
• GitHub Check: cli-evm-e2e-matrix (warp-apply-submitters)
• GitHub Check: cli-evm-e2e-matrix (warp-check-4)
• GitHub Check: cli-evm-e2e-matrix (warp-check-2)
• GitHub Check: cli-evm-e2e-matrix (warp-init)
• GitHub Check: cli-evm-e2e-matrix (warp-send)
• GitHub Check: cli-evm-e2e-matrix (warp-apply-simple-updates)
• GitHub Check: cli-evm-e2e-matrix (warp-check-1)
• GitHub Check: cli-evm-e2e-matrix (warp-extend-config)
• GitHub Check: cli-evm-e2e-matrix (warp-read)
• GitHub Check: cli-evm-e2e-matrix (warp-extend-basic)
• GitHub Check: cli-evm-e2e-matrix (warp-bridge-2)
• GitHub Check: cli-evm-e2e-matrix (warp-check-5)
• GitHub Check: cli-evm-e2e-matrix (warp-deploy-2)
• GitHub Check: cli-evm-e2e-matrix (warp-check-3)
• GitHub Check: cli-evm-e2e-matrix (warp-deploy-1)
• GitHub Check: cli-evm-e2e-matrix (warp-bridge-1)
• GitHub Check: cli-evm-e2e-matrix (warp-apply-rebalancing-config)
• GitHub Check: cli-evm-e2e-matrix (warp-apply-ism-updates)
• GitHub Check: cli-evm-e2e-matrix (warp-extend-recovery)
• GitHub Check: cli-evm-e2e-matrix (relay)
• GitHub Check: cli-evm-e2e-matrix (warp-apply-hook-updates)
• GitHub Check: cli-evm-e2e-matrix (warp-apply-ownership-updates)
• GitHub Check: env-test-matrix (mainnet3, optimism, igp)
• GitHub Check: env-test-matrix (mainnet3, optimism, core)
• GitHub Check: cli-evm-e2e-matrix (core-read)
• GitHub Check: cli-evm-e2e-matrix (core-deploy)
• GitHub Check: cli-evm-e2e-matrix (core-init)
• GitHub Check: cli-evm-e2e-matrix (core-check)
• GitHub Check: cli-evm-e2e-matrix (core-apply)
• GitHub Check: env-test-matrix (mainnet3, arbitrum, core)
• GitHub Check: env-test-matrix (testnet4, sepolia, core)
• GitHub Check: env-test-matrix (mainnet3, ethereum, core)
• GitHub Check: env-test-matrix (mainnet3, ethereum, igp)
• GitHub Check: env-test-matrix (mainnet3, arbitrum, igp)
• GitHub Check: aleo-sdk-e2e-run
• GitHub Check: cli-radix-e2e-matrix (warp-apply-ownership-updates)
• GitHub Check: cosmos-sdk-e2e-run
• GitHub Check: cli-radix-e2e-matrix (core-deploy)
• GitHub Check: cli-radix-e2e-matrix (warp-apply-route-extension)
• GitHub Check: cli-radix-e2e-matrix (warp-deploy)
• GitHub Check: cli-cosmos-e2e-matrix (core-read)
• GitHub Check: cli-cosmos-e2e-matrix (warp-read)
• GitHub Check: cli-cosmos-e2e-matrix (core-deploy)
• GitHub Check: cli-cosmos-e2e-matrix (warp-deploy)
• GitHub Check: cli-cosmos-e2e-matrix (core-check)
• GitHub Check: cli-cosmos-e2e-matrix (core-apply)
• GitHub Check: cli-cross-chain-e2e-matrix (warp-deploy)
• GitHub Check: cli-cross-chain-e2e-matrix (warp-apply)
• GitHub Check: cli-install-test-run
• GitHub Check: e2e-matrix (evm)
• GitHub Check: lint-rs
• GitHub Check: test-rs
• GitHub Check: lander-coverage

🔇 Additional comments (6)

.github/workflows/rust-release.yml (3)

109-118: Token generation and checkout wiring looks solid.

The token's generated before checkout and properly passed through, which'll let subsequent git operations actually trigger workflows. Good move gettin' the credentials set up front like that.

---

184-184: Proper git identity configuration from token.

Pullin' the bot user ID from the app slug and configuring git with it — that's the right way. The token flows through GITHUB_TOKEN and git config picks it up for subsequent operations. Should work a treat.

Also applies to: 190-192

---

271-271: Publish job uses different approach for token handling.

The publish job here doesn't wire the App token into checkout (line 271) like release-pr does. Instead, it uses the default GITHUB_TOKEN and hardcodes github-actions[bot] for git identity. This isn't necessarily wrong — the job explicitly triggers downstream workflows with gh workflow run (lines 381-385) rather than relying on git push to do it. But worth notin' there's a difference in approach between this job and the publish-release job in release.yml, which does use the App token for checkout.

If you're intentionally keepin' these different, that's fine — just good to be aware of the inconsistency.

Can you confirm whether the publish job's approach (explicit workflow triggers rather than App token for git ops) is the intended pattern here, or should it align with release.yml's publish-release job?

Also applies to: 276-276, 281-282

.github/workflows/release.yml (3)

43-58: Token generation and checkout integration in prepare-release is well done.

Token's generated right up front, then passed straight into checkout via the token parameter. That's exactly what needs to happenin' for git credentials to be configured properly. The flow from token → checkout → subsequent operations is clean.

---

68-88: Git identity configuration and changesets setup is solid.

Fetching the bot user ID via API (lines 68-72), configuring git with that identity (lines 74-77), then disabling changesets' built-in git setup (line 85) and passin' the generated token (line 88) — that's the whole picture done right. The token's bein' reused consistently, and git'll use it for all the operations that follow.

---

161-206: Publish-release job mirrors prepare-release pattern — good consistency.

Same token → checkout → user ID → git config → changesets flow as prepare-release. Duplicatin' the pattern here is actually the right call for keeping jobs independent and clear about what they're doin'. Pattern's consistent within the file and matches the intent of the PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 0.00%. Comparing base (2eb378e) to head (4a1f77d).
⚠️ Report is 6 commits behind head on main.

Additional details and impacted files

@@     Coverage Diff      @@
##   main   #7515   +/-   ##
============================
============================

Components	Coverage Δ
core	∅ <ø> (∅)
hooks	∅ <ø> (∅)
isms	∅ <ø> (∅)
token	∅ <ø> (∅)
middlewares	∅ <ø> (∅)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.