Upgrade GitHub Actions for improved functionality

[devfrankduah]

Update actions/checkout to version 6 and actions/create-github-app-token to version 3 to enhance functionality and consistency across workflows. Fix minor issues related to variable configurations.

[llm-exe-review-bot]

PR Review: Upgrade GitHub Actions for improved functionality

Summary

This PR updates CI/CD workflow infrastructure: bumps actions/checkout v4→v6 and actions/create-github-app-token v1→v3 across all workflow files, migrates from app-id (secret) to client-id (var) per the v3 API, and adds substantial failure-recovery logic to publish-release.yml.

No src/ changes, so no dist/ rebuild is needed. ✅

---

Findings

✅ Looks good

• Action version bumps — actions/checkout@v6 and actions/create-github-app-token@v3 are valid releases (latest are v7 and v3.2.0 respectively).
• app-id → client-id migration — correct for create-github-app-token v3. Moving client IDs from secrets to vars is appropriate since they are non-sensitive public identifiers.
• APP_BOT_USER_ID for git email — correct. The GitHub App user ID (for noreply email) differs from the App ID; using a dedicated variable is the right fix.
• pull-requests: write permission — needed for the new gh pr create/edit/merge operations in the failure recovery job.
• Release notes filter — adding revert version bump after failed publish to the sed filter is consistent with the new revert commit message format.
• revert-to-draft job condition — always() && ... needs.publish-action.result == 'failure' is the correct pattern.

📝 Notes (non-blocking)

1. package-lock.json not reverted (publish-release.yml:197-198) — The version revert only modifies and stages package.json. If the original version-bump workflow also modified package-lock.json, the lockfile version will be inconsistent after the revert. Consider either also reverting the lockfile, or running npm install before the commit to sync it.

2. --admin merge bypasses branch protections (publish-release.yml:212) — gh pr merge "$REVERT_PR" --admin --squash skips required checks and approvals. This is clearly intentional for automated recovery, but worth confirming the bot token's app has admin/bypass permissions, and that the team is comfortable with unreviewed merges to development in this recovery path.

3. Force push to revert-version-bump (publish-release.yml:200) — Acceptable for a short-lived branch, but if two releases fail in quick succession, there's a small race window where concurrent revert-to-draft runs could conflict on this branch name. Low risk in practice since concurrent release failures are unlikely.

4. Token interpolation style (publish-release.yml:157) — The curl Authorization header changed from ${GH_TOKEN} (shell env var) to ${{ steps.bot-token.outputs.token }} (Actions expression). Both are functionally fine, but since GH_TOKEN is already set as a step-level env var, using ${GH_TOKEN} would be slightly more consistent and avoids direct expression interpolation into shell strings.

5. Consider set -euo pipefail for the version-revert step (publish-release.yml:182-233) — This is a long shell script where a silent mid-step failure (e.g., gh pr merge failing) would cause the script to continue. The other complex step in this workflow (promote floating tags) already uses set -euo pipefail.

---

Verdict

No blocking issues. The action version upgrades are correct, the create-github-app-token migration follows the v3 API properly, and the failure-recovery logic is well-structured. The notes above are all minor improvements that could be addressed in a follow-up.