Generally jenkins builds the code with the latest commit.Suppose in a build multiple commits have taken place.What I want is the list of commits that have been incorporated in the build.
Does anyone have a solution for this??
If you press changes in a job, you should get a list of all the commits that are new for each build of that job.
Related
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.
In part of our testing setup we are build our artifacts needed and then copying a template job and settings its name so it recognizable.
Build artifact -> copy test template -> ending with a job for each
test case
that means i'm ending up with lots of jobs with Test_Client${BRANCHNAME}_Server${BRANCHNAME}
I'm running through these jobs alot while testing that branch, but as soon as it's merged it's not going to be touched again, which is why i would like to create a job of sorts that simply deletes the jobs that havn't been run for the 14 days or so.
Does anyone know a way of doing this? and not just cleaning out the workspace.
Thanks!
It may be a big change, but this is an ideal case for the Multibranch pipeline.
On one project, we have a master branch and version branches. The developers branch to short-lived feature branches or other branching purposes. As the branches are created and pushed to github, the multibranch job picks them up and starts building them. Developers get quick feedback that the changes will pass the build. When they merge them to master or to a version branch, then delete the branch, the multibranch job goes away.
I want to build limited set of Jenkins branches master develop release* hotfix* using Jenkins Github Organization Folder plugin.
The problem is that once I add the filter for the list of branches to build to master develop release* hotfix* Jenkins stops building PRs.
It does work as expected for these branches but I does not pull PRs made against them and this is mandatory as we want to be able to merge only code that was executed by Jenkins, but without having to include the source branches in the normal list of builds (we don't want to build each feature branch as they can get lots and lots of changes.)
After two weeks and lots and lots of tests I finally raised a bug
https://issues.jenkins-ci.org/browse/JENKINS-36352
This seems to be a bug so far.
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!
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.