On .NET projects, I've used TeamCity and Subversion to run pre-checked builds.
For those unfamiliar with pre-checked builds, the idea is that when you commit, a build is run with your changeset against trunk.
If that build passes, then your changeset is applied to trunk. If it doesn't pass, you're notified and can try again.
That way, builds from trunk should always be green, and no-one else on the team is interrupted by build breakage.
My question is: has anyone achieved a similar workflow on a Ruby on Rails project, using Git and Jenkins (a.k.a. Hudson)? If so, could you please share some hints / tips / documentation?
You might want to have a look at a Jenkins/Gerrit combination. Gerrit is a code review system that you can setup so it will not push your commit to master unless your commit is approved. You can set it up so that Jenkins first has to approve it.
We are starting to use it for a C++ project where Jenkins first tries to build the patch, if it succeeds it is pushed to the main repo. This also doesn't stall git on the client side.
http://jenkins-ci.org/
https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger
To truely do this, you want to use a Git pre-receive hook. An excellent one (which runs PHP tests when code has been pushed) is detailed in: a blog post on codeutopia.net
However, the last sentence of the entry states:
it will cause the git push to be delayed until its completion.
Which is no fun if your test suite takes minutes to run, and seriously annoying when it takes 10 or 20 minutes (because git on the dev's machine will sit there and wait and not let go until the pre-receive hook exits).
Now, you may be able to write some sort of Hudson script to revert the failing commit when a build breaks. A former team experimented with such an idea, but never implemented it.
Related
I want to run(trigger) my jenkins job whenever a push happens to developer repository.
Firstly,
i'm storing all my automation scripts in my personal GitHub.
All of my developer's code is another GitHub, i.e in beanstalk which is top of GitHub
Now whenever dev's pushes their changes to their repository, then i want trigger my jenkins job which takes source code from my personal GitHub.
So, after some research on it, i came to know Webhooks will help in this.
Bu in my case as per their are two separate repositories, i couldn't able to get what exactly i have to do.
Any solution appreciated.
One of the solution, I can think of is you can build a WebHook and Git integration on your Dev's repository to trigger your Jenkins job, and in the build steps you can perform the check-out of your git repository source code using git commands.
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 :)
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.
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>]
We are using Jenkins,GerritTrigger setup for CI and it will start build for each commit though all commits came from single push. Since all changes are dependent on each other its enough to make a single build with all changes, but I don't see that option in GerritTrigger plugin.
I believe many companies use Jenkins and Gerrit combination and I am curious to know how they are handling these cases.
Example:
If a developer pushes below 4 commits at once to gerrit it will create 4 changes accordingly in gerrit say 1,2,3,4 and it starts 4 builds in jenkins for all commit
git log --oneline
e3dfdwd CommitD
5fgfdgh CommitC
df34dsf CommitB
a23sdr3 CommitA
Here 4 commits as a whole will pass all tests in jenkins but individually they will fail. Now jenkins builds will fail for A, B, C and will succeed for D as it will checkout A,B,C as they are its dependencies.
In this case though Commit-D is successful it can't be merged as its dependencies are not passed in Jenkins.
It seems reasonable from development to expect jenkins verification for each push instead of each commit. But GerritTrigger can run for each commit only.
Question:
Is there a way to inform jenkins to start build only for commit-D as it will have all dependencies C,B,A ??
Or can we start a build for each git push from development instead of commits?
Sorry if I had any info
I found a way to start build only for commit-D.
I have introduced a gerrittrigger job which runs immediately after every commit, this job will not do any clone/build/verification.
It will just do some set of verifications like, check if given change has needed-by change, dependency exists and dependencies on same branch etc
This job will trigger another main job which does real clone, checkout change, build, verification etc only for changes which pass all validations.
So this will start job always for top commit and approve/reject all dependent changes based on job result.
Though it has few limitations, we found this method is suitable for our workflow
Most companies don't use git and gerrit :) Most companies don't even use git, unfortunately. And most of the ones that do, don't use gerrit. I've consulted for dozens of companies: two use git, and neither of them have even heard of gerrit.
I don't think it's possible to get gerrit to think of pushes as if they were commits. Since each commit in a push can be separately reviewed and rejected, each commit has to be considered and built separately. If you don't want it to work that way, gerrit might not be for you.
Instead, you should squash your related commits locally before pushing them to gerrit. This will achieve the desired results.