After diving into this post: Show current state of Jenkins build on GitHub repo
I still haven't found a way to show the current status of the build (last Jenkins run result) in every PR.
Meaning that every PR will show the status of the build and not just the specific commit that broke it.
This will make the team more aware of the build status and will prevent merging when the build is broken.
Related
We have a repo in BitBucket Server with "Minimum successful builds" merge check enabled and set to 1. When PR is opened the build starts and result of that build returns back to BitBucket.
Sometimes build fails (out of memory, etc) we run build again manually (without new commits). In that case PR contains two builds: first is "Failed" and the second is "Passed", but "Minimum successful builds" merge check still can't allow us to merge because it require to all builds be successful.
It is possible to check only last build be successful to allow PR merge?
So, the only solution I've found so far is changing the build name which Jenkins sends to Bitbucket. The main idea is that the build name must always be the same for that particular Pull Request. In that case, PR build name on Bitbucket is overridden each time when a new build of the PR starts by Jenkins.
In our case, I just removed Jenkins's BUILD_NUMBER from the build name, which it sent to Bitbucket.
The only drawback of that solution I've found is that you can only see last build status of the PR without any build history.
We have set a CI build for every Pull request. If a build fails for some reason, is there a way to re-initiate the build for the same PR.
You could simply re-run the failed build in pull request page under Policies, click queue build, such as below:
Just pay attention, do not directly re-run build with the same pipeline other than queue the build policy from PR page, it's a little difference here.
Queuing the build policy from PR page does a little more than just
rerunning a build. It first needs to check if the target branch has
moved and create a new merge commit if needed. In that case it will
queue a completely new build and not rerunning the existing one. In
addition, PR source branch could move and rerunning of the build on
old merge commit would have no effect on PR policy. So at this point
we do not see much value in investing in this scenario.
Source: Rerunning failed build doesn't always count towards PR
requirement
All our Jenkins jobs are configured to build changes on all branches in a repository. There are times where we want to re-run a specific build that ran against a specific commit.
a build fails because some external resource was unavailable and we want to re-run that commit once the resource is up again;
a job depends on an internal package and we need to be able to re-build specific branches to pick up the latest version of that package.
Jenkins' "Build Now" command, however, builds on the branch of the last build. It doesn't let the user choose what branch to build on. In order to rebuild a branch, users have to commit and push a change to that branch.
Is there a plugin that will allow the user to re-run a specific build or choose the branch to build on? If you've used TeamCity, I want the "Re-run with same revisions" feature.
We've tried both the Naginator and Rebuilder plugins. Naginator only lets you rebuild failed builds, but also automatically re-builds failed builds at least once (not desireable). Rebuilder always rebuilds the last commit. It behaves just like the "Build Now" button.
The Rebuild plugin is probably the closest plugin to what you want however as you have found it only will get HEAD and not a specific git revision.
This is an open feature request.
The comment on this question notes the same thing.
All that being so I would still suggest that you should perhaps reconsider the idea of depending on the git revision to drive the outcome of your build. You should want to build the HEAD.
Jenkins should notify bitbucket if a job that is linked to a branch has passed or falied, and it does:
But for some reason, in the branch view, it doesn't notify about the result of the last build, and says it failed even if the last build has passed:
How do I make it refer to the result of the last build only?
Today it was released a new version of the plugin for jenkins bitbucket-build-status-notifier which allows exactly what you need to avoid the problem you describe. It's new config option "Only show latest build status", just ensure this checkbox is checked and enjoy it.
Hi I'm the maintainer of the bitbucket-build-status-notifier for Jenkins. Actually the plugin creates a new build status for every jenkins build execution for a given commit. That means that if you exec a build for a given commit id and it failed and later exec a new build for the same commir id and success, both status success and failed will remain in bitbucket, that's find and not an issue. Anyways I understand your problem or desires and you are not the only one since there's already a issue
for solving it.
At the moment I've not much time for developing this new features but I'll do it as soon as possible.
We're using Jenkins with the Gerrit Trigger plugin so when a changeset is uploaded to Gerrit for review, Jenkins will check if it compiles and post the results.
The workflow happens like this:
A changeset is uploaded to Gerrit
A gerrit hook notifies Jenkins of the new changeset, giving Jenkins certain information such as the Gerrit changeset ID, patch number, target branch, etc.
Jenkins launches a build in the project that is configured to listen to this repository.
When the project is finished building, jenkins reports the result back to Gerrit if the build was successful or not, either +1 or -1. This information is used by the code reviewers in gerrit to help them decide to accept the changeset or not.
Problem: When these builds fail, the Jenkins project is marked "Failing" or "Unstable". This isn't exactly accurate, because the changes that caused the failure are not accepted or merged into the repository yet, they are just newly proposed.
One feature of Jenkins is that it will measure the health of a project based on the ratio of successful to failed builds. If the builds are all working, it will show a "sunshine" symbol but if some are failing then you get a "thundercloud". How do I configure Jenkins so that these verification builds don't affect the stability rating of the project? We need the status for the project to show "sunshine" if the commits that are approved from Gerrit and merged into the git repository builds, regardless of the outcome of builds from changes that are not merged (those changes in Gerrit still pending review). It's ok for the individual build to be red instead of green.
At $DAYJOB, we handle this by using 2 separate build jobs. A commit validation job, which posts +1/-1 on Gerrit changes and which we don't care about build stability. And a build stability/regression job, which runs builds that have already been merged where we do care about stability. We ignore the status color for the commit validation job.
I'm not aware of any way to get the Jenkins plugin to give a -1/+1 vote but always show a status of green. It uses that status when determining what score to give.