Release Settings

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, Release Settings are also inherited for Folders and Releases.

Release Settings can be defined at the folder level which all sub-folders and Releases will inherit. They can be overridden on any individual Release or Folder.

Here are all the Release Settings currently available:

Setting Name	Description	Default Value

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.
Default Branch Name	The branch name to use when a Project or Package is added to the Release. If not set, the main branch for that Project will be used.
Snapshot Name	A custom script used to generate default Snapshot names. This is groovy script configuration and supports variables like CurrentDate, ReleaseName, SequenceNumber. Prior to FlexDeploy 8.0, snapshot name defaulted to date time in format MM-dd-yyyy HH:mm:ss. Now snapshot name is configurable, most likely use of SequenceNumber is easier to understand for users. Variables CurrentDate - current date time in format MM-dd-yyyy HH:mm:ss ReleaseName - name of release where snapshot is being created SequenceNumber - generated using internal sequence, separate sequence for each release. Starts from 1.	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 mode details below 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 are still allowed to approve. 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 a production stage on the Pipeline. The completed packages will be skipped during future Snapshot creation and pipeline execution. Note that this will cause issues in the event that a production stage is not the last stage in the pipeline or there are multiple production stages. The packages will be completed once the first production stage is successful. Since FlexDeploy 8.0, Completed Packages can be reactivated again. This setting will not work if your FlexDeploy server is configured as an Isolated Network Target Server.	false
End Release after successful production stage	Release will be marked as Completed once a Snapshot has completed the production stage of a pipeline. Note that the Release will end once the pipeline execution is successful and a production stage was present. All pending Snapshots and running pipeline executions will be aborted. Since FlexDeploy 8.0, Completed Release can be reactivated again.	false
Lock Comments	Prevents new comments after the Release has been completed.	false
Auto Add-Content Options	Choose when to automatically add Projects and Packages based on Work Items in the Release. Work Items are always added to the Release after Project or Package build or Snapshot completion. Package Work Items - Add a Package to the Release if it's linked to a Work Item in the Release New Builds Linked to Work Item - Add any built Projects/Packages to the Release if the build is linked to a Work Item in the Release Previous Builds Linked to Work Item - Add a Project or Package to the Release if a Work Item is added to the Release and a previous Project/Package build is linked to that Work Item Previous Builds Linked to Work Item should be used with caution as that will add all content previously built for specific work item to the release.	Package Work Items, New Builds Linked to Work Item

Do Not Allow Duplicate File(s)

Here are the different scenarios where this setting will impact Snapshot creation:

Create a 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 FAILED status 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.