Expose the startup_failure reason (invalid workflow file error) via the REST/GraphQL API #200010
Replies: 2 comments
-
|
Thank you for your interest in contributing to our community! We currently only accept discussions created through the GitHub UI using our provided discussion templates. Please re-submit your discussion by navigating to the appropriate category and using the template provided. This discussion has been closed because it was not submitted through the expected format. If you believe this was a mistake, please reach out to the maintainers. |
Beta Was this translation helpful? Give feedback.
-
|
Apologies — this was created via the API by mistake and is correctly auto-closed. Re-submitting through the UI with the provided template. Please disregard. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Summary
When a workflow run ends in
conclusion: startup_failure— e.g. invalid workflow YAML, or a top-levelpermissions:block missingactions: read— the web UI shows a precise reason, for example:But that reason is not available through any public API. I verified this against a real
startup_failurerun:GET /repos/{o}/{r}/actions/runs/{id}conclusion: startup_failure, no message/error fieldGET /repos/{o}/{r}/actions/runs/{id}/jobstotal_count: 0GET /repos/{o}/{r}/actions/runs/{id}/logs404GET /repos/{o}/{r}/check-suites/{id}/check-runs(incl.?filter=all)total_count: 0checkSuite.checkRuns0Because the workflow file never parsed, no job or check run is ever created — so there is nothing for the API to return. The reason clearly exists server-side (the UI renders it), it's just not surfaced anywhere callable.
Why this matters
We run a GitHub App that listens for
check_suitecompleted events and posts a Slack alert onstartup_failure. We can link the run, but we can't tell the team why it failed — which is the single most useful piece of information. Reading the workflow file ourselves can't reproduce GitHub's exact parser error.Prior art
This was asked in 2023 in https://github.com/orgs/community/discussions/57536 and left unanswered — the only workaround offered was scraping the run page HTML, which is brittle and doesn't work for private repositories.
Request
Surface the startup-failure reason via the API — for example an
error/messagefield on the workflow run or check suite object, or an annotation reachable through the Checks API.Beta Was this translation helpful? Give feedback.
All reactions