Scenario

Promote a QA build as release build. Instead of simply copying the QA artifacts, the release build artifacts should be generated by building from the source used by the QA build.

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 a new jar file is generated in the release build.

Resolution

1. Edit promotion setting of the QA configuration and define a promotion. The property "destination configuration" should be defined as the release configuration. We do not need to define property "files to promote" since we will not use QA artifacts, instead, we will build artifacts directly from source in the release build.
2. Most steps of the QA and release configuration are the same, and we can define them at project level to avoid duplication. Pay attention to the label step, we changed the step condition so that it only executes when release configuration is running.

   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.