project-automation cannot create GitHub App token for FastLED project sync

[zackees]

Problem

The project-automation workflow is currently failing before it can sync issues/PRs to the project board.

Failing run/job:

• Run: https://github.com/FastLED/FastLED/actions/runs/24797158573
• Job: https://github.com/FastLED/FastLED/actions/runs/24797158573/job/72569883734
• Workflow: project-automation
• Event: pull_request_target
• Head branch/SHA: fix-span-static-subviews / cce99e7738916f9419981866adeb3e356d6b00b8

The failure is not related to the PR code. The job fails in the Generate GitHub App token step before ci/github_project_sync.py runs.

Observed failure

actions/create-github-app-token@v1 is called from .github/workflows/project_automation.yml with:

app-id: ${{ vars.PROJECT_APP_ID }}
private-key: ${{ secrets.PROJECT_APP_PRIVATE_KEY }}
owner: ${{ vars.PROJECT_OWNER }}

Current repo variables observed through the Actions variables API:

• PROJECT_APP_ID=3422407
• PROJECT_OWNER=FastLED
• PROJECT_NUMBER=1

The secret PROJECT_APP_PRIVATE_KEY exists and was last updated on 2026-04-18T15:41:00Z.

The workflow log shows:

repositories not set, creating token for all repositories for given owner FastLED
Failed to create token for FastLED (attempt 1): Not Found - https://docs.github.com/rest/apps/apps#get-a-user-installation-for-the-authenticated-app
...
RequestError [HttpError]: Not Found
request url: https://api.github.com/users/FastLED/installation

The same authentication pattern is also used by .github/workflows/project_drift_sync.yml, so the nightly/project backfill sync is likely affected too.

Likely cause

The GitHub App identified by PROJECT_APP_ID=3422407 is not currently installed on the FastLED organization, or PROJECT_APP_PRIVATE_KEY belongs to a different GitHub App than app ID 3422407.

A missing repo variable is unlikely: the job passes the variable guard, and the action receives app ID 3422407 and owner FastLED.

Fix checklist

An org/repo admin should verify:

• GitHub App ID 3422407 still exists and is the intended project-sync app.
• The private key stored in PROJECT_APP_PRIVATE_KEY was generated from that exact app.
• The app is installed on the FastLED organization.
• The app installation has access to the FastLED/FastLED repository, or all repositories if the workflow should keep requesting an owner-wide token.
• The app has the permissions needed by ci/github_project_sync.py and ci/github_project_drift_sync.py, especially project access plus issue/PR metadata access.

Optional workflow hardening after the app is confirmed:

• Consider updating actions/create-github-app-token@v1 to the current major version.
• Consider scoping the token to the repository with repositories: FastLED if org-wide repository access is not required. The project sync may still need organization project permissions, so this should be tested against both event sync and drift sync.

Validation

After the app installation/key pairing is corrected, re-run the failed project-automation job or trigger a new issue/PR event. Then manually run project-drift-sync with workflow_dispatch to confirm the nightly sync path also generates a token successfully.

[zackees]

Additional gh investigation:

• Local gh auth is user zackees with repo, workflow, project, and read:org scopes.
• FastLED project support TLS3001 #1 is readable and resolves to FastLED Tracker: https://github.com/orgs/FastLED/projects/1.
• Installed GitHub Apps on the FastLED org visible through gh api orgs/FastLED/installations are:
  • cursor, app ID 1210556, installed for all repos
  • claude, app ID 1236702, installed for all repos
  • coderabbitai, app ID 347564, installed for all repos
• No installed app has app ID 3422407.
• gh api repos/FastLED/FastLED/installation with the user token returns 401 A JSON web token could not be decoded; that endpoint is for GitHub App JWT auth, so it does not validate the workflow app from a normal PAT.

Conclusion: PROJECT_APP_ID=3422407 is stale or refers to a GitHub App that has not been installed on the FastLED org. The next required step is admin/web UI work: locate app ID 3422407 under the app owner account and install it on FastLED, or create a replacement GitHub App and update PROJECT_APP_ID plus PROJECT_APP_PRIVATE_KEY.

[zackees]

Repo-side follow-up completed:

• Added repo Actions variable PROJECT_APP_CLIENT_ID=Iv23liL4dLxjYFwTNWKt.
• Opened PR Use GitHub App client ID for project sync token #2384 to switch both project sync workflows from actions/create-github-app-token@v1 + app-id to actions/create-github-app-token@v3 + client-id:
  Use GitHub App client ID for project sync token #2384

This is the CLI-fixable workflow modernization step. It does not install the GitHub App. The FastLED-owned app still needs to be installed on the FastLED organization before token generation can succeed.

Current FastLED org installations visible from gh api orgs/FastLED/installations still do not include app ID 3422407 / client ID Iv23liL4dLxjYFwTNWKt.

[zackees]

Applied the client-ID workflow update across the other feeder repos and added PROJECT_APP_CLIENT_ID=Iv23liL4dLxjYFwTNWKt as a repo Actions variable everywhere.

PRs:

• FastLED/FastLED: Use GitHub App client ID for project sync token #2384 (merged)
• FastLED/fbuild: Use GitHub App client ID for project sync token fbuild#188
• FastLED/PlatformIO-Starter: Use GitHub App client ID for project sync token PlatformIO-Starter#5
• FastLED/fastled-fastled.github.io: Use GitHub App client ID for project sync token fastled-fastled.github.io#4
• FastLED/fastled-playground: Use GitHub App client ID for project sync token fastled-playground#2
• FastLED/WiLi: https://github.com/FastLED/WiLi/pull/1

Each feeder PR changes only .github/workflows/add-to-project.yml from actions/create-github-app-token@v1/PROJECT_APP_ID to actions/create-github-app-token@v3/PROJECT_APP_CLIENT_ID.

Remaining non-CLI blocker is still the same: the GitHub App with app ID 3422407 / client ID Iv23liL4dLxjYFwTNWKt must be installed on the FastLED org.

[zackees]

Still reproducing after #2384 merged.

New failing run/job:

• Run: https://github.com/FastLED/FastLED/actions/runs/24804553005
• Job: https://github.com/FastLED/FastLED/actions/runs/24804553005/job/72595414611
• Workflow: project-automation
• Event: pull_request_target
• PR: Add FL_STATIC_ASSERT wrapper and lint #2390
• Base/head at run: master f104eb88fc64957b9b756241086eb0d708a1b203, head f9b474446ba5f31a5939522263b489dcbeb34a72

This run is using the post-#2384 config:

actions/create-github-app-token@v3
client-id: Iv23liL4dLxjYFwTNWKt
owner: FastLED

It still fails with:

Input 'repositories' is not set. Creating token for all repositories owned by FastLED.
Failed to create token for FastLED (attempt 1): Not Found - https://docs.github.com/rest/apps/apps#get-a-user-installation-for-the-authenticated-app
request url: https://api.github.com/users/FastLED/installation

So the earlier workflow fix corrected the action version/input (client-id), but this is still blocked on org/app configuration: the app identified by PROJECT_APP_CLIENT_ID=Iv23liL4dLxjYFwTNWKt is not visible as installed for owner FastLED, or the private key does not belong to that app. The scheduled project-drift-sync workflow has also been failing daily since at least 2026-04-19, which is consistent with the same root cause.

[zackees]

Follow-up on the post-#2384 failure: the run is no longer failing because of the old app-id/v1 config. It is failing inside actions/create-github-app-token@v3 before our Python project sync runs.

The owner-only token path logs:

Input 'repositories' is not set. Creating token for all repositories owned by FastLED.
GET https://api.github.com/users/FastLED/installation -> 404

FastLED is an organization, but the action's owner-only path is still using the /users/{owner}/installation lookup. I patched the workflows to pass explicit repositories so the action uses the repository installation path instead:

• project_automation.yml: scope the token to the event repository.
• project_drift_sync.yml: scope the token to the known feeder repositories.

I also made token generation best-effort: if the GitHub App is genuinely not installed or the private key/client ID is wrong, the workflows emit a warning and skip project sync instead of failing unrelated issue/PR checks.