FlexDeploy issue tracking systems integration (out of box or custom) can be configured globally for use by various Projects. Configurations can be overridden at Project level as well as necessary.
Click on a particular issue tracking system to configure it.
...
Field Name | Required | Description |
|---|---|---|
Id | Yes | System generated identifier (read-only). |
Name | Yes | Name of the issue tracking system. (read-only for out-of-box integrations) |
Description | No | Description of the issue tracking system. |
Ticket Number Pattern | Yes | 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 is must be the Jira project Key, followed by a dash (e.g. "MYPROJ-"). All In Jira, all tickets created for this project are prefixed by this key, making it the pattern. 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.For Azure Boards, the pattern of tickets is the Azure DevOps project name, followed by a dash (e.g. "MYPROJ-"). For GitLab, the pattern must be the project name, followed be a dash (e.g. MYPROJ-) You can provide more than one pattern as comma-separated values. |
| Java Implementation | Yes | Implementation class issue tracking system integration. (read-only for out-of-box integrations) |
...
Field Name | Required | Description |
|---|---|---|
Update Tickets on Build | No | Check this box if you want to globally update any tickets associated to FlexDeploy builds. Can be overridden at the environment, project, or environment/project level. |
Build Update Comment Pattern | No | Applicable only if Update Tickets on Build is checked. 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. Groovy variables available to the script are provided in the (x=) dropdown to the right. Can be overridden at the environment, project, or environment/project level. |
Update Ticket Status on Build | No | Applicable only if Update Tickets on Build is checked. Check this box if you want to globally update the status of any tickets associated to FlexDeploy builds. Can be overridden at the environment, project, or environment/project level. |
To (Build) | No | Applicable only if Update Ticket Status on Build is checked. Any associated ticket will be updated to this status whenever the build completes successfully. Can be overridden at the environment, project, or environment/project level. For GitLab, this must be a transition status (e.g. reopen, close) which is valid as a state event in the GitLab Issue API, and not a current status as shown in the GitLab application. |
Update Tickets on Deploy | No | Check this box if you want to globally update any tickets associated to FlexDeploy deployments. Can be overridden at the environment, project, or environment/project level. |
Deploy Update Comment Pattern | No | Applicable only if Update Tickets on Deploy is checked. 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. Groovy variables available to the script are provided in the (x=) dropdown to the right. Can be overridden at the environment, project, or environment/project level. |
Update Ticket Status on Deploy | No | Applicable only if Update Tickets on Deploy is checked. Check this box if you want to globally update the status of any tickets associated to FlexDeploy builds when they are deployed. Can be overridden at the environment, project, or environment/project level. |
To (Deploy) | No | Applicable only if Update Ticket Status on Deploy is checked. Any associated ticket will be updated to this status whenever the deployment completes successfully. Can be overridden at the environment, project, or environment/project level. For GitLab, this must be a transition status (e.g. reopen, close) which is valid as a state event in the GitLab Issue API, and not a current status as shown in the GitLab application. |
Issue Tracking System Variables
...
Variable | Description |
|---|---|
EnvironmentName | Name of the environment selected when build or deploy is created. |
PackageName | Name of the current project package. |
ProjectName | Name of the project. |
ProjectVersion | The version of the project to submit for deployment. |
ReleaseLink | Applicable only for build and deployments on the release level else link will just go to last visited release. FlexDeploy link which redirects to this snapshot on the release dashboard. |
ReleaseName | The release name selected when build or deploy is created. |
ReleaseId | The id of the release selected when build or deploy is created. |
ServerBaseURL | The FlexDeploy server base URL defined in Administration → System Settings → Server Base URL |
| SnapshotId | Applicable only for build and deployments on the release level. Internal id value of Snapshot. |
| SnapshotName | Applicable only for build and deployments on the release level. Name of the snapshot (auto-generated by date and time when created). |
| StreamName | Name of the SCM stream selected when build is created. |
| WorkflowRequestor | FlexDeploy user that created the build or deployment request. |
...
Issue Tracking System Statuses table defines status details for specific issue tracking system, and allows FlexDeploy to update your issues to those values at build or deployment time. Statuses are also used when you choose to enable external approvals with your issue tracking system.
Each status is represented by Id and Name. Click the Save button to apply any updates.
...
For GitLab, you will need statuses for both getting the current status and making any desired transitions. For the current status, it should match statuses exactly as they're shown on the board. These statuses are only needed if you plan to use GitLab for external approvals. If you want FlexDeploy to make any updates to statuses on successful builds or deployments, you will need the state event names as they appear in GitLab's Issue API documentation. For example, in this image the current statuses would be 1-Open open and 2-Closedclosed. The transition statuses would be 3-Reopen reopen and 4-Closeclose. In the Update Ticket Status on Build and Update Ticket Status on Deploy dropdowns, the statuses will need to be transition statuses. In the Auto-approve Tasks on Status dropdown, the status needs to be a current status as it appears in the GitLab application. 
Finding GitHub Statuses
At this time, GitHub only supports open and closed for statuses. Statuses should match as they appear in GitHub. Status with id 1 should be the initial status and the status with the highest id should be the completed status.