Repository navigation
The dispatch dry run could never run — workflow_call secrets are empty on workflow_dispatch - #2699
Conversation
…low_dispatch `secrets.app-id` / `secrets.private-key` are workflow_call inputs. On a manual `workflow_dispatch` there is no caller passing them, so both resolve to the EMPTY STRING and the credential assertion refuses — correctly, but for the wrong reason: nothing was misconfigured, the dispatch path simply could not see the secrets. Observed on run 33274129955, the first dry run after #2694: it failed at "Assert the dispatch credential is configured" while `DEPENDENT_DISPATCH_APP_ID` is set on the repo. Fall back to the repo secret on the dispatch path. Without this the ONE tool for checking whether the fan-out reaches anything is itself untestable, which is the same failure it exists to prevent — a mechanism that reports a problem it created. The assertion stays exactly as it was: with the fallback in place, a red here now means the credential really is absent rather than merely invisible. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR fixes the manual workflow_dispatch dry-run path for the dependent-repo notification workflow by ensuring GitHub App credentials are available even when the workflow is not invoked via workflow_call (where the app-id/private-key secrets are normally provided by a caller).
Changes:
- Add an expression fallback so
workflow_dispatchruns can use repo secrets (DEPENDENT_DISPATCH_APP_ID/DEPENDENT_DISPATCH_APP_PRIVATE_KEY) whenworkflow_callsecrets are absent/empty. - Apply the same fallback both to the credential assertion step and to the
actions/create-github-app-token@v2token minting step.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Test Results (shard 3)689 tests 497 ✅ 4m 45s ⏱️ Results for commit 6bf34a3. |
Test Results (shard 0)913 tests 913 ✅ 5m 38s ⏱️ Results for commit 6bf34a3. |
Test Results (shard 5)1 528 tests 1 528 ✅ 5m 32s ⏱️ Results for commit 6bf34a3. |
Test Results (shard 2)941 tests 941 ✅ 5m 8s ⏱️ Results for commit 6bf34a3. |
Test Results (shard 4) 10 files 10 suites 5m 14s ⏱️ Results for commit 6bf34a3. |
Test Results (shard 1)788 tests 784 ✅ 7m 32s ⏱️ Results for commit 6bf34a3. |
Test Results 41 files 41 suites 33m 52s ⏱️ Results for commit 6bf34a3. |
#2694 added a manual dry run so "is the dispatch App installed everywhere?" could be answered on demand. It could never run.
secrets.app-idandsecrets.private-keyareworkflow_callinputs. On a manualworkflow_dispatchthere is no caller passing them, so both resolve to the empty string and the credential assertion refuses.Observed on run
33274129955— the first dry run after #2694 merged — failing at "Assert the dispatch credential is configured" whileDEPENDENT_DISPATCH_APP_IDis set on the repo.The assertion was right; the reason was wrong. Nothing was misconfigured — the dispatch path simply could not see the secrets.
Fix
Fall back to the repo secret when the workflow_call one is absent:
The assertion itself is unchanged. With the fallback in place a red there now means the credential really is absent, rather than merely invisible on this path.
Why this was worth catching rather than working around
The dry run is the one tool for checking whether the fan-out reaches anything. A checking tool that cannot itself be run is the same failure it exists to prevent — its predecessor printed
NOT CONFIGUREDand went green for its entire life. I would rather it fail loudly for a real reason than be quietly untestable.Once this lands, the dry run answers the open question directly: it prints the repositories the App is installed on, or fails naming an empty set.