h1. Scenario
Promote build from QA configuration to release configuration. The release build should use the same artifacts of the QA build being promoted.
h1. Demonstration
# Visit [latest build of QA configuration|http://demo.pmease.com/build/40.latest]. 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 the jar file is now copied from QA build and renamed to reflect the release version.
h1. Resolution
# Edit [promotion setting of the QA configuration|http://demo.pmease.com/settings/40/promotions] 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.
# Edit [step setting of the release configuration|http://demo.pmease.com/settings/41/steps] 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.
{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|http://demo.pmease.com/settings/37/repositories] 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|http://demo.pmease.com/settings/37/general] and set the _Run Mode_ property as _DISABLED_.
Promote build from QA configuration to release configuration. The release build should use the same artifacts of the QA build being promoted.
h1. Demonstration
# Visit [latest build of QA configuration|http://demo.pmease.com/build/40.latest]. 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 the jar file is now copied from QA build and renamed to reflect the release version.
h1. Resolution
# Edit [promotion setting of the QA configuration|http://demo.pmease.com/settings/40/promotions] 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.
# Edit [step setting of the release configuration|http://demo.pmease.com/settings/41/steps] 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.
{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|http://demo.pmease.com/settings/37/repositories] 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|http://demo.pmease.com/settings/37/general] and set the _Run Mode_ property as _DISABLED_.