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.
Related
I have installed- https://plugins.jenkins.io/changes-since-last-success/ in my jenkins. But now, when my build has failed then the commits done for that particular build are not visible in the next successful build.
I can't see this changes since last success option in UI-
Am I required to do anything else other than this plugin installation. I mean do I have to perform any configuration to use it or make it work?
Your answer will help me a lot.
I know that a build had run for a Jenkins job (I received an e-mail with the results and the build number #9).
But, when I open Jenkins to check the Build History, the build in question (Build #9) is not there. When I try to trigger a new build, it is counted as Build #10. So, somebody must have deleted Build #9 manually from Jenkins (my guess).
If yes, how do I get the details of the user who deleted that build?
Is there a log I can refer to?
Do you have the Jenkins Audit Trail Plugin installed?
You can use it to keep an audit of "most actions with significant effect such as creating/configuring/deleting jobs and views or delete/save-forever/start a build".
So it looks like the example you gave of deleting a build would be covered.
See https://wiki.jenkins.io/display/JENKINS/Audit+Trail+Plugin
The Job Configuration History plugin will keep track of all changes (delta+user) AND let you roll back, but only after you install it.
I try to configure Jenkins. I want a simple behavior: trigger a build on new pull request.
I cannot understand what I missed...
Jenkins version: 2.89.2
At https://ci.mysite.fr/configure :
Still no build triggered:
At https://ci.mysite.fr/job/test-back/configure :
On Github, Webhook is sent and well received by Jenkins:
Nginx Log says the same:
Help please!
Some things to check when debugging this sort of thing:
Check your Jenkins logs to see whether or not Jenkins is receiving the hook and deciding not to take action for some reason.
Check Jenkins security by clicking Manage Jenkins -> Configure Global Security. Open things up as much as you're comfortable doing and see if that changes anything.
Ensure that you're pushing changes to the master branch. For simplification, consider using ** as your branch specifier while you're getting this to work.
Ensure Git is properly configured on your Jenkins host by clicking Manage Jenkins -> Global Tool Configuration
Make sure the user whose credentials you provided can manage hooks and pull from the repo you're interested in.
Run the job manually in Jenkins, ensure that it works.
After you run the job, it should show up as an option in Protected Branches/Required Statuses. In your repo, click on Settings->Branches, select your branch in the Branches section, click Require Status Check to Pass before merging option, and your job should show up in the list which appears.
Webhooks are arguably the most difficult Jenkins feature to test without prior experience, because of gotchas like these (probably their list is incomplete):
New git commit / git push must be made for each pipeline build (repeating a previous one won't trigger a new build even if webhooks are already set up correctly - see below).
First build made after setting up webhook correctly must be manual (no bootstrap from the webhook itself is possible).
First build made after setting webhook correctly must succeed completely for the changes to take effect and for webhooks to start working. This will also cause Jenkins to miss all incoming requests made during the first build of a newly created pipeline.
More info
Please be warned that it is not possible to trigger a build using the same build conditions again (at least using a webhook). Therefore you might have a correct webhook setup already, but not find out that it works unless you create a new git commit and push it to the remote repo on Github. If your try to repeat some old push over and over again, by simply pressing the "Redeliver" button in the Recent deliveries section on Github's Webhooks / Manage webhook page, Jenkins will never move beyond the "poke" repo stage, as it requires SCM changes to be detected in order to trigger a new build:
Received PushEvent for https://github.com/mirekphd/<REPO_NAME> from <GITHUB_IP> ⇒ <JENKINS_URL>/github-webhook/
Apr 16, 2021 9:42:12 PM INFO org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber$1 run
Poked <REPO_NAME>
Apr 16, 2021 9:42:13 PM INFO com.cloudbees.jenkins.GitHubPushTrigger$1 run
SCM changes detected in <REPO_NAME>. Triggering #236
For further info on points 2) and 3): see original source.
I'm trying to add some very basic functionality that exists in every other modern ci product, but which unfortunately seems to be a completely foreign concept in Jenkins land.
I have the github plugin hooked up, and the git plugin set to build the "inverse" of "origin/master", so that pushing any branch except master triggers a build.
The problem is, if there's a flaky test and the build fails there's no way to restart it in jenkins. I added the Naginator plugin but it rebuilds the last branch that ran, not the branch of the build that you clicked "retry" on. Using the Naginator plugin, it seems that I need the git branch or sha to be a real parameter of the build. But, I can't find a way to set the git branch as a parameter of the build when a build gets triggered.
The only thing I can think of is to split it into two builds that link to the same git repo, and have the second one be a parameterized build that the first one triggers with the GIT_COMMIT value as the parameter. Then, retrying the second one with Naginator should retry it on the same SHA. This isn't a good solution though, it sucks to have to configure 2 builds for every one of my builds.
Does anyone know of a good way to accomplish this? I'm hoping I'm just missing something simple.
Unfortunately i'm unfamiliar with this exact setup, however the Git plugin documentation, section Push notification from repository, mentions that in the trigger url, the <commit ID is optional. If set, it will trigger a build immediately, without polling for changes.
If there is a built-in "button" in some plugin to issue this manually from inside jenkins UI i don't know, if not that could be a nice feature request.
So, if there really is no easy option aviable yet, as a workaround you could write yourself some script which builds and calls the url for a given branch + commit ID.
Trigger url format, as found in Git Plugin docs:
curl http://yourserver/git/notifyCommit?url=<URL of the Git repository>&branches=branch1[,branch2]*][&sha1=<commit ID>]
Is there any way in jenkins where as soon as we detect the failed build, job revert back the perforce code to the last successful build changelist and fire a build again.
Flow -
1. so as soon as we have failed build - Notifcation will be sent out to dev team with possible checkins which causing the build failure
Revert back the recent code to the last working code and submit it
Initiate a build.
It is possible, but I don't see any reasons or use case to do it as it is not a correct workflow and can be confusing.
But if you decided to do it, the next steps are required:
Example how to do it using Perforce source control.
Steps inside job settings:
Before build triggers you need to save latest changelist number $P4_CHANGELIST - 1
Perforce plugin for Jenkins: Perforce plugin for Jenkins
Build
Get last error code
Get last error code from the: batch
If code != 0 then checkout and build changelsit $P4_CHANGELIST - 1
Jenkins is not a production server. It runs tasks and do not have options that I know for that purpose.
What is your source code ? webapps ? others ?
What steps are you performing ?
Are you performing some automatic tests ?
My assumption is that you got some tests that may invalidate the build.
These tests should be runned :
* on a mock server to prevent deploying on your server
* or somewhere else
Like that, if build failed, nothing is deployed.
If build success, you can deploy your project normally.
If this not reply to your answer, please provide requested information to undestrand a bit more your job process.
If your using an artifact repository like Nexus or Artifactory to manage your project artifacts then you could always redeploy the previous working version of your application when a failure is detected.
Your not cancelling any checked in code that potentially broke the build but you are preserving your test environment. You can configure Jenkins to notify the user who checked in the latest erroneous change set and they can work on resolving the issue.
Jenkins also provides a rich API which allows you to delete a job, start a job, get information about previously run jobs. You could leverage some of these services along with your artifact repo to achieve the experience you described.