Share this page

# Track commits to your SCM system

If your CI server is set up to work with a source control management (SCM) system, such as Git or Subversion (SVN), you can use the integration to track committed changes. See also Source code management (SCM) integrations.

In this topic:

## Overview

Pipelines display the commits associated with each run of the pipeline.

You can associate a commit with specific backlog items (user stories, quality stories, or defects). For details, see Associate commits with backlog items.

You can track the committed changes and their affect on release and build quality. You can view the following information in different modules.

Module | Description
--- | ---
Pipelines | In a pipeline run: The list of backlog items and commits associated with the pipeline run. In a pipeline overview: The number of committers and commits included in the pipeline's latest run. In a pipeline run's analysis: The commits that are related to failed automated test runs.
Backlog | Inside a backlog item: The list of commits related to the item. Inside an epic or feature: The list of commits associated with backlog items defined under the epic or feature.
Team Backlog | The list of commits made by the members of the selected team.

The risk indicator near commits or features indicates changes committed in sensitive areas of code.

Note:

- When working with GoCD, commits and their associations with entities are displayed. The list of files included in each commit is not available.

- Long commit messages are truncated to 255 characters.

## Use-cases for tracking commits

Below are ways that you can use to commit tracking information.

Note: Most roles can be customized. Roles and their permissions might be different for your organization.

Role | Use case
--- | ---
Developer | When you commit a change to your SCM system, enter a commit message with the ID of the defect, user story, or quality story related to this change. When the pipeline associated with your change runs, this information is passed to OpenText Software Delivery Management. When you open the backlog items, you and your team leader get a clear picture of the files that you changed for each backlog item you worked on. Identify sensitive areas in your code, which are risky to change. You may want to simplify and refactor the code and increase testing around the functionality it covers. This should reduce the risk of future changes causing quality issues. For details, see Identify hotspots in your code.
Developer or DevOps engineer | Match build failures to specific changed files and specific backlog items.
Developer or QA engineer | Identify commits that seem to be related to failing automated tests. You can also see which commits are riskier than others because they affect hotspot files.
Dev team leader | View the team members' commits and how they relate to the items in the team backlog.
QA engineer | After verifying that a pipeline run was successful and automated tests passed, determine the areas that contain significant changes and require manual testing.
Project manager | Identify features with risky commits and consider increasing testing on these features, or postponing their release.

## Prerequisites

To track changes you need to fill the following prerequisites:

- Make sure a pipeline was created on a CI server that works with an SCM system. For details, see Create and configure pipelines.

- When committing a change to your SCM system, the commit message should include one of the patterns defined on the DevOps > SCM Change Patterns settings page. You can modify the default commit message patterns using Java regular expressions. For details, see Customize SCM change patterns.

  The default commit message patterns are:

  `defect #<defect id>`

  `user story #<user story id>`

  `quality story #<quality story id>`

  The message syntax is not case sensitive.

## Associate commits with backlog items

You can associate commits with backlog items either automatically or manually.

Commits and backlog items have a many-to-many relationship, meaning that you can associate multiple commits with multiple backlog items.

Commit method | Description
--- | ---
Associate commits automatically | When committing a change to your SCM system, add the commit pattern as defined in Customize SCM change patterns. To associate your commit with multiple backlog items, enter commit comments as in the following examples: `Defect #1001, User story #1002: I changed all of the blue icons to green ones.` `Fixed the issue of screen not refreshing. Defect #1001, Defect #1002.`
Associate commits manually | You can associate commits with backlog items manually from the following places: A specific pipeline A Development > Commits tab, such as the one in the Team Backlog module Within a backlog item To associate commits manually: On the Development > Commits tab, select the commits that you want to associate with the backlog items, and then click Link to stories. In the Add backlog items dialog box, add the items that you want to associate with the commit. To remove the link, from the commit's Backlog Items tab, select the item, and then click Remove link from commit. Or: On the Details tab of the backlog item that you want to associate with a commit, click the Link to Commits button . In the Add commits dialog box, add the commits that you want to associate with the item. To remove the link, from the backlog item's Development > Commits tab, select the item, and then click Remove link from story.

## Track commits associated with a pipeline run

You can analyze commits related to a specific pipeline run.

To access the commits of a pipeline run:

1. Open the global menu and select Quality > Pipelines > Manage.

2. Select a pipeline.

3. Open a specific pipeline run:

   - To open a latest run, in the pipelines grid, click the ID of a Last completed pipeline run.

   - To open a previous run:

     - Click a pipeline's ID to open it in details view.

     - Select the Runs tab.

     - In a grid view, filter and sort the grid to locate a specific run.

     - Click the run's ID.

You can find the following information.

Area | Description
--- | ---
Test Runs | View commits that seem to be related to failing automated tests. For details, see Analyze test failures.
Commits | View the commits included in this pipeline run. For more details, see Track committed changes in the Commits tab.
Backlog Items | View the defects, user stories, and quality stories associated with the pipeline run's commits. To associate backlog items with a commit you must list the items in commit messages using the correct syntax. For each backlog item, you can see information about the item and the associated commit. For example: The item's ID, name, and phase. The number of commits associated with the item. The names of the users who committed the changes. The number of files added, modified, or deleted by those commits. Click a backlog item's ID if you want to open the item and view more details.

If the pipeline is configured to notify committers upon run failure, users receive an email if a pipeline run that included their commits fails.

You can edit this option on the pipeline's Details tab.

Each user receives an email about their own commits. The email lists the commits, the failed builds, and the failed tests (limited to a certain number of items). It also includes a link to the relevant pipeline run's Test Runs tab.

## Track commits associated with backlog items

To track commits associated with backlog items, do one of the following:

- Use the Development > Commits tab in backlog items to find all commits related to specific backlog items. For details, see Track committed changes in the Commits tab.

- Use dashboard widgets to track and analyze your SCM changes, and their impact on your backlog. For details, see Analyze commit activity in the dashboard

## Track committed changes in the Commits tab

The Commits tab displays all changes that were associated with backlog items using SCM commit messages in the correct syntax.

You can find the Commits tab inside a pipeline run or a backlog item, or in the Team Backlog module.

Types of commits | How to view
--- | ---
Commits associated with a pipeline run. | Open the global menu and select Quality Management > Pipelines. Select a pipeline. Click the pipeline's ID to open it. In the Runs tab, click the ID of a run.
Commits associated with a backlog item via commit messages. | Click a backlog item's ID and open the Development tab.
Commits associated with backlog items defined under an epic or feature. | Click the ID of an epic or feature and open the Development tab.
Commits committed by the members of a team, during the time frame of the selected release and sprint. | In the Team Backlog, select the relevant team. Click a specific team member in the Team pane to see only that person's commits.

To view additional commit information:

For each commit, you can see additional information, such as the name of the user who committed it, and the commit message (comment).

1. Optionally, add columns to the grid to see more information. For example, the Risk column displays a risk indicator if the commit includes a change to a sensitive area of code (a hotspot).

   The Repository column is only relevant if you are working with Git or SVN.

2. You can filter the information in this tab, for example, by the name of the user who committed the change.

   Tip: To filter by user, make sure your SCM users are mapped to OpenText Software Delivery Management users. For details, see Map SCM users.

   If you are the user who committed the change, but your SCM user is not yet mapped to your OpenText Software Delivery Management user, click the Map User button to create the mapping.

3. Select a specific commit. The list of files included in this commit is displayed. If the SCM system provides the relevant information, the list differentiates between edited, added or deleted files.

   Note: If you have file names in Git that contain Unicode characters and you want to see them in OpenText Software Delivery Management, update your Git configuration as follows:

       git config --global core.quotePath false

4. For each changed file listed in a Commits pane, you can optionally enable HTTP links to the file view and diff view in your repository viewer. To enable the links, configure templates for the HTTP links. For details, see Enable links to the Git or SVN viewer.

## Analyze commit activity in the dashboard

Create custom widgets based on commits in the Dashboard or the backlog Overview.

Alternatively, use the predefined widgets provided in the Dashboard's DevOps & Analytics category. For example, you can use the Impact of changes widgets to discover the impact of source code changes.

Discover which backlog items and application modules were worked on recently, and see the number of commits related to each. This can give you an idea of the areas that need to be tested more thoroughly.

Note:

- The association of commits with features and application modules is made using the user story or defect mentioned in a commit's message.

- By default, these widgets include commits made in the last 30 days. You can configure the widget to change the time frame. For details, see Add and configure widgets.

## Analyzers

Analyzers are built-in tools that attempt to correlate between a failed test and users.

The analyzers enable you to find the users who made commits that are responsible for test failures. They can save you a significant amount of time by helping you determine who to contact if you see a failed test in your CI. This is especially useful for developers, QA engineers, and CI owners.

Test failures can occur from a variety of reasons, such as source code problems, test code issues, and environment issues.

Analyzers attempt to understand the properties of the failure and determine the most appropriate person to contact. For a source code or a test issue, this person may be a committer. In this scenario, you can view the relevant commit data which is the root cause of the failure. Alternatively, it can be a non-committer user. Although this user may not be the one who caused the failure, they may be able to shed light about why the failure occurred.

The following is a list of the analyzers. Their output suggests a relation between the test failure and a user, and in the case of committer issues, additional commit data.

Analyzer | Focus | Description
--- | --- | ---
Unstable test | Tests considered unstable | When a test is unstable, the last commit that changed the test file before it became unstable is displayed. This commit is likely to be related to the initial failure that caused the current instability.
Test stack-trace | All test failures | Looks for commits that include changes to files listed in the current test failure's stack trace.
Related files | New test failures | Looks for commits which include changes to a file which has previously been linked to this test, by analyzing committers and the Who's on it history. Whenever a committer is manually assigned as "on it" for test failure, a relation is built between their committed files to the test. This is then used to identify related commits for new failures.
Same application module | New test failures | Looks for commits related to an application module that was assigned to the test. Commits are related to application modules via the stories mentioned in the commit message and the features to which those stories belong.
Same feature | New test failures | Looks for commits related to an application module that is assigned to the test. Commits are related to features via the stories mentioned in the commit message.
Last on it | New test failures | Looks for the last person who fixed this test, by looking at the ‘assigned to’ field.
Test owner | New test failures | Provides the owner of the test, as a recommendation for people who might help with test investigation.
Cluster | New test failures | Looks for other users who took responsibilities for a test that failed due to the same reason (they are in the same test failure cluster). For details, see Expand your test failure analysis.
Commit message | New test failures | Checks the commit message text and looks for a relation between the full test name and the commit message.
Committed files | New test failures | Checks committed files and their names and looks for a relation between the full test name and files.

## Find commits related to failures

When analyzing pipeline run failures, the Test Runs tab displays the commits that may be related to test run failures. For details, see Expand your test failure analysis.

Keywords in the committed files list and commit messages are highlighted. These keywords triggered the analyzer to list a user as a suspect for the test failure. The highlighting is based on the two analyzers:

Analyzer | Runs on… | Description
--- | --- | ---
Commit message | New test failures | Checks the commit message text and looks for a relation between the full test name and the commit message.
Committed files | New test failures | Checks committed files and their names, and looks for a relation between the full test name and files.

Administrators can list specific words to exclude from the analyzer, using the BLAME_COMMITTER_ANALYZERS_EXCLUDE_WORDS site parameter. The analyzer won't trigger a blame report for the committer when it detects one of these words. For details, see Configuration parameters.

For more details about the analyzers, see Analyzers.

## Map SCM users

Identifying the users who commit SCM changes as OpenText Software Delivery Management users lets you analyze the commit information using widgets and filters.

If the email address defined for an SCM user is identical to the one defined for an OpenText Software Delivery Management user, the users are mapped automatically when changes they commit are discovered.

Tip: Make sure that your SCM system is configured to share commit authors with your CI server. For example, in the Jenkins GIT plugin, set the Use commit author in changelog option.

Otherwise, your space admin can map the users manually. For details, see Roles and permissions.

Alternatively, individual users can map themselves to unmapped SCM users listed in Commits tabs. For details, see Track committed changes in the Commits tab.

## Troubleshooting

The following is troubleshooting for commits to your SCM system.

Issue | Troubleshooting
--- | ---
You don't see commit information on the pipeline | If the OpenText Software Delivery Management server was restarted while the pipeline was running, change information will be available only after the pipeline runs. Try running the pipeline again.
You don't see commits associated with your backlog items, or vice versa | Make sure your commit messages follow the correct syntax.

## See also

- Set up CI/CD integration
- Set up your SCM system
- Create and configure pipelines
- Run pipelines

https://admhelp.microfocus.com Software Delivery Management 8942
Tips to improve your search results... OpenText™ Software Delivery Management Help Center OpenText™ Software Delivery Management Help 26.3 All View Local Help Center View Online Help Center Version: