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

OpenText Core Software Delivery Platform 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.

Back to top

Use-cases for tracking commits

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

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 Core SDP. 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.

Back to top

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.

Back to top

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.

Back to top

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. In the Pipelines module, open the Pipelines > Manage tab and select a pipeline.

2. Open a specific pipeline run:

   • To open the last run, click the pipeline's Run number.

   • To open a previous run, click the pipeline's ID to open the pipeline. In the Runs tab, click the ID of a specific run.

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.

Back to top

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

Back to top

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 Pipelines module. 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 Core SDP 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 Core SDP 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 Core SDP, 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.

Back to top

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.

Back to top

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.

Back to top

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.

Back to top

Map SCM users

Identifying the users who commit SCM changes as OpenText Core SDP 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 Core SDP user, the users are mapped automatically when changes they commit are discovered.

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.

Back to top

Troubleshooting

The following is troubleshooting for commits to your SCM system.

Issue	Troubleshooting
You don't see commits associated with your backlog items, or vice versa	Make sure your commit messages follow the correct syntax.

Back to top

See also:

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