Scenario

Promote build from QA configuration to release configuration. The release build should use the same artifacts of the QA build being promoted.

Demonstration

1. Visit latest build of QA configuration. A jar file is published as artifacts.
2. Click the promote button, and refresh the page after a while, a promotion arrow will appear at right side of the QA build version pointing to the newly generated release build.
3. Click the newly generated release build. When the build finishes, you will see that the jar file is now copied from QA build and renamed to reflect the release version.

Resolution

1. Edit promotion setting of the QA configuration and define a promotion, with property destination configuration defined as release configuration, and property files to promote defined as desired files need to be promoted. All promoted files will be copied to workspace of node running the master step of destination configuration.
2. Edit step setting of the release configuration to define desired steps need to be executed during the release process. In this demo, we add steps to change name of promoted artifacts, publish promoted artifacts, and at last create label in the SCM.

   Please make sure that the same repositories are used in QA and release configuration. This makes sure that all repository related steps in the release configuration operate against the repository revision used in the QA build. In our example, we define the repository directly at the project level and it is inherited by both QA and release configurations.

3. Optionally you may set up the release configuration to disallow direct triggering, so that new releases can only be promoted from QA build. This can be done by editing general setting of the release configuration and set the Run Mode property as DISABLED.