subversion Pre-commit build with jenkins

[Lynn Lin]

Hi all,
    Anyone has experience on this? I just want  to block bad commit

[Les Mikesell]

On 4/7/11 7:06 AM, Lynn Lin wrote:
> Hi all,
> Anyone has experience on this? I just want to block bad commit

Bad commits on a trunk aren't the end of the world - and one of the points of
keeping everything in a version control system is so you can learn from previous
mistakes. If you just let jenkins build frequently after trunk commits and
email the development group on failed builds it will be fixed quickly and your
developers will learn to run a test build before committing. And with
continuous builds happening on the trunk, you'll probably want to copy to
branches as your work approaches new stable release points for final changes and
testing as the trunk development moves on.

--
Les Mikesell
lesmi...@gmail.com

[Lynn Lin]

I understand  you. One  of our project is like this. However the project owner doesn't want commit which break build in repository

[David Weintraub]

On Thu, Apr 7, 2011 at 9:14 AM, Lynn Lin <lynn.x...@gmail.com> wrote:
> I understand  you. One  of our project is like this. However the project
> owner doesn't want commit which break build in repository

No one does. But, this is not the end of the world. With Subversion,
you can easily revert bad commits. In fact, you can use Jenkins to run
tests, do code coverage, and check syntax styles.

Developers get very embarrassed when they cause a build to fail, and
everyone on their team (and all the team leads) get an email stating
this. Jenkins makes it very obvious when someone messes up. I've been
in projects using Jenkins for years that never had a bad build caused
by a developer commit.

To really ensure that developers don't break builds, use the Jenkins
Continuous Integration Game. It scores builds by how unit testing and
the build comes out. Break a unit test, and you lose a point. Break a
build, and you lose 10 points. Fix a unit test, and you get a point.
Plus, you get a point for each good build. Developers are very proud
of their position on the leader board.

--
David Weintraub
qaz...@gmail.com

[Les Mikesell]

On 4/7/2011 8:14 AM, Lynn Lin wrote:
> I understand you. One of our project is like this. However the project
> owner doesn't want commit which break build in repository

This would be easier to arrange with a distributed VC like git where a
person in charge of the 'master' repo can selectively pull approved
changes from developer's copies. With a centralized VC like subversion,
you either accept that the trunk will sometimes have flaws, do all
development on 'feature' branches that are merged back to the trunk when
complete, or don't give commit access to anyone you don't trust to do a
test build before committing (and with concurrent development you can
still miss).

--
Les Mikesell
lesmi...@gmail.com

[Swindells, Thomas]

The simplest solution is to switch to using Git/Gerrit and use the Gerrit trigger plugin do a pre-commit build before it gets merged into trunk. The developer is still responsible for performing the merge, but they only do it after the precommit Jenkins job has verified their build - you could have other people also doing code review as well but there's no requirement for that.

Thomas

**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postm...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************

[Lynn Lin]

On Fri, Apr 8, 2011 at 4:59 PM, Swindells, Thomas <TSwin...@nds.com> wrote:
> The simplest solution is to switch to using Git/Gerrit and use the Gerrit trigger plugin do a pre-commit build before it gets merged into trunk. The developer is still responsible for performing the merge, but they only do it after the precommit Jenkins job has verified their build - you could have other people also doing code review as well but there's no requirement for that.
>

Thanks,however it's difficuclt to switch to git so far,not technical reason.

There should be lots of subversion users who play with Jenkins,I still
want to get some clues on pre-commit build

[Swindells, Thomas]

The problem is that the way svn works doesn't match the concept of pre-commit builds.
Pre-commit requires some form of staging area of commits, if you try hacking this into svn you are likely to confuse the client as it will think that the commit is in and not in at the same time.

The simplest work around for this if you have to use svn is to have two branches, a staging branch and a reviewed branch, Hudson builds the staging branch, if it passes somebody then copies the changes into the master branch (and another Hudson job builds this to make sure it really is ok).

Thomas

[Nigel Magnay]

I think you're trying to teach a pig to sing here. Your project owner is adding requirements that exceed the capabilities of the tooling.

Your choices are either make the developers commit code by some non-svn mechanism - perhaps by submitting patchsets to Jenkins - and if the build succeeds, jenkins commits the code into SVN. Commercial solutions like TeamCity I believe take this approach (where the developers aren't really using SVN anymore).

Alternatively, development could carry on inside a branch in SVN, and a similar process could take place. However, if the project owner is insisting that *all* revisions committed are buildable, you're setting yourself up for a miserable time because you've just moved the problem somewhere else. If a 'bad' commit ends up in the branch, you've got to manually revert it whilst developers are still committing to it and... well... hilarity ensues.

If I were forced to do something like this, then I'd use a combination of gerrit, git and a git-svn bridge to do the first option. I'd have developers commit to git / gerrit, build it in jenkins, and if successful then do a squashed commit with git-svn to the svn repo.

The project owner will still see commits into SVN (it can still be treated as the 'canonical' repository), all downstream SVN users / tooling still works, but developers are submitting to it in a slightly altered workflow gaining the desired quality metric.

[Lynn Lin]

I am very  interested at  your  first  suggestion-submit  patch to jenkins.
Just  a question here:how do i apply patch meanwhile the patch will  not  commit into repository

[Nigel Magnay]

I meant something like developers instead of committing to svn, do something like

$ svn diff | mail -s "Title of the commit message" jenkins@blahblah

Then you have a build trigger from email that checks out latest SVN revision, then does

'patch -p0 -i <content of mail>', does the build, and if successful does an svn checkin.

You'll probably have some work to do building jenkins plugins to get the work done.

If the patch won't apply then the build is a fail and the developer has to re-submit (same as if you were using a DVCS / gerrit like solution)

[Ferenc Kovacs]

somebody mentioned the try jobs from buildbot in another thread:
http://buildbot.net/buildbot/docs/0.8.2/try.html

maybe it would be a worthwhile addition to jenkins?

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

[Sami Tikka]

Sorry, I'm coming late to this thread. Was Subversion Merge plugin mentioned yet? https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Merge+Plugin

I haven't tried it myself but the description looks like it could be used to implement pretested commit, especially when reading under the title "Automatic integration"

-- Sami