Release Settings allow you to control actions for a Release throughout its lifecycle. These settings support setting defaults, automatically triggering actions during pipeline execution, and defining restrictions for a Release. Similar to the security inheritance for Folders and Projects, there is a Release Settings tab within each folder.
Release Settings can be defined at the folder level which will be inherited by all subfolders and Releases. They can be overridden on any individual Release or Folder.
Here are all the Release Settings currently available:
Setting Name | Description | Default Value |
|---|---|---|
Default Pipeline | Default pipeline will be automatically assigned to new Releases under this folder. The pipeline on the Release can still be changed for scenarios where you don’t want to use the default. | n/a |
Default Branch Name | The branch name default set on each Project and Package when creating a Snapshot. The branch can also be set on each item from the Definition tab, or on the Create Snapshot form. | n/a |
Snapshot Name | A custom script used to generate default Snapshot names. | CurrentDate |
Do not allow duplicate file(s) | New snapshot creation will fail if a file is present in more than one Package from the same Project in a Release. See Additional Notes for how this setting impacts different methods of creating a Snapshot. | false |
Do not allow approvals by code committers | Prevents FlexDeploy users from approving a gate if they had made commits to any of the source code deploying on that stage. This applies for both Approval and External Approval Gates. Checks for matching username or email in commit details. Administrators can still override. The email and username on the commit details correlate to the user’s git config at the time of the commit, not their git account. | false |
Do not allow overriding external approvals | Prevents manually overriding an External Approval Gate within FlexDeploy. Note that if this setting is enabled and your CMS system is down, you will be unable to progress your Release. However, Administrators can still override. | false |
Complete Package after deployment to production | All Packages in a Snapshot will be marked as completed once the Snapshot has successfully completed the production stage on the Pipeline. The completed packages will be skipped during future Snapshot creation and pipeline execution. Packages can be reactivated again. | false |
End Release after successful production stage | Release will be marked as Completed once a Snapshot has completed the production stage of a pipeline. All pending Snapshots and running pipeline executions will be aborted. Release can be reactivated again. | false |
Lock Comments | Prevents new comments after the Release has been completed. | false |
Additional Notes:
Do Not Allow Duplicate File(s)
Here are the different scenarios where this setting will impact Snapshot creation:
Create Snapshot Form and Promote to Release
For Promote to Release, the Current Snapshot on the Release must contain the duplicate file(s) for the error to be thrown.
Create Snapshot Form will have the same error when trying to submit.
Associate Release with Build Request:
When associating Release with a Build Request, a Snapshot will be created automatically. If duplicate files exist then the Snapshot will get created with a
FAILEDstatus with a corresponding error message that duplicate files are not allowed on Release.
Release CI Schedule:
For Snapshots that are automatically triggered from the schedule CRON Expression on the Release, the Snapshot will not get created and instead an error message will appear at the top of the Release page. The error message will be deleted once a Snapshot is successfully initiated.
