Jenkins: Use Archived Artifact in Promoted Build

Question

I've archived an artifact as the last step of the build and it's available as something like this: https://xxx.ci.cloudbees.com/job/xxx/52/artifact/target/xxx-1.2.1-SNAPSHOT-r8304-20130807-1507-app.zip

How can I easily access the artifact in my promotion process? Please note that I need to access the specific build, not the latest successful one.

The goal of the promotion process is to copy the artifact to S3 from where our deployment job will further process it. So I might promote build #52 to development (copy it to a specific S3 bucket), later on promote build #50 to production and so on.

Ideally, I can access the artifact in a shell script to rename the file etc. Is there an environment variable to access the archived artifacts of a build, which I cannot find or how should this be done? $BUILD_URL and $JOB_URL are already specific to the promotion process and don't point to the build itself in shell scripts on the promotion job.

With the copy artifact plugin I can only copy artifacts from other builds in the promotion process, which I don't need to do.

Boris

Answer 1

I believe I have found the solution.

Summary

• Do not use Specified by permalink
• Use Specific build and set build number to ${PROMOTED_NUMBER}

The Solution

Prerequisites

• The Copy Artifact Plugin must be installed.
• Archive the artifacts you want the promotions to access
  • In Post-build Actions add the action Archive the artifacts and set Files to archive to what ever you want your promotion to access.
• Do not discard old artifacts
  • In the Job Configuration, deselect Discard Old Builds or ensure that its settings will keep the artifacts for as long as you want to promote your builds.

Promotion setup:

Setup up your promoted build with name and criteria as usual.

In the Actions section add the action Copy artifacts from an other project, and set these values.

• Project Name: ${PROMOTED_JOB_NAME}
• Which Build: Specific Build
• Build Number: ${PROMOTED_NUMBER}
• Artifacts to Copy: path/to/your/artifacts/**
• Target: ${BUILD_TAG}

Then add the actions you really want to do. For example add the action Archive the artifacts to save the artifacts. Remember to prefix your paths with ${BUILD_TAG} e.g. ${BUILD_TAG}/path/to/your/artifacts/**

Notes on why

Copying artifacts

As you probably know by now, the promotion should not expect to have access the the content of the workspace of the build. It might be executed on a different server, and it might have access to no workspace at all or the workspace from an older or newer build. It is therefore required to copy the artifacts you want to use to the current workspace.

This is also the reason why the Target value is set. The workspace might be poluted with other builds or promototions. Setting target to ${BUILD_TAG} Prevents any conflicts with files already in the workspace, by creating a folder unique to the promotion process.

${PROMOTED_*} variables

As you state the normal build variables refer to the promotion process itself, but The Promoted Build Plugin defines some environment variables referring to the actual build instead.

Permalinks

In a Jenkins context permalinks only refers to the special links that points to the latest build of some type or the latest promotion. That is why you will always get the latest version

In my version of Jenkins the dropdown is replaced with a textbox. Writing the URL to a specific build like http://jenkins/job/myjob/59/ is not recognized as one of the special permalinks, and the copying will thus fail.

Mantelletta

This does indeed select the correct build. Pretty obscure, but great solution! – Boris

This should be included in the "Promoted Builds" documentation – Ruffner

Answer 2

You can use the Copy Artifact plugin. Set it to copy artifacts from the main project, and choose Specified by permalink where the permalink is Latest promotion: this promotion process.

(Note that since the promotion configuration refers to itself here, you cannot add such a promotion in one step: you must add the promotion with no build step, save, then go back and add the build steps.)

Cyperaceous

I find the naming a little confusing, but this is definitely a step in the right direction. Doing a little test I experienced the following behavior: The first promotion process takes the current artifact. Any additional deployment can only deploy the current or a later artifact. If I've already promoted build #60 for a specific promotion, trying to promote #59 will again deploy #60. I'll need to discuss this, but this is probably good to have to avoid old deploys. – Boris

There's a new (I think) facility in the copy artifact plugin that you can specify the build number and the artifact you want from that build number – Debauchee

@Boris : Did you get a solution for this issue? I am facing the same problem. promoted build #60 and then trying promote a lesser version is promoting the last promoted version of the artifact. – Scibert

Unfortunately not. The last build always "win" – Boris

Answer 3

As an aside, you might find the Workflow system makes it easier to customize this kind of pipeline logic, without needing to use the Promoted Builds or Copy Artifact plugins at all.

Cyperaceous

If possible, can you describe how one might use pipelines instead of copy artifacts? We have a multi-stage pipeline, where each stage runs in a new kubernetes pod, and I'd like to access an archive built in a previous stage for integration testing. Is there anything special I can do in my pipeline to share artifacts specifically built in an earlier stage, aside from archiving artifacts (or publish+download to some other location)? – Bufflehead