Jenkins queuing multiple jobs of same type from SVN post commit hooks, what is expected behaviour?

[Christoffer Holmstedt]

Hi

I'm running a Jenkins server, latest 2.19 LTS release with a few pipeline jobs. Each job is triggered by a post-commit hook in respective SVN repository. The problem I have is that I expected Jenkins to only queue up one similiar job if another job of the same pipeline is already running but I get one build per commit.

As an example: Job A is triggered by a post commit from Commit #1. The build takes 5 minutes so if I commit #2 and #3 to the repository Jenkins will queue up two more builds, one for each commit. I would expect Jenkins to only queue one extra build with commit #2 and #3.

While searching for a solution to this it is not clear what the expected behaviour is. Jenkins will only queue up one identical build if multiple remote triggers are actived except in the case if a build uses parameters in that case if the parameters are different each build will be unique. The problem here is that I don't use parameterized builds so not sure what is going on really and what to expect.

Any help is appreciated.

Best regards

--

Christoffer Holmstedt

[Slide]

This is expected behavior, each commit gets its own build. Don't you want a build for each time a developer commits something so you know which commit broke something?

--
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-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAG9Fz%2BuF0KS0txKHc6NZiF7zLe%2Bfe4DqxHzvScLq%3DcMh1OkySQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[taroc...@gmail.com]

Maybe you can configure the 'quiet period'? The default is set in the configuration screen, but you can also set it per job configuration.

[Christoffer Holmstedt]

Thank you for your answers, much appreciated. After digging into this problem a bit further I've come to the conclusion that you are both right.

As you say Slide I really want every build to isolate one commit but at some point the feedback loop back to developers becomes too long and it would be more valuable to start the build earlier with multiple commits. If it is a green light, good, if it is red then a little more time than usual have to be spent on tracing down the failing commit(s). I could throw more hardware at it also to solve this problem but I was curious if there is any configuration setting to help me out for the time being.

I looked closer to the "quiet period" and it is sort of the functionality I want, but not for the first build. So if nothing is building on the build server I would like the quiet period to be 0 and if the same job is already being built for one commit then the build server should queue up one and only one build for all commits coming in during that first build. I assume the quiet period is static for all builds and cannot be dynamically set from within Jenkins depending on current builds.

So to summarize I'm trying to optimize the feedback loop back to developers as well as sticking to one build per commit for as long as possible.

Regards

--

Christoffer Holmstedt

--

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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/91be60dd-e5b5-4a93-b59f-2c9dc53a5090%40googlegroups.com.

[taroc...@gmail.com]

From my experience, having multiple pipeline jobs polling for changes causes confusion from the end-user. It seems better to have one "master" job that polls and runs all the other builds. Also it seems Jenkins jobs (including pipeilnes) are quite happy to build concurrently, but I don't know how to handle it yet. So I've selected "Do not allow concurrent builds" in the master pipeline job. As a result, the job will queue.

On Tuesday, December 13, 2016 at 9:48:46 PM UTC-8, Christoffer Holmstedt wrote:

[Christoffer Holmstedt]

hmm, I don't follow you now tarocaravan. I only use post-commit hooks from SVN to Jenkins, no polling. Each SVN repository only triggers one job on the Jenkins build server but the problem is that a rapid sequence of multiple commits will build up the "feedback loop time". So one commit will give feedback in 5 minutes but the builds after the first commit will build up to total time of commits * 5 minutes, which is too long.

--

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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/9e6d8b89-2566-4bbe-b1ca-02685e2876c6%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Christoffer Holmstedt