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.
Related
I could click Build Now to build a jenkins job again if the job is corresponded to a specific branch.
What if the job is related with multiple branches? That is, I utilized wildcard branch specifier.
When I click Build Now, it will rebuild the last build. I'm wondering if there is a way to rebuild those previous builds.
Yes you can rebuild any build with his own parameter.
1. Install rebuild plugin.
2. select the build that you want to rebuild and press rebuild.
enter image description here
My understanding of Jenkins is that, if you have a repo (say a Git repo) that is tied to a Jenkins build, a check-in will trigger a complete repo re-build. But if you have a number of applications as part of your repo, is there a way to limit which applications will rebuild in response to a check-in? If you make a change to one application, is there a way to set up your Jenkins build process to that that check-in triggers a rebuild of that application alone?
I'm sorry but your understanding is wrong... Jenkins and Git talk to each other using hooks and if these hooks are connected to your build, only then will they build the application/branch in your repo... So unless you have specified that everything must be built, then all the application will be built, otherwise the one you checked in ...will trigger only that build
If you want, you can create a new job and add the GIT SCM hook(during configuration) and do a check in, it will build only your project and any other project that is using the same hook- key point to note here :)
So if all your applications are building then you have a configuration issue
Hope this helps :)
I am using to Jenkins to pull code from git in every 10 minutes and then compiling, archiving it for other jobs to clone this workspace. Currently it's pulling code from git every time and then archiving every time.
I want to clone code from git only if there is any new change else it should skip and do not archive the workspace. Which plugin should I use and what configuration I should make in that?
So it sounds like you have a couple things going on here. Here is some possible suggestions that I use to meet similar needs:
1.) If you are only wanting your job to build when there is a change in your source control, in this case GIT, you can use the "Poll SCM" plugin. And then in there set a cron expression to run every 10 minutes.
"Poll SCM" plugin will check source control for any changes and build the job when it finds them. If this works properly your job will not build thus it will not archive anything unnecessarily.
2.) For archiving I would make sure to utilize the "Discard Old Builds" plugin and "Advanced" section to keep a rotation and retention policy for your jobs artifacts.
3.) You state "for other jobs to clone this workspace". Are you actually having other jobs pull in this jobs workspace? Or did you mean copy its artifacts? I ask because the workspace is temporary, in a sense, and you should pull the artifacts. There is a plugin for that as well called "Copy Artifact Plugin" that you can use and it allows for various options.
4.) An alternative to "Poll SCM" plugin, if it doesn't work or you do not prefer this, depending on your GIT setup you could also potentially setup a hook that will notify Jenkins of changes. There are various hooks depending on the GIT implementation.
Hope this helps!
I have a Jenkins job that includes an Android app and a common library. I use Jenkins' Multiple SCM plugin to download both git repos and then build and run.
The common library gets updated more frequently than the app, and sometimes these updates break compatibility with the App. When the App gets updated and committed, its generally guaranteed to have fixed any incompatibilities against the latest library version.
The jenkins job should trigger only for commits to the App. Under the common lib SCM, I have added "Don't trigger a build on commit notifications" as well as "Polling ignores commits from certain users" excluding "*".
However, this job still gets run when commits happen to the lib, resulting in a lot of broken build notifications. What am I doing wrong?
Thanks.
under SCM 'Advanced clone behaviors', select 'Polling ignores commits in certain paths' and set 'Excluded Regions' to '.*'
Maybe it's better to switch from polling to post-commit hook, like described here?
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.