Improve description of cancellation process in workflow documentation#44242
Improve description of cancellation process in workflow documentation#44242MTomBosch wants to merge 1 commit into
Conversation
How to review these changes 👓Thank you for your contribution. To review these changes, choose one of the following options: A Hubber will need to deploy your changes internally to review. Table of review linksNote: Please update the URL for your staging server or codespace. The table shows the files in the
Key: fpt: Free, Pro, Team; ghec: GitHub Enterprise Cloud; ghes: GitHub Enterprise Server 🤖 This comment is automatically generated. |
There was a problem hiding this comment.
Pull request overview
Clarifies the workflow cancellation timeline by specifying that only jobs selected for cancellation are forcibly terminated after the cancellation timeout, improving reader understanding of what gets killed vs. what can continue running.
Changes:
- Refines the final step to specify that forced termination applies to jobs targeted for cancellation (and any remaining running steps).
| 1. For jobs that continue to run, the server re-evaluates `if` conditions for the unfinished steps. If the condition evaluates to `true`, the step continues to run. You can use the `cancelled` expression to apply a status check of `cancelled()`. For more information, see [AUTOTITLE](/actions/reference/evaluate-expressions-in-workflows-and-actions#cancelled). | ||
| 1. For steps that need to be canceled, the runner machine sends `SIGINT/Ctrl-C` to the step's entry process (`node` for JavaScript actions, `docker` for container actions, and `bash/cmd/pwd` when using `run` in a step). If the process doesn't exit within 7500 ms, the runner will send `SIGTERM/Ctrl-Break` to the process, then wait for 2500 ms for the process to exit. If the process is still running, the runner kills the process tree. | ||
| 1. After the 5 minute cancellation timeout period, the server will forcibly terminate all jobs and steps that are still running. | ||
| 1. After the 5 minute cancellation timeout period, the server will forcibly terminate all jobs (marked in step 1 to be canceled) and steps that are still running. |
| 1. For jobs that continue to run, the server re-evaluates `if` conditions for the unfinished steps. If the condition evaluates to `true`, the step continues to run. You can use the `cancelled` expression to apply a status check of `cancelled()`. For more information, see [AUTOTITLE](/actions/reference/evaluate-expressions-in-workflows-and-actions#cancelled). | ||
| 1. For steps that need to be canceled, the runner machine sends `SIGINT/Ctrl-C` to the step's entry process (`node` for JavaScript actions, `docker` for container actions, and `bash/cmd/pwd` when using `run` in a step). If the process doesn't exit within 7500 ms, the runner will send `SIGTERM/Ctrl-Break` to the process, then wait for 2500 ms for the process to exit. If the process is still running, the runner kills the process tree. | ||
| 1. After the 5 minute cancellation timeout period, the server will forcibly terminate all jobs and steps that are still running. | ||
| 1. After the 5 minute cancellation timeout period, the server will forcibly terminate all jobs (marked in step 1 to be canceled) and steps that are still running. |
Why:
Current description is not clear enough about the question which jobs are forcibly terminated after 5 minutes.
The new description makes it more clear.
Closes:
What's being changed (if available, include any code snippets, screenshots, or gifs):
Check off the following: