- Comments: #180
- Proposed by: @lotas
Allow to automatically cancel previous pipelines for github and push
pull_request
events.
This will allow to save computing resources and give more flexibility for the Taskcluster users on Github. When several pushes happen to the same branch within a short amount of time, like hotfixes or rebases, only the last commit and pipelines matters. By cancelling previous task groups and tasks we could save significant amount of compute resources and developer hours by not running redundant tasks.
This will only apply to non-default branches (and possible protected branches?), to allow all pushes to the default branch to have their own builds.
To be flexible and allow some projects to still run checks for all events, we could add new key to the .taskcluster.yml
configuration.
We can introduce top-level configuration option autoCancelPreviousChecks: true
(having true
by default) to control if this behaviour is desired.
Github's webhook handler upon receiving
If push
event would check if there are other task groups existing for given branch, that are not HEAD.autoCancelPreviousChecks
is set to true
it will cancel them.
Cancellation will happen for all the non-resolved tasks within the same taskGroupId
. However, due to the fact that tasks can create their own sub-tasks, there might be cases where running tasks would still manage to create some tasks that might not be cancelled.
To make it easier for developers to cancel running builds associated with some specific branch we can expose new API endpoint. github.cancelBuilds({ organization, repository, branch })
would be able to find all task groups associated with this branch, find all non-resolved tasks within those groups and cancel those.
- Original request issue #5621
Due to the bug #6616 it was decided that push
events would not be handled.
Only pull_request
events to cancel builds for the same pull request.
This is because same commit may belong to different branches like main
, production
, staging
, etc.
And to keep configuration simple we decided to only handle pull_request
events.