Document workflow run statuses and conclusions

[bm1016bm-svg]

GitHub Copilot generated this pull request.

Note

This pull request should have the llm-generated label. External contributors do not have permission to add labels to this repository.

Why:

Closes: #34987

The issue is labeled help wanted and SME reviewed; the Actions SME requested a new reference article defining workflow run statuses and conclusions, linked from the REST API documentation.

What's being changed:

• Adds a focused workflow run status and conclusion reference article.
• Adds the article to the workflows and actions reference navigation.
• Links to the article from the manually maintained introduction to the workflow runs REST API page.
• Separates the six status values from the nine conclusion values exposed by the current workflow_run webhook schema.
• Calls out that startup_failure is a webhook conclusion but is not accepted by the workflow run list endpoints' status filter.

This builds on the useful direction in #44984 by @happysnaker. It preserves the existing frontmatter formatting requested in that pull request's review and removes speculative "typical use case" claims that are not established by the public schema.

Technical values were checked against the current workflow run REST endpoint documentation and the workflow_run webhook schema in this repository.

Verification:

• npm run lint-content -- --paths content/actions/reference/workflows-and-actions/index.md content/actions/reference/workflows-and-actions/workflow-run-statuses.md content/rest/actions/workflow-runs.md — no errors.
• npm run build — passed.
• CHANGED_FILES="content/actions/reference/workflows-and-actions/index.md content/actions/reference/workflows-and-actions/workflow-run-statuses.md content/rest/actions/workflow-runs.md" npm run test -- src/content-render/tests/render-changed-and-deleted-files.ts — 1 test file and 2 tests passed.

Check off the following:

• A subject matter expert (SME) has reviewed the technical accuracy of the content in this PR. In most cases, the author can be the SME. Open source contributions may require an SME review from GitHub staff.
• The changes in this PR meet the docs fundamentals that are required for all content.
• All CI checks are passing and the changes look good in the review environment.

[github-actions]

How to review these changes 👓

Thank you for your contribution. To review these changes, choose one of the following options:

• Spin up a codespace
• Set up a local development environment

A Hubber will need to deploy your changes internally to review.

Table of review links

Note: Please update the URL for your staging server or codespace.

The table shows the files in the content directory that were changed in this pull request. This helps you review your changes on a staging server. Changes to the data directory are not included in this table.

Source	Review	Production	What Changed
actions/reference/workflows-and-actions/index.md	fpt ghec ghes@ 3.21 3.20 3.19 3.18 3.17	fpt ghec ghes@ 3.21 3.20 3.19 3.18 3.17
New file: actions/reference/workflows-and-actions/workflow-run-statuses.md	fpt ghec ghes@ 3.21 3.20 3.19 3.18 3.17	fpt ghec ghes@ 3.21 3.20 3.19 3.18 3.17
rest/actions/workflow-runs.md	fpt ghec ghes@ 3.21 3.20 3.19 3.18 3.17	fpt ghec ghes@ 3.21 3.20 3.19 3.18 3.17

Key: fpt: Free, Pro, Team; ghec: GitHub Enterprise Cloud; ghes: GitHub Enterprise Server

🤖 This comment is automatically generated.

[TheDarkniteFalls]

Thanks for taking this on. I compared the draft with the specific questions in #34987 and the current Actions and Checks references. The article shape and three-file scope look right. Three bounded additions/corrections would close the remaining gaps:

1. Please address the reported queued -> in_progress -> queued -> completed sequence. A status is a current snapshot, not a transition history. A re-run keeps the workflow run ID and increments run_attempt, so readers should compare the attempt first; if it did not change, the logs and related check runs are the evidence to inspect because status alone does not give a reason for the transition.
2. Please make the evidence and object boundaries explicit: conclusion is null until completion, and workflow runs, check suites, check runs, and commit statuses do not share one universal state set. In particular, the existing Checks documentation defines startup_failure for check-suite startup (not individual check runs) and defines stale for an incomplete check run.
3. I suggest changing “is not an accepted value” to “is not listed as an accepted value” unless endpoint behavior has been tested or a source establishes rejection. The REST reference documents the filter list; omission alone does not prove how the endpoint rejects or handles the value.

These points preserve the concise reference format while answering the issue's transition and property-delineation requests.