From ce913b7cc28ab5324dcab6a0f1352392523b16e6 Mon Sep 17 00:00:00 2001 From: ayushman1210 Date: Fri, 21 Nov 2025 20:41:13 +0530 Subject: [PATCH] fix the changes --- .../approve-runs-from-forks.md | 2 + .../cancel-a-workflow-run.md | 2 + .../how-tos/manage-workflow-runs/index.md | 2 + .../manually-run-a-workflow.md | 2 + .../re-run-workflows-and-jobs.md | 2 + .../skip-workflow-runs.md | 2 + content/rest/actions/workflow-runs.md | 2 + .../actions/workflow-run-statuses-2.md | 39 ++++++++++++++++++ .../actions/workflow-run-statuses.md | 40 +++++++++++++++++++ 9 files changed, 93 insertions(+) create mode 100644 data/reusables/actions/workflow-run-statuses-2.md create mode 100644 data/reusables/actions/workflow-run-statuses.md diff --git a/content/actions/how-tos/manage-workflow-runs/approve-runs-from-forks.md b/content/actions/how-tos/manage-workflow-runs/approve-runs-from-forks.md index 6d93ce7cf4a0..3f42d8483711 100644 --- a/content/actions/how-tos/manage-workflow-runs/approve-runs-from-forks.md +++ b/content/actions/how-tos/manage-workflow-runs/approve-runs-from-forks.md @@ -16,6 +16,8 @@ redirect_from: - /actions/managing-workflow-runs-and-deployments/managing-workflow-runs/approving-workflow-runs-from-private-forks --- +{% data reusables.actions.workflow-run-statuses-2 %} + Workflow runs triggered by a contributor's pull request from a fork may require manual approval from a maintainer with write access. You can configure workflow approval requirements for a [repository](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#configuring-required-approval-for-workflows-from-public-forks), [organization](/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#configuring-required-approval-for-workflows-from-public-forks), or [enterprise](/enterprise-cloud@latest/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#enforcing-a-policy-for-fork-pull-requests-in-your-enterprise). Workflow runs that have been awaiting approval for more than 30 days are automatically deleted. diff --git a/content/actions/how-tos/manage-workflow-runs/cancel-a-workflow-run.md b/content/actions/how-tos/manage-workflow-runs/cancel-a-workflow-run.md index a22caa621776..bb3d0a49fd88 100644 --- a/content/actions/how-tos/manage-workflow-runs/cancel-a-workflow-run.md +++ b/content/actions/how-tos/manage-workflow-runs/cancel-a-workflow-run.md @@ -13,6 +13,8 @@ redirect_from: - /actions/how-tos/managing-workflow-runs-and-deployments/managing-workflow-runs/canceling-a-workflow --- +{% data reusables.actions.workflow-run-statuses-2 %} + ## Canceling a workflow run {% data reusables.repositories.navigate-to-repo %} diff --git a/content/actions/how-tos/manage-workflow-runs/index.md b/content/actions/how-tos/manage-workflow-runs/index.md index 7e2041373eff..459689b31ca8 100644 --- a/content/actions/how-tos/manage-workflow-runs/index.md +++ b/content/actions/how-tos/manage-workflow-runs/index.md @@ -29,3 +29,5 @@ redirect_from: - /actions/how-tos/managing-workflow-runs-and-deployments/managing-workflow-runs - /actions/how-tos/managing-workflow-runs-and-deployments --- + +{% data reusables.actions.workflow-run-statuses-2 %} diff --git a/content/actions/how-tos/manage-workflow-runs/manually-run-a-workflow.md b/content/actions/how-tos/manage-workflow-runs/manually-run-a-workflow.md index a84ae5173b48..678390e2df0e 100644 --- a/content/actions/how-tos/manage-workflow-runs/manually-run-a-workflow.md +++ b/content/actions/how-tos/manage-workflow-runs/manually-run-a-workflow.md @@ -14,6 +14,8 @@ redirect_from: - /actions/how-tos/managing-workflow-runs-and-deployments/managing-workflow-runs/manually-running-a-workflow --- +{% data reusables.actions.workflow-run-statuses-2 %} + {% data reusables.actions.enterprise-github-hosted-runners %} ## Configuring a workflow to run manually diff --git a/content/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs.md b/content/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs.md index 1a4d8f3c96b2..f1e5ec44ecb8 100644 --- a/content/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs.md +++ b/content/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs.md @@ -14,6 +14,8 @@ versions: ghec: '*' --- +{% data reusables.actions.workflow-run-statuses-2 %} + > [!NOTE] > Re-run workflows use the privileges of the actor who initially triggered the workflow, not the privileges of the actor who initiated the re-run. The workflow will also use the same `GITHUB_SHA` (commit SHA) and `GITHUB_REF` (git ref) of the original event that triggered the workflow run. diff --git a/content/actions/how-tos/manage-workflow-runs/skip-workflow-runs.md b/content/actions/how-tos/manage-workflow-runs/skip-workflow-runs.md index 759d8ef7ad28..c7fca6688341 100644 --- a/content/actions/how-tos/manage-workflow-runs/skip-workflow-runs.md +++ b/content/actions/how-tos/manage-workflow-runs/skip-workflow-runs.md @@ -12,6 +12,8 @@ redirect_from: - /actions/how-tos/managing-workflow-runs-and-deployments/managing-workflow-runs/skipping-workflow-runs --- +{% data reusables.actions.workflow-run-statuses-2 %} + {% data reusables.actions.enterprise-github-hosted-runners %} > [!NOTE] diff --git a/content/rest/actions/workflow-runs.md b/content/rest/actions/workflow-runs.md index d6d01bcb05ab..e0358adcb2c8 100644 --- a/content/rest/actions/workflow-runs.md +++ b/content/rest/actions/workflow-runs.md @@ -18,4 +18,6 @@ autogenerated: rest You can use the REST API to view, re-run, cancel, and view logs for workflow runs in {% data variables.product.prodname_actions %}. {% data reusables.actions.about-workflow-runs %} For more information, see [AUTOTITLE](/actions/managing-workflow-runs). +{% data reusables.actions.workflow-run-statuses-2 %} + diff --git a/data/reusables/actions/workflow-run-statuses-2.md b/data/reusables/actions/workflow-run-statuses-2.md new file mode 100644 index 000000000000..9d6bd1aa797e --- /dev/null +++ b/data/reusables/actions/workflow-run-statuses-2.md @@ -0,0 +1,39 @@ +Below are common `status` and `conclusion` values you may see for workflow runs, check runs, and jobs, with an explanation and typical use cases. Use these as a reference when interpreting results returned by the REST and Checks APIs. + + +**Quick summary:** +- **`status`**: the current lifecycle state of the run or job (for example: `queued`, `in_progress`, `completed`). +- **`conclusion`**: the final outcome when `status` is `completed` (for example: `success`, `failure`, `neutral`, `cancelled`). + +**Common `status` values and meaning** +- **`queued`**: The run or job has been scheduled and is waiting for a runner to pick it up (waiting for available runner resources). +- **`requested`**: The run or check run has been requested (for example, by an app or integration) and is awaiting scheduling; it is a precursor to `queued` in some APIs. +- **`waiting`**: The run/job is blocked and waiting on an external gate (for example: a required environment approval, manual intervention, or a required reviewer). This state often indicates human or policy action is needed before the job can proceed. +- **`in_progress`**: The run or job is actively executing on a runner. +- **`completed`**: Execution has finished — look at `conclusion` for the outcome. + +**Common `conclusion` values (apply when `status` is `completed`)** +- **`success`**: The run completed successfully. +- **`failure`**: The run failed (one or more failing jobs or checks). +- **`neutral`**: The run completed without a success *or* failure being attributed to it — typically used for informational or non-blocking runs/checks (for example, a lint job that reports results but is configured not to fail the workflow). +- **`cancelled`**: The run was canceled by a user or system action before completion. +- **`skipped`**: The run or job was intentionally skipped (for example, conditionals prevented the job from running). +- **`timed_out`**: The run or job exceeded the allowed time limit and was aborted. +- **`action_required`**: The run finished in a state that requires human action to continue (for example: environment protection rules require approval to proceed or a required review was not completed). This is an actionable state signalling manual intervention is necessary. +- **`stale`**: The run or check is considered out-of-date or no longer relevant (for example, a later commit was pushed that supersedes this run). Behavior may vary by API — often used by the Checks API to indicate a run that no longer applies to the current commit. + +State diagram (linear flow, simplified): + +`requested` -> `queued` -> `in_progress` -> `completed` -> `conclusion` (one of `success`, `failure`, `neutral`, `cancelled`, `skipped`, `timed_out`, `action_required`, `stale`) + +Notes on overlapping terms: +- **`pending` vs `queued` vs `requested`**: Different APIs and contexts sometimes use slightly different words for similar queueing states. `requested` is often the earliest state (a run was requested), `queued` means the run is in the runner queue, and `pending` is a generic term used by the Statuses API to mean the result is not yet available. Treat these as queue/pending states that precede `in_progress`. +- **`waiting`**: Typically indicates the run/job is blocked by an external requirement (manual approval, environment protection, required reviewers). A `waiting` state may appear instead of `queued` when the job cannot be scheduled until the blocking condition is resolved. +- **`action_required`**: Although listed as a `conclusion` value in some API responses, this value indicates the run cannot progress or be considered fully successful until a person performs a required action (for example granting an environment approval). Consider it a terminal-but-actionable conclusion. + +Usage guidance +- When inspecting a workflow run object from the REST API: check `status` first. If `status` is `completed`, read `conclusion` to determine the final outcome. +- For UI or automation that responds to runs, treat `neutral` as a completed but non-failing outcome and treat `action_required` and `waiting` as requiring human attention before considering a job fully resolved. +- If you need definitive behaviour for a particular webhook or API (for example, whether `stale` should be treated as failure or ignored), consult the specific endpoint docs or test against the API in your environment — some conclusion values are used differently between the Checks API and the Workflow Runs API. + +If you'd like, I can produce a more detailed Checks API vs Workflow Runs API appendix or adjust wording for a specific audience. diff --git a/data/reusables/actions/workflow-run-statuses.md b/data/reusables/actions/workflow-run-statuses.md new file mode 100644 index 000000000000..5e13ac8fb1ff --- /dev/null +++ b/data/reusables/actions/workflow-run-statuses.md @@ -0,0 +1,40 @@ +```markdown +Below are common `status` and `conclusion` values you may see for workflow runs, check runs, and jobs, with an explanation and typical use cases. Use these as a reference when interpreting results returned by the REST and Checks APIs. + +**Quick summary:** +- **`status`**: the current lifecycle state of the run or job (for example: `queued`, `in_progress`, `completed`). +- **`conclusion`**: the final outcome when `status` is `completed` (for example: `success`, `failure`, `neutral`, `cancelled`). + +**Common `status` values and meaning** +- **`queued`**: The run or job has been scheduled and is waiting for a runner to pick it up (waiting for available runner resources). +- **`requested`**: The run or check run has been requested (for example, by an app or integration) and is awaiting scheduling; it is a precursor to `queued` in some APIs. +- **`waiting`**: The run/job is blocked and waiting on an external gate (for example: a required environment approval, manual intervention, or a required reviewer). This state often indicates human or policy action is needed before the job can proceed. +- **`in_progress`**: The run or job is actively executing on a runner. +- **`completed`**: Execution has finished — look at `conclusion` for the outcome. + +**Common `conclusion` values (apply when `status` is `completed`)** +- **`success`**: The run completed successfully. +- **`failure`**: The run failed (one or more failing jobs or checks). +- **`neutral`**: The run completed without a success *or* failure being attributed to it — typically used for informational or non-blocking runs/checks (for example, a lint job that reports results but is configured not to fail the workflow). +- **`cancelled`**: The run was canceled by a user or system action before completion. +- **`skipped`**: The run or job was intentionally skipped (for example, conditionals prevented the job from running). +- **`timed_out`**: The run or job exceeded the allowed time limit and was aborted. +- **`action_required`**: The run finished in a state that requires human action to continue (for example: environment protection rules require approval to proceed or a required review was not completed). This is an actionable state signalling manual intervention is necessary. +- **`stale`**: The run or check is considered out-of-date or no longer relevant (for example, a later commit was pushed that supersedes this run). Behavior may vary by API — often used by the Checks API to indicate a run that no longer applies to the current commit. + +State diagram (linear flow, simplified): + +`requested` -> `queued` -> `in_progress` -> `completed` -> `conclusion` (one of `success`, `failure`, `neutral`, `cancelled`, `skipped`, `timed_out`, `action_required`, `stale`) + +Notes on overlapping terms: +- **`pending` vs `queued` vs `requested`**: Different APIs and contexts sometimes use slightly different words for similar queueing states. `requested` is often the earliest state (a run was requested), `queued` means the run is in the runner queue, and `pending` is a generic term used by the Statuses API to mean the result is not yet available. Treat these as queue/pending states that precede `in_progress`. +- **`waiting`**: Typically indicates the run/job is blocked by an external requirement (manual approval, environment protection, required reviewers). A `waiting` state may appear instead of `queued` when the job cannot be scheduled until the blocking condition is resolved. +- **`action_required`**: Although listed as a `conclusion` value in some API responses, this value indicates the run cannot progress or be considered fully successful until a person performs a required action (for example granting an environment approval). Consider it a terminal-but-actionable conclusion. + +Usage guidance +- When inspecting a workflow run object from the REST API: check `status` first. If `status` is `completed`, read `conclusion` to determine the final outcome. +- For UI or automation that responds to runs, treat `neutral` as a completed but non-failing outcome and treat `action_required` and `waiting` as requiring human attention before considering a job fully resolved. +- If you need definitive behaviour for a particular webhook or API (for example, whether `stale` should be treated as failure or ignored), consult the specific endpoint docs or test against the API in your environment — some conclusion values are used differently between the Checks API and the Workflow Runs API. + +If you'd like, I can also add a small diagram image or a more detailed job-by-job mapping for the Checks API vs Workflow Runs API. +```