Configure Project for Issue Tracking
- Karl Henselin
- Chandresh Patel
The Issue Tracking tab allows the association of the project with specific Issue Tracking System Instance which was configured on the Integrations page. Projects can define zero or more issue tracking systems, but in general there is only one issue tracking system in use for most organizations. Issue Tracking configuration can also be defined on folders to apply the configuration to all folders and projects within a folder.
Select an Issue Tracking System Instance from the drop down to associate it to the project. You can create the instance on this screen if needed.
Issue Tracking Configurations are inherited from the first parent folder that has overridden Issue Tracking Configurations. If no folder has overridden Issue Tracking Configurations, then the root FlexDeploy folder configurations are used.
To override these settings, enable the Override Issue Tracking Configuration toggle.
You can override the global settings as defined in the following table.
Field Name | Required | Description |
|---|---|---|
Ticket Pattern | No | Pattern of the issues within the issue tracking system, used to associate FlexDeploy builds with particular issue(s). If not specified here, the pattern will need to be defined on each project which associates to your issue tracking system. For Jira, Azure Boards, GitLab, and GitHub, the pattern of tickets must be the project Key, followed by a dash (e.g. "MYPROJ-"). In Jira, all tickets created for this project are prefixed by this key. For other providers, this key isn't part of the ticket id in the external system, but is necessary in FlexDeploy for identifying the project name. For Redmine, the pattern can be whatever you like. Recommended is 'refs #, references #, and IssueID #', as these match the defaults for referencing issues in commits defined by Redmine. You can provide more than one pattern as comma-separated values. |
Post Build Comment | No | The value of this property is a groovy script which evaluates to the comment you wish to update associated tickets with when a build completes successfully. See groovy variable section. |
Post Build Status | No | Use the dropdown and select the status. Any associated ticket will be updated to this status whenever the build completes successfully. |
Post Deploy Comment | No | The value of this property is a groovy script which evaluates to the comment you wish to update associated tickets with when a deployment completes successfully. See groovy variable section. |
Post Deploy Status | No | Use the dropdown and select the required status . Any associated ticket will be updated to this status whenever the deployment completes successfully. |
You can also control Ticket status differently based on environment. Under Environments section, Click Add Environment button, select Environment and define different status as necessary for environment.
This can be useful if you are using Statuses like Verify(Test), Verify(QA) etc.
Click Save to apply any changes, or disable Override Issue Tracking Configuration toggle to undo any changes.Â
Groovy Variables
The following variables are exposed into the Issue Tracking System groovy scripts to helper perform various actions like retrieving FlexDeploy data or making REST API requests.
Functions for performing actions in FlexDeploy | |
Functions for formatting and sending emails | |
Functions for getting topology values. | |
Object exposing REST functions. For more info see Using the REST object. |
- style