

Use Jenkins "Build Per Branch" for Git Feature Branch Development - tednaleid
http://entagen.github.com/jenkins-build-per-branch/

======
ddlatham
_One disadvantage is that with multiple, short-lived branches, manually
creating CI to confirm that all tests continue to pass becomes far too much
overhead. It must be automated for this model to work and be trusted. "Jenkins
Build Per Branch" is the answer to that problem._

We use something close to this model, but there's no need to create separate
Jenkins jobs for each branch.

We have a single job that takes the git branch as a parameter and can run all
of the automated tests (and other jobs for builds, etc.). There is a script
that watches for new pull requests and automatically triggers the Jenkins job
to run all the tests on that pull request to verify that they pass before the
reviewer merges in to master.

~~~
tednaleid
Thats an interesting approach. If a branch is broken, which causes the job to
fail, how do you communicate that and monitor when it's actually fixed (rather
than another branch getting run which "fixes" it)?

~~~
ddlatham
We have email notifications on test failures, so the creator and reviewer of
the pull request can see it fails. Haven't done it yet, but would like to
extend it to report back the result as a comment directly on the pull request.

------
pbiggar
Circle (my CI-as-a-service startup - <https://circleci.com>) does this by
default. For nearly any reason that you have a branch - for staging or
deployment, for features, for tags, for bug fixes - there really is no reason
not to have this.

Unless of course, everyone gets a notification for every build in every
branch. Then you'll have practically every developer in your organization
hating this feature! I'm sure Jenkins has a way of controlling that though.

------
tantalor
Travis automatically does this,

<http://about.travis-ci.org/docs/user/build-configuration/>

Basically, it builds whichever branch you push, as long as that branch has a
config. I think this is better because your config is in SCM instead of off in
jenkins-land (even though it is highly travis-specific).

~~~
enobrev
For that exact reason, I usually to put all my build scripts into a bash file,
and just call that bash file from jenkins.

------
gvalkov
A while ago, I wrote a similar tool[1] that I never quite got around to
releasing/documenting. Unlike the OP's nicely integrated plugin, mine is an
external script (which you would run from cron) that checks the repository for
new refs and creates jobs accordingly. Have a look at the config file[2] for a
general idea of what it does.

[1] <https://github.com/gvalkov/jenkins-autojobs>

[2] [https://github.com/gvalkov/jenkins-
autojobs/blob/master/doc/...](https://github.com/gvalkov/jenkins-
autojobs/blob/master/doc/git.config.yaml)

------
nsxwolf
Is there something like this for SVN?

~~~
tednaleid
Not that I'm aware of, but modifying the code to support SVN would be pretty
easy to do. All it really needs from the VCS is the current list of branch
names. If you modified the GitApi class ([https://github.com/entagen/jenkins-
build-per-branch/blob/mas...](https://github.com/entagen/jenkins-build-per-
branch/blob/master/src/main/groovy/com/entagen/jenkins/GitApi.groovy)) to talk
to SVN instead of git, everything else should work fine.

This project was presented at a user meeting tonight and one of the attendees
there was planning on adding Mercurial support.

~~~
nsxwolf
Will take a look. Thanks.

~~~
sulsomat
mind dropping a note here how it went? really keen on having this for svn as
well (i know, i know, so last century - but at my work place we have only
limited resources and migrating to another scm is a pretty resource intensive
task).

how about forking the module on github?

~~~
lt
Count me in as another one interested on this.

------
Ramone
But then it's not really continuous integration anymore is it? Having a CI
server and practicing continuous integration are not the same thing.

~~~
russell_h
Continuous integration doesn't mean all development happens in master. A
policy that works well for me is that anything that will require more than 2
minor commits to accomplish should happen in a feature branch. If tests pass
in the branch (and you probably want to insert code review/sign-off at this
stage as well), merge to master. If tests pass in master, deploy.

From what I can tell, this just makes it easy to run tests in branches. My
team uses something similar that kicks off a build whenever someone comments
"build it" in a GitHub pull request, and posts the results to the pull request
discussion.

~~~
Ramone
It sounds like we agree that long-lived branches are not continuous
integration at least. We probably differ in that I think short-lived branches
and pull requests are more overhead than most teams require. Keep in mind that
CI does expect daily check-ins to _master_. That's how short those branches
can live to satisfy that requirement. Anything else is not CI... which is not
the end of the world either, but I don't see the point of using a CI server at
all anymore. Just build/test your stuff locally.

