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.
...
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, the pattern of tickets is the Jira project Key, followed by a dash (e.g. "MYPROJ-"). All tickets created for this project are prefixed by this key, making it the pattern. 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) |
Default Configuration
...
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 URL defined in Adminstration 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. |
...
FlexDeploy can be configured with global environment rules which will apply to all projects unless overridden at the project level. Environment Configurations done for specific environment will be applicable only for that specific environment (i.e. overrides for Default Configuration)
...
The selected ticket status for the Auto-approve Tasks on Status field, is for any External Approval Task that gets created for the Development environment. The task is automatically approved when the associated ticket, in the Issue Tracking System, reaches or exceeds the desired status. For more information on the setup of the External Approvals and configuring Issue Tracking System at the Project level, refer to the Project Issue Tracking System Configuration section of the Projects page.
...
Issue Tracking System Properties provide the definition of configuration parameters that are required to integrate with specific instance of issue tracking system. Values for these properties will be provided when Issue Tracking System Instance is configured. Properties are read-only for out-of-box integrations.
Status
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.
...
In Azure Boards, issue statuses can be retrieved from the column names in the individual Board itself. It is critical that the status names entered in FlexDeploy match the column names in the Azure Board. Otherwise, otherwise, FlexDeploy will be unable to make the desired updates. Status ids aren't relevant for Azure Boards, so the only requirement for entering them in FlexDeploy is putting them in the order they appear in your workflow. (e.g. 1-New, 2-Active, 3-Test, 4-Resolved, 5-Closed)
Finding GitLab Statuses
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. 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 and 2-Closed. The transition statuses would be 3-Reopen and 4-Close. 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.
