ci(release): use GitHub App token in release-prepare for PR creation#1317
ci(release): use GitHub App token in release-prepare for PR creation#1317
Conversation
GITHUB_TOKEN is not permitted to create PRs in this repo. Switch to the GitHub App token (same pattern as release-tag and release-publish) so melos-action can successfully open the release PR. Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe workflows were changed to use a GitHub App token for release steps. A new step calls Sequence Diagram(s)sequenceDiagram
participant Runner as GitHub Actions Runner
participant CreateToken as actions/create-github-app-token@v2
participant GitHubApp as GitHub App (secrets: app-id, private-key)
participant Checkout as actions/checkout
participant Melos as grdsdev/melos-action (workflow)
participant GitHub as GitHub API / Repo
Runner->>CreateToken: invoke with app-id & private-key
CreateToken->>GitHubApp: request installation token
GitHubApp-->>CreateToken: return app installation token
CreateToken-->>Runner: outputs.app-token (token)
Runner->>Checkout: checkout repo with token=steps.app-token.outputs.token
Checkout->>GitHub: authenticate & fetch repo
Runner->>Melos: run melos-action with token=steps.app-token.outputs.token
Melos->>GitHub: authenticate (create PRs / perform release ops)
GitHub-->>Melos: API responses
Melos-->>Runner: action results
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/release-prepare.yml (1)
44-50:⚠️ Potential issue | 🟠 MajorPass the app token as
GH_TOKENenv var to the melos-action step for PR creation.The app token is passed to the
checkoutstep (line 37), which configures git credentials. However, whencreate-pr: truetriggers PR creation,bluefireteam/melos-action@v3invokes the GitHub CLI (gh pr create), which reads the token from theGH_TOKENenvironment variable, not from git credentials.This pattern is already demonstrated in
release-tag.yml(line 51), whereGH_TOKENis explicitly passed whengh workflow runis invoked. Similarly,release-publish.ymlpasses the token to the GitHub Release action (line 79). Themelos-actionstep inrelease-prepare.ymlneeds the same treatment.Add the following to the melos-action step:
Suggested fix
- name: Setup Melos uses: bluefireteam/melos-action@v3 + env: + GH_TOKEN: ${{ steps.app-token.outputs.token }} with: run-versioning: ${{ inputs.prerelease == false }} run-versioning-prerelease: ${{ inputs.prerelease == true }} run-versioning-graduate: ${{ inputs.graduate == true }} create-pr: true🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release-prepare.yml around lines 44 - 50, The melos-action step (uses: bluefireteam/melos-action@v3) currently sets create-pr: true but does not expose the app token to GH CLI; add an env entry for GH_TOKEN populated from the workflow input (the same token used in the checkout step) so the action can run gh pr create (e.g., add GH_TOKEN: ${{ inputs.token }} under the melos-action step).
🧹 Nitpick comments (1)
.github/workflows/release-prepare.yml (1)
26-31: Consider storingAPP_IDas a configuration variable (vars) rather than a secret.GitHub's documentation recommends storing the app ID as a GitHub Actions configuration variable, not a secret, since the app ID is non-sensitive. The official action README and all GitHub-provided examples use
${{ vars.APP_ID }}forapp-id. Storing it as a secret unnecessarily masks it in logs and exhausts secret quota.⚙️ Suggested change
- app-id: ${{ secrets.APP_ID }} + app-id: ${{ vars.APP_ID }}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release-prepare.yml around lines 26 - 31, The Generate token step (id: app-token, uses: actions/create-github-app-token@v2) currently reads app-id from secrets (secrets.APP_ID); change it to use a repository/organization variable reference (vars.APP_ID) instead of a secret, update any documentation or CI variable setup to add APP_ID as a GitHub Actions variable, and remove or stop relying on the secrets.APP_ID entry to avoid masking a non-sensitive app ID in logs and consuming secret quota.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In @.github/workflows/release-prepare.yml:
- Around line 44-50: The melos-action step (uses: bluefireteam/melos-action@v3)
currently sets create-pr: true but does not expose the app token to GH CLI; add
an env entry for GH_TOKEN populated from the workflow input (the same token used
in the checkout step) so the action can run gh pr create (e.g., add GH_TOKEN:
${{ inputs.token }} under the melos-action step).
---
Nitpick comments:
In @.github/workflows/release-prepare.yml:
- Around line 26-31: The Generate token step (id: app-token, uses:
actions/create-github-app-token@v2) currently reads app-id from secrets
(secrets.APP_ID); change it to use a repository/organization variable reference
(vars.APP_ID) instead of a secret, update any documentation or CI variable setup
to add APP_ID as a GitHub Actions variable, and remove or stop relying on the
secrets.APP_ID entry to avoid masking a non-sensitive app ID in logs and
consuming secret quota.
ℹ️ Review info
Configuration used: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
Cache: Disabled due to Reviews > Disable Cache setting
Disabled knowledge base sources:
- Linear integration is disabled
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
.github/workflows/release-prepare.yml
Use grdsdev/melos-action@feat/custom-token-for-create-pr across all three release workflows. Pass the App token to the melos-action in release-prepare so peter-evans/create-pull-request uses it directly — the fork's token input is the correct fix for the GITHUB_TOKEN PR creation restriction. Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
.github/workflows/release-tag.yml (1)
26-27:app-idis non-sensitive — prefervars.APP_IDoversecrets.APP_ID.The official marketplace recommends storing the App's ID in repository environment variables rather than secrets. Using a secret unnecessarily masks the app ID in logs, making debugging harder without any real security benefit.
- app-id: ${{ secrets.APP_ID }} + app-id: ${{ vars.APP_ID }}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release-tag.yml around lines 26 - 27, Replace the unnecessary secret usage for the App ID in the workflow: change the app-id input that currently uses secrets.APP_ID to use repository variables (vars.APP_ID) while keeping private-key as secrets.PRIVATE_KEY; update the app-id line (the key named "app-id" in the release-tag.yml job step) to reference ${{ vars.APP_ID }} so the App ID is stored as a non-sensitive repo variable for easier logging and debugging..github/workflows/release-publish.yml (1)
32-33: Samevars.APP_IDrecommendation as inrelease-tag.yml.
app-idis not sensitive — store it as a configuration variable rather than a secret for consistency with the officialactions/create-github-app-tokenusage examples.- app-id: ${{ secrets.APP_ID }} + app-id: ${{ vars.APP_ID }}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release-publish.yml around lines 32 - 33, The workflow currently uses a secret for the GitHub App ID; change the `app-id` input to use a repository/organization variable instead of a secret by replacing `${{ secrets.APP_ID }}` with `${{ vars.APP_ID }}` in the `.github/workflows/release-publish.yml` action step (keep `private-key: ${{ secrets.PRIVATE_KEY }}` as-is); update any documentation or workflow docs to state APP_ID is stored in vars and not in secrets to match `actions/create-github-app-token` examples.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release-publish.yml:
- Line 47: The workflow references a mutable fork branch
"grdsdev/melos-action@feat/custom-token-for-create-pr" which is a supply-chain
risk; replace that branch ref with an immutable commit SHA (or an official
released tag) for grdsdev/melos-action so the action is pinned to a specific
commit, matching the same pinned ref used in release-tag.yml; update the "uses:"
value to the selected commit SHA for grdsdev/melos-action and ensure any other
workflow references use the identical immutable ref.
In @.github/workflows/release-tag.yml:
- Line 39: Replace the mutable branch ref
grdsdev/melos-action@feat/custom-token-for-create-pr with a pinned full commit
SHA for that fork (e.g. grdsdev/melos-action@<full-commit-sha>) so the action
cannot change between runs; alternatively switch to the upstream official
release (e.g. bluefireteam/melos-action@<tag-or-sha>) if available—update the
uses: line accordingly to reference the exact commit SHA.
---
Nitpick comments:
In @.github/workflows/release-publish.yml:
- Around line 32-33: The workflow currently uses a secret for the GitHub App ID;
change the `app-id` input to use a repository/organization variable instead of a
secret by replacing `${{ secrets.APP_ID }}` with `${{ vars.APP_ID }}` in the
`.github/workflows/release-publish.yml` action step (keep `private-key: ${{
secrets.PRIVATE_KEY }}` as-is); update any documentation or workflow docs to
state APP_ID is stored in vars and not in secrets to match
`actions/create-github-app-token` examples.
In @.github/workflows/release-tag.yml:
- Around line 26-27: Replace the unnecessary secret usage for the App ID in the
workflow: change the app-id input that currently uses secrets.APP_ID to use
repository variables (vars.APP_ID) while keeping private-key as
secrets.PRIVATE_KEY; update the app-id line (the key named "app-id" in the
release-tag.yml job step) to reference ${{ vars.APP_ID }} so the App ID is
stored as a non-sensitive repo variable for easier logging and debugging.
ℹ️ Review info
Configuration used: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro
Cache: Disabled due to Reviews > Disable Cache setting
Disabled knowledge base sources:
- Linear integration is disabled
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (3)
.github/workflows/release-prepare.yml.github/workflows/release-publish.yml.github/workflows/release-tag.yml
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/release-prepare.yml
|
|
||
| - name: Bootstrap with Melos | ||
| uses: bluefireteam/melos-action@v3 | ||
| uses: grdsdev/melos-action@feat/custom-token-for-create-pr |
There was a problem hiding this comment.
Same mutable fork branch ref as in release-tag.yml — pin to a commit SHA.
grdsdev/melos-action@feat/custom-token-for-create-pr is a mutable branch pointer on a personal fork. The same supply chain risk applies here: force-pushing the branch silently changes what code runs, and this workflow handles the full publish flow including pub.dev publishing and GitHub Release creation.
- uses: grdsdev/melos-action@feat/custom-token-for-create-pr
+ uses: grdsdev/melos-action@<full-commit-sha> # feat/custom-token-for-create-pr🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/release-publish.yml at line 47, The workflow references a
mutable fork branch "grdsdev/melos-action@feat/custom-token-for-create-pr" which
is a supply-chain risk; replace that branch ref with an immutable commit SHA (or
an official released tag) for grdsdev/melos-action so the action is pinned to a
specific commit, matching the same pinned ref used in release-tag.yml; update
the "uses:" value to the selected commit SHA for grdsdev/melos-action and ensure
any other workflow references use the identical immutable ref.
|
|
||
| - name: Setup Melos | ||
| uses: bluefireteam/melos-action@v3 | ||
| uses: grdsdev/melos-action@feat/custom-token-for-create-pr |
There was a problem hiding this comment.
Pin the fork action to a full commit SHA instead of a mutable branch ref.
grdsdev/melos-action@feat/custom-token-for-create-pr is a branch pointer on a personal fork. If the branch is force-pushed or the fork is compromised, the next workflow run silently executes different code with access to APP_ID, PRIVATE_KEY, and a valid installation token. Pinning to a commit SHA is the standard mitigation.
- uses: grdsdev/melos-action@feat/custom-token-for-create-pr
+ uses: grdsdev/melos-action@<full-commit-sha> # feat/custom-token-for-create-prIf this fork is intended only as a temporary bridge, consider opening a PR upstream to bluefireteam/melos-action so you can return to an official, versioned release.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/release-tag.yml at line 39, Replace the mutable branch ref
grdsdev/melos-action@feat/custom-token-for-create-pr with a pinned full commit
SHA for that fork (e.g. grdsdev/melos-action@<full-commit-sha>) so the action
cannot change between runs; alternatively switch to the upstream official
release (e.g. bluefireteam/melos-action@<tag-or-sha>) if available—update the
uses: line accordingly to reference the exact commit SHA.
1 participant
Fixes the CI failure in the Prepare Release workflow where
GITHUB_TOKENis not permitted to create pull requests in this repo.Adds a
Generate tokenstep usingactions/create-github-app-token@v2and passes the App token to the checkout step, somelos-actioninherits it when opening the release PR — matching the same pattern already used inrelease-tag.ymlandrelease-publish.yml.🤖 Generated with Claude Code