GitLab Issues Integration

Syntax for GitLab Issues

GitLab issues are represented as RepoName-NUMBER in FlexDeploy. For example, demo-1, demo-2 where demo is name of GitLab project. See image below for reference.

FlexDeploy will accept and show GitLab issues as demo-1, demo-2 etc. Lowercase….

Preparing for GitLab Integration with FlexDeploy

  1. Go to GitLab and log in as the user you want to comment on GitLab Issues with.

  2. Generate a Personal Access Token in GitLab following this guide: https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html

  3. Choose an expiration date based on your security policies. Shorter expiration dates will require updating the ITS more frequently.

  4. Choose the following OAuth scopes to comment on and change status of issues:

Create Issue Tracking Instance

A GitLab instance looks like this:

Property Name

Property Code

Required

Description

Property Name

Property Code

Required

Description

GitLab URL

FDGITLABITS_URL

Yes

GitLab base project URL (https://gitlab.com/{organization or user})

GitLab Personal Access Token

FDGITLABITS_TOKEN

Yes

GitLab personal or project access token

GitLab API Version

FDGITLABITS_API_VERSION

Yes

GitLab API Version

Configure Folder or Project for Issue Tracking

Configure GitLab Issue Tracking Instance on your project or parent folder. Issue Tracking configurations are inherited by sub-folder and projects. This configuration will allow you to integrate GitLab issues with your builds. See Configure Project for Issue Tracking for more details.

Work Item pattern is optional, if specified his will used to parse commit logs work item numbers. Alternatively, you can just prefix work item numbers with # in commit message.

Optionally configure for Comment and/or Status update after build or deploy execution.

GitLab Issues only accept statuses of open and closed. Other statuses will be ignored.

Linking GitLab Issues to FlexDeploy Builds

Now you are ready to link GitLab issues with project builds. In order to link

  • using commit messages - use the format #issue for example, #Denver-1. Or you use Denver-1234 in commit message if Denver- is setup as work item pattern.

  • manually at build time - just specify work item number(s) on build request form in work items input. Note that # prefix only necessary with commit message.

  • manually with package - just specify work item number(s) on package configuration.

See Associate Work Items to a Build for more information about linking Work Items to builds.

Examples

 

The following macros are not currently supported in the footer:
  • style