Use codeql-ci-app token for integration tests

[redsun82]

Why

BOT_TOKEN is a PAT on the codeql-remote-query-bot machine user. It has to be rotated by hand every 90 days, tracked by a recurring Slack reminder. This replaces it with short-lived codeql-ci-app installation tokens, which expire on their own and need no rotation.

Approach

A single Generate CI token step at the top of the job mints one installation token, and all four API call sites use it. Minting once is safe because the job's timeout-minutes: 30 sits comfortably inside the ~1 hour token lifetime.

The token is scoped as narrowly as the calls allow:

• contents: write for the variant-analyses endpoints, which run control_access :write_multi_repository_variant_analysis / :read_... and map to repo_contents_writer
• actions: read for GET /actions/runs/{id}
• repositories: codeql-variant-analysis-action, so the token only reaches this repo

Both endpoints already set allow_integrations: true, so app tokens are accepted.

Notes for reviewers

The token scope and the analysis targets are unrelated. The JSON payload still lists docker/compose, hashicorp/terraform, and github/does-not-exist. Those are the variant analysis targets and are untouched. They resolve regardless of token scope because public repos are unioned into the accessible set, so scoping the token to one repo does not affect them.

permissions: {} added to the job. Nothing here uses GITHUB_TOKEN: every call passes an explicit Authorization header, and create-github-app-token authenticates with a private-key JWT, including its post-run token revocation. Worth knowing for later, since a future step that expects GITHUB_TOKEN will fail with a 403 that does not obviously point back at this line.

action_repo_ref is unchanged and deliberately not main. The workflow passes the PR head ref so the test exercises the action code from the pull request. Non-default refs are gated on the mrva_allow_non_default_action_ref feature flag, and codeql-ci-app[bot] is enrolled. I added a comment at the REF computation recording this, because a failure here surfaces as Invalid ref provided. You are only allowed to use main., which reads like a workflow bug and invites pinning the ref to main. That would make the test pass while no longer testing the PR's code.

This PR validates itself. It is a same-repo PR, so secrets are available and the integration test runs with the new auth path against this branch.

Follow-up, not in this PR

BOT_TOKEN still exists as a repository secret. It should stay until the integration test goes green here, so there is a fallback, and then be deleted along with the rotation reminder.

Fork PRs cannot run this workflow, since secrets are unavailable to them. That is pre-existing rather than new: BOT_TOKEN was equally a secret. The only difference is that failure now surfaces at the minting step instead of later as a null variant analysis ID.

[Copilot]

Copilot review overview

🟡 Changes recommended

The scoped token omits target-result details, causing the integration test to fail.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review tier: Balanced
Findings: 1

New issues introduced by this change (1)

Severity	Finding
	.github/​workflows/​integration-tests.yml — Scoping the installation token to only this repository prevents this test from reading the…

What changed in this PR

Replaces the rotating BOT_TOKEN with a short-lived GitHub App token for integration tests.

Changes:

• Mints a narrowly scoped codeql-ci-app token.
• Uses it for all four API requests.
• Documents non-main ref requirements.

File	Description
.github/​workflows/​integration-tests.yml	Configures and uses GitHub App authentication.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.