Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Can a second pipeline deploy automatically cancel a previous one in progress?

Brendan Miller October 19, 2017

We have multiple developers working concurrently and make use of a development server to review the state of our application. 

We push to the "dev" branch to trigger a pipeline to deploy all approved changes to this server. This deploy triggers a new build of the current state of the app.

When we are developing rapidly there may be several deploys triggered concurrently which bogs down the deployments with redundant building.

How can we have the latest/most recent deploy automatically cancel previous deployments in progress?

Thank you.

7 answers

15 votes
Sufi Nawaz
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
January 20, 2020

There is absolutely a use case to stop all existing builds and only run latest build. This saves time and resources particularly since (at least in our case) we care about only the latest build. So I agree with @Jan Keller here in giving us the option to stop previous builds and prioritize and run only the latest build.

10 votes
Lorenzo Campanis
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
February 21, 2020

@Philip Hodder It is vital to be able to automatically cancel some builds of the same branch, so that the latest one can be built instead.

It's vital to avoid using build minutes for similar builds of same branches.

This option should allow to cancel builds per branch when the same branch's been pushed or merged. Say the develop branch which is constantly being built with merges to be canceled. Currently without this option everyone is forced to go in and cancel the previous build or use minutes for no reason.

An option to cancel same branch builds is a must and available in all CI tools.

We have migrated the lot now to BB Pipelines, but without this option minutes wil be exhausted very quickly.

Thanks

4 votes
Ernesto Serrano
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
July 2, 2018

Hello Brendan,

You can put this Python script in your repository and call it as first run step in your pipeline to achieve this. In my case I use a similar one but placed in AWS Lambda and call via curl

import os

BITBUCKET_USER = os.environ.get("BITBUCKET_USER")
BITBUCKET_KEY = os.environ.get("BITBUCKET_KEY")
BITBUCKET_REPO_OWNER = os.environ.get("BITBUCKET_REPO_OWNER")
BITBUCKET_REPO_SLUG = os.environ.get("BITBUCKET_REPO_SLUG")
BITBUCKET_BRANCH = os.environ.get("BITBUCKET_BRANCH")
BITBUCKET_COMMIT = os.envoron.get("BITBUCKET_COMMIT")

request_url = "https://api.bitbucket.org/2.0/repositories/%s/%s/pipelines/?sort=-created_on" % (BITBUCKET_REPO_OWNER, BITBUCKET_REPO_SLUG)
r = requests.get(request_url, auth=(BITBUCKET_USER, BITBUCKET_KEY))
result = r.json()
uuids = []
for value in result["values"]:
target = value.get("target")
if target.get("ref_name") == BITBUCKET_BRANCH:
type = value.get("state").get("type")
if type == "pipeline_state_in_progress" or type == "pipeline_state_pending":
if target.get("commit").get("type") == "commit":
if target.get("commit").get("hash") != BITBUCKET_COMMIT:
uuids.append(value.get("uuid"))
for uuid in uuids:
request_url = "https://api.bitbucket.org/2.0/repositories/%s/%s/pipelines/%s/stopPipeline" % (BITBUCKET_REPO_OWNER, BITBUCKET_REPO_SLUG, uuid)
response = requests.post(request_url, auth=(BITBUCKET_USER, BITBUCKET_KEY))
2 votes
Erkki Lepre
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
February 28, 2021

Here's a Node.js implementation for stopping previous pipeline executions. The script uses App Password with Pipeline Read & Write scopes.

const axios = require('axios');

const WORKSPACE = '';
const REPO_SLUG = '';
const BITBUCKET_USER = '';

const client = axios.create({
baseURL: 'https://api.bitbucket.org/2.0',
auth: {
username: BITBUCKET_USER,
password: process.env.BITBUCKET_APP_PASSWORD,
},
});

async function main() {
const branch = process.env.BITBUCKET_BRANCH;
const res = await client.get(`/repositories/${WORKSPACE}/${REPO_SLUG}/pipelines/?target.branch=${branch}&status=BUILDING&status=PENDING`);
if (res.data.values.length < 2) { // Skip if only one pipeline running
return;
}
const uuid = res.data.values[0].uuid;
await client.post(`/repositories/${WORKSPACE}/${REPO_SLUG}/pipelines/${uuid}/stopPipeline`);
}

main
()
Brigitte Bedard September 15, 2021

That would work if they hadn't implemented the feature to pause new deployments

Erkki Lepre
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
September 19, 2021

Aah, true. I missed the point, that this thread was specifically about deployments. This approach does work with normal pipelines.

Like Tyler T likes this
1 vote
Philip Hodder
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
October 25, 2017

Hello Brendan,

We'll be looking into ways to solve this problem natively in Pipelines later this year.

I suggest you following this ticket for updates: https://bitbucket.org/site/master/issues/12821/limit-concurrent-pipelines-so-deployment

In the meantime, if you need this functionality now, you can use the Bitbucket Pipelines REST API to construct a script that checks for other, more recent, running pipelines before deploying. 

Rest API documentation: https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Busername%7D/%7Brepo_slug%7D/pipelines

Thanks,

Phil

0 votes
Brigitte Bedard September 15, 2021

In our use case, this is a must.  Unless somebody has a not-so-complicated-solution, it would be nice to have the latest pipeline interrupt the current one.  This way, we be able to merge a series of PR, and deploy to our test server only on the last merge.  It has become such a waste of time for us. 

Two workarounds for now are

1) Changing the pipeline to manual.  OR

2) Disable the pipeline in the settings and re-enable it only for the last merge.

Both suck.  I agree that interrupting a pipeline could have potential problems in some cases, but in our case, it does not matter.  So having an option in the settings would make everybody happy.

0 votes
Philip Hodder
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
July 2, 2018

Bitbucket Pipelines now supports deployment concurrency. You can find more information here: https://bitbucket.org/site/master/issues/12821/limit-concurrent-pipelines-so-deployment?_ga=2.107981314.1848967244.1530489631-825437565.1515570924#comment-45346024

We've set it up to pause new deployments when a deployment is already running. Instead of the existing in progress one, as stopping a running deployment may leave environments in an inconsistent/broken state. Paused deployments may be manually resumed.

If you're interested in automatic deployment queueing, please follow the issue here: https://bitbucket.org/site/master/issues/16304/queuing-and-automatic-resuming-of-paused

Thanks

Brendan Miller July 2, 2018

It seems that the second deployment is paused and not resumed. This is not helpful in our case in which we are deploying from a branch to a given server and we want the LAST (latest) deployment to succeed, not an earlier one that may already be in progress that is missing the latest commits. Is that possible with this new feature?

Like # people like this
Philip Hodder
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
July 2, 2018

Not at the moment.

We decided not to automatically stop already running deployments as a deployment being stopped halfway unexpectedly would likely be a cause of issues for that deployment environment. Hence pausing newer ones instead.

We'd like to get a better understanding of use-cases before committing to a solution, as there's quite a few use-cases and edge-cases to consider.

Can you share with us on the queueing issue with any details about your deployment flow, number of deployments, number of them getting skipped, HOT fix procedure, etc. It would help us a lot. :) Our PMs will also provide updates on that ticket.

Jan Keller
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
July 28, 2018

How about a configuration option?

I see these three values for that option as relevant:

  • Current functionality. Pause the new deployment and run the previous to the end
  • Pause the new deployment, run the previous to the end, then run the new deployment
  • Stop the previous deployment and run the new deployment

And if there could be some sort of wait-period where a new deployment would cancel the previous one(s), I think it would solve a lot.

Like # people like this
Sayo Oladeji November 10, 2018

Giving us the ability to configure this would be nice, just like Travis.

Like # people like this
difelicea
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
April 6, 2020

Hi, was this functionality added already? Thanks.

Like Bence Knáb likes this
danijohnston
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
August 26, 2020

@Philip Hodder , I don't know if you're still looking for use cases for this. I agree with you that for deployments it's likely better to pause the newer ones to not leave things in a weird state.

My use case for stopping the older pipelines in favour of the newer pipelines going through is for PRs. If someone pushes a change to the branch before the first build is done, I don't really care about the test results for the old commit now, because it's been invalidated by a code change, I'd rather abort that pipeline and run the tests on the latest changes.

EDIT: I want to clarify that I wouldn't use this option if there was a deployment (e.g. a pipeline for master branch) but I would for pipelines that only have tests or builds (i.e. a PR pipeline). It really needs to be a configuration option rather than the default behaviour of pipelines.

Like # people like this
Noah Shipley
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
April 7, 2022

Is this issue still unsolved?

Sufi Nawaz
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
April 7, 2022

@Noah Shipley dont think so but also personally don’t care anymore. Have moved on from atlassian products :) all the best!

Like ken11zer01 likes this

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events