h1. Define promomotions
[Build promotion] can be defined in promotion setting page of a configuration like below:
!promotion.png!
The promote condition controls whether or not the promote action appears on the build page. Taking above screenshot for example:
# if a build is successful, the promote action _deploy_ will be visible while promote action _release_ will not be visible like below:
!deploy.png!
# if a build is recommended, the promote action _deploy_ and _release_ will both be visible like below:
!deploy-release.png!
# if a build is failed, no promote actions will be visible.
h1. Revision promotion and artifact promotion
During a promotion, QuickBuild will remember the repository revision used in source build, and use it to build destination configuration. This is called revision promotion, and it guarantees that the source build and destination build use the same set of source code. Please note that revision promotion only happens for repositories of the same name. For example, if source build is generated using source code from repository "A" and "B", and destination build is generated using source code from repository "B" and "C", only revision of repository "B" will be passed from source build to destination build.
In many cases, you may
h1. Control promotion process with variables
Variables can be defined in the promotion setting screen to control the promotion process. For example, you may have the destination build using the version as source build if:
# The property _next build version_ of destination configuration is specified as _$\{vars.get("promoteVersion")\}_.
# A promotion variable is defined in promotion setting of the source configuration, with the name set to _promoteVersion_, and value set to _$\{build.version\}_.
If you would like version of destination build being prompted in the above example, you may leave value of the variable _promoteVersion_ empty, and specify its prompt setting as _prompt as text input_.
h1. Change detection during promotion
In a build promotion process, changes of destination build are calculated by comparing repository revision of current destination build against previous destination build, instead of previous source build. This is well explained [here|Promote build#build changes].
[Build promotion] can be defined in promotion setting page of a configuration like below:
!promotion.png!
The promote condition controls whether or not the promote action appears on the build page. Taking above screenshot for example:
# if a build is successful, the promote action _deploy_ will be visible while promote action _release_ will not be visible like below:
!deploy.png!
# if a build is recommended, the promote action _deploy_ and _release_ will both be visible like below:
!deploy-release.png!
# if a build is failed, no promote actions will be visible.
h1. Revision promotion and artifact promotion
During a promotion, QuickBuild will remember the repository revision used in source build, and use it to build destination configuration. This is called revision promotion, and it guarantees that the source build and destination build use the same set of source code. Please note that revision promotion only happens for repositories of the same name. For example, if source build is generated using source code from repository "A" and "B", and destination build is generated using source code from repository "B" and "C", only revision of repository "B" will be passed from source build to destination build.
In many cases, you may
h1. Control promotion process with variables
Variables can be defined in the promotion setting screen to control the promotion process. For example, you may have the destination build using the version as source build if:
# The property _next build version_ of destination configuration is specified as _$\{vars.get("promoteVersion")\}_.
# A promotion variable is defined in promotion setting of the source configuration, with the name set to _promoteVersion_, and value set to _$\{build.version\}_.
If you would like version of destination build being prompted in the above example, you may leave value of the variable _promoteVersion_ empty, and specify its prompt setting as _prompt as text input_.
h1. Change detection during promotion
In a build promotion process, changes of destination build are calculated by comparing repository revision of current destination build against previous destination build, instead of previous source build. This is well explained [here|Promote build#build changes].