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.
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 |
|
Backlog |
|
Team Backlog |
|
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 |
|
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:
|
Associate commits manually |
You can associate commits with backlog items manually from the following places:
To associate commits manually:
Or:
|
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:
-
In the Pipelines module, open the Pipelines > Manage tab and select a pipeline.
-
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, and more:
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:
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. |
|
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).
-
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.
-
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.
-
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
-
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 Configure widget settings.
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 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.
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 commits associated with your backlog items, or vice versa |
Make sure your commit messages follow the correct syntax. |
See also: