fix: checkout release-please PR before local action

[joeyorlando]

Summary

• add an initial checkout step for release-please PRs in the Platform Lint and Unit Tests job
• ensure the local composite action at ./.github/actions/github-app-token exists on disk before GitHub tries to load it
• preserve the follow-up checkout that swaps credentials to the GitHub App token for generated-file pushes

Root cause

The release-please path skipped the first checkout, then immediately ran uses: ./.github/actions/github-app-token. Local actions cannot be loaded until the repository has been checked out, so the job failed with:

Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under '/home/runner/_work/archestra/archestra/.github/actions/github-app-token'

Fixes the failure on release-please PR #3716.

[claude]

Claude finished @joeyorlando's task in 1m 3s —— View job

---

PR Review

• Read the changed workflow file
• Analyze the diff against origin/main
• Assess correctness of the fix
• Post review feedback

---

Summary

The fix correctly addresses the root cause: the release-please branch in platform-lint-and-unit-tests was trying to uses: ./.github/actions/github-app-token without a prior checkout, so the runner could not find action.yml on disk. Adding a plain checkout gated on is-release-please == 'true' makes the local composite action loadable, and the follow-up checkout that swaps in the GitHub App token is preserved. The persist-credentials: false in the new step is the right default and avoids leaking GITHUB_TOKEN into the workspace before the app-token checkout replaces it.

Overall: LGTM, this will unblock release-please PR #3716. One optional simplification noted below.

Observations

1. Consider collapsing the two conditional checkouts into one unconditional checkout — .github/workflows/on-pull-requests.yml:200-212

The two checkout steps are now byte-identical except for the if: condition:

- name: Checkout project
  if: ${{ steps.check-release-please.outputs.is-release-please != 'true' }}
  uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
  with:
    persist-credentials: false
    fetch-depth: 1

- name: Checkout project for release-please PR
  if: ${{ steps.check-release-please.outputs.is-release-please == 'true' }}
  uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
  with:
    persist-credentials: false
    fetch-depth: 1

Since the configurations are identical and together they cover every case, you could drop both if: conditions and keep a single unconditional "Checkout project" step. That would be slightly more readable and removes a chunk of duplication. The release-please-specific re-checkout at lines 224-231 (which swaps to the app token) would still run afterwards for release-please PRs, so behavior is preserved.

Minimal patch:

       - name: Checkout project
-        if: ${{ steps.check-release-please.outputs.is-release-please != 'true' }}
-        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
-        with:
-          persist-credentials: false
-          fetch-depth: 1
-
-      - name: Checkout project for release-please PR
-        if: ${{ steps.check-release-please.outputs.is-release-please == 'true' }}
         uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
         with:
           persist-credentials: false
           fetch-depth: 1

Fix this →

This is optional — the current fix is correct as-is, and if you preferred keeping the two conditional steps for future divergence (e.g. different fetch-depth), that's reasonable too.

2. Correctness of downstream steps — verified

• Generate token for release-please PR at line 219 will now find ./.github/actions/github-app-token/action.yml because the workspace is populated.
• Update checkout credentials for release-please PR at line 224 still runs afterwards and overwrites the workspace with persist-credentials: true plus the app token, which is what you need for the git push at line 268.
• persist-credentials: false on the new step is consistent with zizmor's hardening expectations and avoids having GITHUB_TOKEN sitting in .git/config between the first checkout and the app-token checkout.

3. No security concerns

The new step uses the same pinned SHA (de0fac2e4500dabe0009e67214ff5f5447ce83dd) as every other actions/checkout in this workflow, and does not persist credentials. Supply-chain-policy should be happy.

Verdict

Approve-worthy from a correctness and security standpoint. The only feedback is the optional consolidation above.
• Branch