2
votes

I've set up a Jenkins build pipeline using the Build Pipeline Plugin and the Jenkins Clone Workspace SCM Plug-in as described by Jochen Wierum

This is very useful, but I have a question... The Clone Workspace SCM plugin only lets you get the most recent (good) build, so the pipeline diagram can be a little misleading. If I manually trigger my pipeline's second stage in, say, build number 4, but the first stage in build number 5 has already happened, then the second stage I'm triggering will actually use the build artifcats from build number 5. This could be confusing and potentially dangerous.

Is there a better workflow for build pipelines that's guaranteed to use the specific upstream build artifacts of this particular build set?

I understand that the Clone Workspace SCM plugin only stores the most recent, but I'm thinking there might be a way to achieve my goal using the standard Archive the artifacts post-build action to keep acrhives of all successful builds. I just can't figure out how to use that as the source of the next stage.

I've already found this answer but in my case I'm not trying to use a specific revision, but the exact result of the previous build stage. For example one of my build stage jobs might be to publish to staging environment. For that I don't want to have to go all the way back to source control and build from scratch when the whole point is that my earlier stages have built, run tests, etc.

2

2 Answers

0
votes

You can create a dummy file that has the change set in it and verify it to make sure you have the desired version when triggering the build stage. More details on how to do it. http://antagonisticpleiotropy.blogspot.com.au/2012/02/implementing-real-build-pipeline-with.html

0
votes

I implement it using build parameters. Jenkins isn't great in letting builds specify their own parameters in the correct format (as different parameters have different formats), so I use this little bit of Groovy in the "Post steps" of my initiating build:

import hudson.model.*
def thr = Thread.currentThread()
def build = thr?.executable
build.addAction(new ParametersAction(new StringParameterValue('UPSTREAM_BUILD_NUMBER', '<SpecificBuildSelector><buildNumber>' + build.getNumber() + '</buildNumber></SpecificBuildSelector>')))

Once this is being recorded from each build, I then use the Copy Artifacts plugin to copy the artifacts of the initiating build into the next job in the pipeline. You simply specify your new parameter, "UPSTREAM_BUILD_NUMBER", as the parameter for the copy artifact plugin, and you then have access to the same files all along the pipeline, with no need to worry that new builds will usurp your artifacts further down the pipeline. The same files are just copied from one build to another. If this is combined with fingerprinting, and the build pipeline plugin, you get a continuous deployment pipeline, with both audibility, and the ability to deploy previous builds if things go wrong.