Several times, our developers have cloned a Stash repo's corresponding Jenkins project when standing up a new software component's continuous integration cycle. Our Jenkins projects are configured to notify Stash upon completion. However, when cloning a Jenkins project, Jenkins often (always?) immediately runs a build, before the developer even finishes customizing the new project and saving the Jenkins project configuration. This results in pull requests on the original Stash repo getting stuck with a failed build from the new project. As far as I can tell, the only way to allow such a pull request to be merged is to have an admin uncheck the 'Require N or more successful builds' setting in the repo properties. I plan on following up on the Jenkins side to investigate why cloned projects kick off builds immediately, but the question remains - how can I remove a failed Jenkins build from a Stash pull request?
I have the same issue.
When looking at the build status keys Jenkins uses in the notifier (via REST API), i find the reason for this. The key contains the project name and jenkins root URL.
When a project is renamed or cloned in Jenkins, they do not match any more. Same if the server is renamed, relocated or if the configuration is tranferred to another Jenkins instance.
==> We definiely need at least a REST API for delete.
Have you checked the 'Keep repeated builds in Stash'?
That means the 'key' is going to have a build number - which means it will _always_ be unique.
This will result in separate builds in Stash every time - which is _not_ what you want.
In newer Stash versions you can change the destination branch if that helps. :)
There is an imprivement request related to it here:
For more information on how Atlassian implements new features and improvements please see the following document:
My apologies that I don't have a solution for you at this time.
As a really hacky workaround (and probably not recommended) you can edit the stash database. In my environment there is a table called AO_CFE8FA_BUILD_STATUS. I issued this command in mysql to change the bulid status:
update AO_CFE8FA_BUILD_STATUS set STATE='SUCCESSFUL' where url = 'http://yam:8080/job/GCSI%20Stash%20Verifier/222/';
While we don't recommend this (and please backup before you ever modify the DB directly), there isn't really any other way to remove the build statuses. They were intended to only ever be added or updated with a newer status.
We could probably add a REST endpoint for deleting them if it really becomes a problem, but personally it sounds like fixing Jenkins might be the better way to go. I'm surprised it's not disabling a cloned build by default, or something like that?
Did you manage to get anywhere with this?
Are you saying every build in Jenkins results in a _new_ build result in Stash? That's not how the feature was intended to work, and would mean that if the build ever fails you would _never_ be able to merge if you have that setting enabled.
The other short-term option BTW, would be to fake a successful build status via REST so that you continue. This isn't going to scale though if the failed build happens on every pull request though.
That is correct, you can _never_ merge if a build fails once. The only use case I can think of is if one would want the build to succeed in multiple environments before merging. However, I would expect my case to be more prevelant where the build fails because of environmental reasons and we want to build it again. However, there does not seem to be away to configure it my way.
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot