The Deploy step deploys a single named project from the snapshot to the stage.
Field | Description |
|---|---|
Step Name | The name of the step. |
Description | An optional description for the step. |
Project Name | The name of the project in the snapshot to deploy. This project must be in the snapshot, or the deployment will fail. |
| Force Deploy | Whether or not to force deploy the project. If true, this is equivalent to checking force deploy when individually deploying a project to an environment through the deploy request form. |
| FlexFields | If Deploy Request FlexFields are configured, entry will be prompted for on the step configuration (not shown above). If the information is provided in the stage execution info, it will override the data entered on the step configuration. |
| Inputs | If the deploy workflow for the project has inputs, entry will be prompted for on the step configuration (not shown above). If the information is provided in the stage execution info, it will override the data entered on the step configuration. |
| Precondition | An optional Groovy script which determines whether the gate or step is applicable during execution. The script has access to variables and methods listed in the expression |
| Continue | If checked, any failure will be ignored, and the pipeline execution will continue. |
| Notify Release Managers | If checked, an email notification will be sent to the release managers (configured on the release) on failure. |
Deploying a named project reduces the generic nature of pipelines, as it assumes that the specific project is in the release and snapshot. To make the pipeline more generic, and therefore reusable, you should try to avoid tying it to specific projects where possible.