2

I got a request from the man upstairs to setup Jenkins for Pretested commit (through a build at Jenkins, if all unit tests and other pass then commit it and build a dist). We're using svn here.

Is anyone clear about how this can be done with Jenkins? I am finding next to no information on it.

Slamice
  • 123
  • 1
  • 4

3 Answers3

3

Sorry to say that, but that's just not the way you use revision control software. You have full history on the server no matter what you do on the client. You can revert any change, including deletion of everything. Committing only fully tested, battle proven code to revision control gives you absolutely no benefits of using revision control in the first place.

What you could do is this: mark one branch as stable (this should be either /trunk or /braches/current-stable, I'd suggest the latter), let developers commit everywhere else. Setup Jenkins to do testing on /trunk and merge commits from trunk to current-stable only when they pass build tests.

Hubert Kario
  • 6,361
  • 6
  • 36
  • 65
  • I am resolved to agree with you. I was thinking of an svn hook but then it starts to get hairy. Thanks. – Slamice Jan 28 '12 at 03:42
  • This is a nice setup, but in essence, what's the difference if you build continuously ? The broken branch can't build since the last known good build, and the "stable" branch can build, yet it has no new code changes since the same revision anyway. Where it's worth the effort, maybe, would be if you have multiple dev branches from different teams, and you can use Jenkins to automatically merge up (pull) from these branches when they are good, and immediately merge down (push) to the other branches so they stay current. But this remains brittle. – Patrice M. Sep 09 '14 at 19:51
  • DVCS (Git, Hg, ...) is probably the better way if you can get there, and then the tooling support for Jenkins(+Gerrit) is therefore the most part. (See @matthias answer below) – Patrice M. Sep 09 '14 at 19:52
  • 1
    Completely disagree. This is a fantastic feature of CI servers like TeamCity, and honestly I've never met anyone who has used it and not come to appreciate it. Just because you *can* rollback a commit, doesn't mean there isn't a **cost** to making failed commits. Build failures are disruptive, particularly when you have many people working on the same code base. Pre-tested commits can help avoid a class of build failures that includes missing a file in a changelist, e.g. Doing so does not invalidate anything about revision control. – Mark Peters Sep 10 '14 at 03:31
  • @MarkPeters: And how does that make the commits to not be in revision control? The point is to have all the commits in revision control. Making sure that only good commits that build and pass basic testing land in `master` or `trunk` is a Good Idea™, pushing to central repository only such commits is not. – Hubert Kario Sep 15 '14 at 16:57
3

I assume that the "man upstairs" is aiming at a master branch/trunk that is always in a releasable state, hence the requirement of pretesting. This is inherently difficult with a centralized revision control system like Subversion and will most probably involve some sort of automatic branch-juggling & merging.

I personally use git in conjunction with Gerrit (http://code.google.com/p/gerrit/), a code-review tool together with Jenkins. Developers pull from a master branch but push to a "staging git repo" hosted by Gerrit. Gerrit in turn reacts by triggering a jenkins build job for the change. If all tests pass, Gerrit accepts the change and merges it into the master branch.

mattgruter
  • 41
  • 2
2

You could also use the Svn Revert Plugin in Jenkins.

Using that it would revert commits that turns the build unstable which removes the need of a "Pretested commit".

(I am the author of the plugin).

ki_
  • 121
  • 3