It can be (mostly) done, but you are intentionally defeating a Jenkins feature
and you need to take that into account.
When a job is monitoring a Git repository, there are two problems. First off,
by default it polls. If two commits get in within the same poll interval,
you’re getting both. Secondly, you can only have one job in the queue with a
given name and a given set of parameters. Duplicate jobs in the queue get
silently discarded. This is a feature, not a bug, so that five commits don’t
cause five builds. It sounds like you explicitly don’t want this behavior.
To do what you want, build two jobs, a “poller” and a runner. The “polling”
job starts by polling Git (it’s in quotes for reasons below). Its only purpose
is to launch the runner job with the ${GIT_REVISION} as its only argument.
The runner doesn’t poll at all, it just pulls from the Git repository,
explicitly getting the version passed in by the poller. By making the revision
an argument, this allows five commits to trigger five different jobs, and
allows all five jobs to remain in the queue (as they have different arguments).
The above still has the problem of handling multiple commits in one polling
interval. In theory, you could poll once a minute, but that’s expensive and
still not going to get you what you want. There is no way to poll quickly
enough to insure one job per commit. You’re going to have to do something
other than polling.
In my shop, we use a local GitLab installation for our source control. We
installed the Gitlab Hook
Plugin<https://wiki.jenkins-ci.org/display/JENKINS/Gitlab+Hook+Plugin>, and set
our jobs to only poll once a day. The plugin allows GitLab to use a Web hook,
so that whenever it receives a commit, it tells Jenkins “Poll on this
repository NOW”. Jenkins will then launch a poll on every job which is polling
that Git repository. Polling once a day satisfies that requirement, and our
jobs launch within seconds of getting a commit.
It may still be possible to get multiple commits to come in fast enough so that
the forced poll catches multiple commits. If someone merges in a branch with
five commits on it, I suspect that all five commits are considered
simultaneous, and you will only poll once and build once.
If you absolutely, positively need one job per commit, including the case above
(or cases where multiple people commit faster than Jenkins can even run its
poll), now you’re going to have to get tricky. Now you need to work in the
poller job. It will have to behave like so:
1. Determine what the last commit built was. Maybe it can use Jenkins
internals, or get the parameters from the last build of the runner via HTTP to
the job’s /api/xml page.
2. Get the history of the repository or branch
3. Find all the commits done after the last commit built
4. In order, launch the runner for each of those commits.
--Rob
From: jenkinsci-users@googlegroups.com
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of Steve K
Sent: Tuesday, December 30, 2014 3:21 PM
To: jenkinsci-users@googlegroups.com
Subject: Git based builds; one commit at a time
Let's say that, since my most recent build, there have been three (3) new
commits.
Rather than having one build that includes all three commits, I would like to
have three separate builds; one for each of the three in sequence.
Is anyone doing something like that? If so, how are you doing it?
Thanks in advance.
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
jenkinsci-users+unsubscr...@googlegroups.com<mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/60bb2099-c4c1-4630-874c-339fc27c82b0%40googlegroups.com<https://groups.google.com/d/msgid/jenkinsci-users/60bb2099-c4c1-4630-874c-339fc27c82b0%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
Click
here<https://www.mailcontrol.com/sr/kDHW7Nj!uqrGX2PQPOmvUvmldA89nuwl+4q7Z7PYepNtJmQIFgNOaagMtbaIYtrvfRb1JLBUB+kJwVIOzJj0SQ==>
to report this email as spam.
________________________________
This e-mail and the information, including any attachments it contains, are
intended to be a confidential communication only to the person or entity to
whom it is addressed and may contain information that is privileged. If the
reader of this message is not the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error, please
immediately notify the sender and destroy the original message.
Thank you.
Please consider the environment before printing this email.
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/0A40042D85E7C84DB443060EC44B3FD36D9A9B890A%40dekaexchange07.deka.local.
For more options, visit https://groups.google.com/d/optout.
