Cancel a workflow in a job
T
Timothée GERMAIN
Be able to cancel the following jobs of a workflow would enable conditional workflows or at least, graceful early exit of workflow#You can avoid rebuilding everything with a large codebase/monorepo :let say you have a project with a frontend and a backend. You have a workflow for each and both are quite long to run.If you already have a tool to know which part you should build (by inspecting which files where changed by the commits you are building for instance) then you can gracefully stop the workflow that is not necessary (stop testing and building the whole backend when you only change the frontend)#You can have conditional notification :Let say you have a cleanup workflow which remove the very old versions of your application. You may not want to run the whole pipeline if you can tell in a early job if there is anything to do in the rest of the pipeline.With a cancel From a user perspective and IMHO this can be a command in circleci-cli like the
step halt
command which proxy a command to the circleci-agent.It might also be done once the workflow API is in place.I think a workflow which was canceled by such command should be marked as cancelled.Currently to mock that behavior I make my early step fail purposely to stop the rest of the pipeline. So I have notification of failed workflow even if the failure is "normal". Not ideal.CCI-I-856
T
Terri
We need this feature as well. Our use case is also monorepos and checking the commit to see if the commit changed files in a certain two folders. If not, we want to cancel the rest of the deploy workflow.
J
James Ovens
We also have a use case for this, one for dealing with monorepos and another for when our automated release tool that uses conventional commits to determine if a release is necessary.
In the second case if the release tool determines there were not any 'releasable changes' i.e. a documentation or test update then the tool will not trigger a formal release or tag in github however our workflow will continue to deploy out to Prod which is obviously not good.
Being able to conditionally run jobs would be ideal, but if not then being able to cancel or 'skip' jobs if they shouldn't happen would be great.
P
Pete Inge
I'd vote for this too. Personally, I can get what I need done by failing each individual job, however, this isn't ideal. Especially when the boss looks over my shoulder and see a lot of RED. Plus each job takes about a minute to spin up before I can check one boolean value to see if I should run. Seems highly inefficient.
The filters on jobs is nice, but my specific use case is we have have a few more conditionals based on branch names and open PRs and we would like to add in custom tags in the commit messages.
D
David Fant
This would be great. My current workaround is having a step in every job that checks if the relevant files have changed. If so, we continue that job.
Example usage:# ./exit-if-path-not-changed.sh path/to/dir1 path/to/dir2 # 1. Get all the arguments of the script# https://unix.stackexchange.com/a/197794PATHS_TO_SEARCH="$*"# 2. Get the latest commitLATEST_COMMIT=$(git rev-parse HEAD) # 3. Get the latest commit in the searched pathsLATEST_COMMIT_IN_PATH=$(git log -1 --format=format:%H --full-diff $PATHS_TO_SEARCH) if [ $LATEST_COMMIT != $LATEST_COMMIT_IN_PATH ]; then echo "Exiting this CircleCI job because code in the following paths have not changed:" echo $PATHS_TO_SEARCH circleci step haltfi
For reference:https://fant.io/p/circleci-early-exit
R
Roberto C. Morano
I tried the approach of self-cancelling the workflow so I don't need to make it fail, but got "Permission denied" from the API, so it seems it's just not supported :(