Commits included in DevOps change request

Release version: Australia

Updated March 12, 2026

6 minutes to read

Summarize

Summarized using AI

Summary of Commits included in DevOps change request

This document outlines how commits are included in a DevOps change request based on the type of change, detailing both manual and automated commit inclusion processes. Understanding this is crucial for ServiceNow customers managing artifact versions and tracking commit histories in their DevOps workflows.

Show full answer Show less

Key Features

Change Type Commit Inclusion:
- Manual: Includes commits from artifact versions and any task executions linked to the change.
- Automated Without Package: All commits from artifact versions linked to pipeline executions are included.
- Automated With Package: Includes commits from the last successful production deployment if the change has a production deploy step; otherwise, all artifact version commits are included.
Commit Types:
- Normal Commits: Standard commits tracked in the repository.
- Revert Commits: Not associated with the change request if a revert is performed.
- Merge Commits: Includes commits that merge changes from different branches.
- Squash and Merge: Keeps changes while removing individual commit history.
Semantic Versioning: Uses versioning format (MAJOR.MINOR.PATCH) to determine commit inclusion, excluding patch and hotfix versions.

Key Outcomes

ServiceNow customers can expect that:

All relevant commits from pipeline executions are tracked and associated with the correct artifact versions.
Changes in commit status will be reflected accurately in the change request, including all applicable commits from previous artifact versions built on the same branch.
Ability to customize commit logic for different step types in the deployment pipeline enhances flexibility in managing changes.

By understanding the commit inclusion process, customers can effectively manage their version control and deployment processes, ensuring accurate tracking of changes throughout their DevOps lifecycle.

The DevOps artifact package and its associated artifact versions are used to determine which commits are included in a DevOps change.

Commits are included in a change based on the change type.


Change type	Commits included
Manual	Commits from the artifact versions of the package in the change. In addition, the commits from task executions of all the pipeline executions in the change reference record when the data_type column is plan or pipeline execution are included.
Automated	Without package: All commits from the artifact versions are included. The artifact versions are the ones that are linked to the pipeline execution and the task executions for that pipeline execution. With package: If any of the upstream task executions of the change has the prod deploy step, then commits from the last successful prod deploy pipeline execution are included. Commits that appear in multiple pipeline executions will be listed only once. If the prod deploy step is not present in the upstream task executions, the commits from all the artifact versions of the package are included. Run commits: If there are no commits from either of the with or without package flow as specified previously, then the run commits from the upstream task executions of the change request are associated.

All commits for artifact versions in the package that were generated after the last deployment date (up to the version currently being deployed) are included in the change request. Previous major versions are not included.

Note:

Patch and hot fix versions are excluded.

When provided, semantic version is used to determine commits for a change. Format is (MAJOR.MINOR.PATCH). For example, semantic version 2.0.1 is read as follows:

Major version 2
Minor version 0
Patch/hotfix version 1

Failed task executions between the previous and current artifact versions that did not build an artifact but have associated commits are also associated to the created artifact version.

Types of commits

Normal commits: Commits on the tracked repository are associated to the change request.
Revert commits: Commits that have the revert field value as true. A revert commit results in a reverted commit and revert commit in the source tree. Both the commits are not associated to the change request.
Merge commits: Commits that have the merge field value as true.
- Merge commit: The source tree tracks the commit to a branch over time and allows for a special merge commit to be made. This merge commit combines the parent commits located directly after the most recent common commit on both the current branch and the branch to be merged. Merge commit adds a new commit on the main branch.
- Squash and merge: Squashing during a merge generates the working tree and index state to match a merge without creating a merge commit. Squash and merge keeps the changes but removes the individual commits from history. It has a single commit with the merge value as true.

Example: Commits and packages

This example consists of:

Three build pipelines (A, B, and C)
A release pipeline (ABC) under change control, with four packages:
1. Build pipeline A (major version 1)
2. Build pipelines A and B (major version 1)
3. Build pipelines B and C (major version 1)
4. Build pipelines A, B, and C (major version 1)

Table 1. Package 1 (A 1.1.0)
Commit	Build pipeline	Semantic version	Included in package
1	A	1.0.0	X
2	A	1.0.1	--
3	A	1.1.0	X
Note: Commit 2 (build A, semantic version 1.0.1) is not included in the package because the semantic version syntax indicates a patch or hot fix.

Table 2. Package 2 (A 1.2.0, B 1.1.0)
Commit	Build pipeline	Semantic version	Included in package
4	A	1.1.1	--
5	A	1.2.0	X
6	A	1.2.0	X
7	B	1.0.0	X
8	B	1.0.0	X
9	B	1.1.0	X
10	B	1.1.0	X
Note: Commit 4 (build A, semantic version 1.1.1) is not included because the semantic version syntax indicates a patch or hot fix.

Table 3. Package 3 (B 1.2.0, C 1.0.0)
Commit	Build pipeline	Semantic version	Included in package
11	A	1.3.0	--
12	B	1.2.0	X
13	B	1.2.0	X
14	C	1.0.0	X
15	C	1.0.0	X
16	C	1.0.0	X
Note: Commit 11 (build A, semantic version 1.3.0) is not included because the package does not specify build A.

Table 4. Package 4 (A 1.4.0, B 1.3.0, C 1.2.0)
Commit	Build pipeline	Semantic version	Included in package
17	A	1.4.0	X
18	A	1.4.0	X
19	B	1.3.0	X
20	B	1.3.0	X
21	C	1.1.0	X
22	C	1.1.0	X
23	C	1.2.0	X
24	C	1.2.0	X
Note: Commit 11 is also included in this package because it is part of the changes in major version 1 of build A since the last package (including major version 1 of build A), package #2, was deployed to production.

Example: Commit calculation logic

Use case with the logic for calculating commits that get associated to artifact versions. The branch information is included whenever the commits are defined.

For example, consider two pipelines, one on the main branch, one on the test branch. Run scenario:

Create a commit C0 on main, run CI build, but don’t create Artifact Version.
Create a commit C1 on test, run CI build, but don’t create Artifact Version.
Create a commit C2 on main, run CI build and the build fails.
Create 2 commits C3,C4 on main, run a CI build and create an Artifact Version (v1.0).

Expected result: Artifact Version (v1.0) is associated to C0, C2, C3, C4. Commit C1 is excluded as it's on a different branch.

Continuing with the use case:

Create 1 commit C5 on main, run CI build, but don’t create Artifact Version.
Create 1 commit C6 on main, run CI build and create an Artifact Version (v2.0).

Expected result: The new artifact version (v2.0) created is associated to C5, C6.

Summary:

All commits from pipeline executions (success & failed) in the same branch, between last Artifact Version for a given Artifact and current Artifact Version, are associated.
If no previous Artifact Version for the given Artifact is found, then all commits from pipeline executions in the same branch are associated.

Continuing with the use case:

Create a release with Artifact Version from the previous step, have a CD pipeline with Step type = Prod Deploy.

Expected result:

Release is associated with the same Artifact Version (v2.0).
Change Request created shows Artifact Version (v2.0) and Commits C0, C2, C3, C4, C5, C6.

Summary:

Commits from both Artifact Versions (v1.0, v2.0) built on main branch (no previous package was deployed to Prod) are shown in the change request, but not the commit from execution on test branch.
The number of commits shown in the change request will be the same as the number in the tool.

Continuing with the use case:

Create 2 commits C7, C8 on test branch, run CI build and create an Artifact Version.
Expected result: Artifact Version (v3.0) is associated to C1, C7, C8.
Create 2 commits C9, C10 on main branch, run CI build and create an Artifact Version.
Expected result: Artifact Version (v4.0) is associated to C9, C10.
Create a release with Artifact Version from previous step (v4.0), have a CD pipeline with Step type = Prod Deploy.
Expected result:
- Release is associated with Artifact Version (v4.0).
- Change Request created shows Artifact Version (v4.0) and commits C9, C10.

Summary:

The change request shows commits just from the latest Artifact Version built on main branch, as commits from previous Artifact Versions built on main had been deployed to Prod on the previous package.
The number of commits shown in the change request will be the same as the number in the tool.
To have other step types, like Test or Deploy, use the same commit logic as Prod Deploy, update the Controls whether other Step types should follow the same logic as Prod Deploy to determine commits for a Change [sn_devops.commit_rel_change_step_type] property. Specify which step types (such as Deploy and Test) should use the same commit logic as Prod Deploy as the property value. If these are set up, the Prod Deploy commit process will also apply to their relationship scripts.