2 Spinnaker Pipelines, 1 Jenkins Job


We just had a situation occur in Spinnaker 1.8.4 where we had two applications in Spinnaker running two different pipelines “start” the same job (a smoke-test job) in Jenkins that resulted in the same job number. To my knowledge this is the first time this has happened. We did upgrade to 1.8.4 today where we were previously running master-unvalidated (from 36 days ago - which I believe was somewhere around 1.8.0 but prior to its actual release).

Is there a situation that can/should result in this behavior? Is there a different way my pipeline should be configured to avoid this?


When you say that these resulted in the same job number, do you mean that when looking at your job in Jenkins there are two executions with the same number? Or is it that Jenkins correctly assigned different numbers to the executions, but Spinnaker got confused and linked both pipelines to the same execution? (That is, you see two different executions in Jenkins, but both Spinnaker pipelines are linking back to the same execution.)


Two pipelines referenced the same Jenkins Job Number and in Jenkins there were two executions on the same job:



Thanks for the details—I had never seen this before in Jenkins, but was just able to reproduce locally. From my experimenting, the behavior of Jenkins itself is that if it receives multiple requests to trigger a build in quick succession it will collapse these into a single execution, and note that the execution was triggered multiple times. I was able to reproduce by writing a short script that just calls the same API Spinnaker uses (POST /job/{job-name}/build) a number of times in parallel.

In my experimenting, it did not collapse parameterized builds with different parameters—so this looks like it may be intentional behavior, where it’s deciding that identically triggering a build with exactly the same parameters a few times in a short interval can be collapsed into a single trigger. That being said, I couldn’t find any documentation of this in a quick search.

So this seems to be a characteristic of how Jenkins behaves—it looks like the behavior you’ve seen will happen regardless of whether builds are triggered by Spinnaker or another system.

In your workflow, is there a reason you’d want the Jenkins job to run twice when triggered by the same parameters in rapid succession? (Or is your case more complex, and Jenkins collapsed builds with different parameters, which I was not able to observe in my testing.)