View Source

h1. 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.

h1. Demonstration
# Visit [latest build of QA configuration|]. A jar file is published as artifacts.
# 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.
# Click the newly generated release build. When the build finishes, you will see that a new jar file is generated in the release build.

h1. Resolution
# 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.
# 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.
{info}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.{info}
# 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_.