Repository navigation
Add --force flag to gh run cancel <run-id> #11073
Description
Activity
Thanks for submitting this, @stepankuzmin! 🙏
Not surprisingly, @BagToad brought this up in a recent conversation we had. I'm wondering if there's any issue/discussion in the past, because I couldn't find similar requests among our old issues. @BagToad, in case you know some issue, could you please link this to it?
I think this is actually a good suggestion.
So, I'm going to put down the A/C for it.Let's first discuss the experience. See my comment below.
Hey @babakks 👋
I've also tried to find any related information in the existing issues, but I didn't see anything.
Reacted by Babak K. ShandizBefore jumping to the A/C, I think we need to investigate the experience a bit more.
Currently,
gh run canceldoes not prompt for confirmation. But as of theforce-cancelendpoint docs:You should only use this endpoint to cancel a workflow run when the workflow run is not responding to POST /repos/{owner}/{repo}/actions/runs/{run_id}/cancel.
It's probably because force-cancelling a run might have side effects which wouldn't incur if the user goes through the ordinary cancel. So, I think at the CLI side, we should ask the user to confirm the forced cancel. And if there's a confirmation prompt, we might also want to have a way of bypassing it, e.g. with an extra
--yesoption to make it usable in automation use cases.So, the TLDR is we have these three options:
run cancel --forcedoes not prompt and works just like normal cancel.run cancel --forceprompts for confirmation.run cancel --forceprompts for confirmation, with an optional--yesflag for bypassing.
Out of these, I'm more into the 3rd option, but let's see what other folks think.
@BagToad @andyfeller @williammartin What are your thoughts?
Reacted by Stepan Kuzminrun cancel --forcewith an optional--yesflag looks good 👍Reacted by Babak K. ShandizThanks for pinging me on this @babakks ❤ I have been meaning to open an issue for this because it's a straightforward feature that only has API access right now. Thanks for opening this @stepankuzmin! It puts the CLI in a bit of a unique position to provide a better way to access this feature 😃
Now to the point, I actually don't want a
--yes. This is a double confirmation since the user has already told us they'd like to force it with--force.Another reason I'm not really worried is that the impact of a force-cancel is not that much different than a cancel. The difference in particular is that it overrides any conditionals in the workflow that may make it immune to a typical cancellation. The big one being the inclusion of
if: always()as a job condition which makes the workflow continue to run despite a cancellation.Most workflows will actually be cancellable without this flag, and besides most people are just running a straight API call to force cancel when they need to without really thinking about it, because they just want to cancel it.
And, the impact of an accidental job cancellation is contextual based on what a user is doing, but in general it simply means the workflow needs to be re-ran. It's not the end of the world, which is why we don't have a confirmation for a typical cancellation.
Reacted by Stepan KuzminAcceptance Criteria
-
Given I have a workflow run in progress
When I rungh run cancel --force <run-id>
Then the workflow run is force-cancelled using the GitHub API’s force-cancel endpoint -
When I run
gh run cancel --help
Then I see documentation for the--forceflag describing its use
Reacted by Stepan Kuzmin and Andrey Kozhev-
I'm working on this
Describe the feature or problem you’d like to solve
Sometimes, a workflow run could not respond to regular cancellation, so we should be able to force it as outlined in https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2022-11-28#force-cancel-a-workflow-run
Proposed solution
gh run cancel --force <run-id>Additional context
https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2022-11-28#force-cancel-a-workflow-run