--- sourceDocument: Australia IT Service Management sourceDocumentLink: https://www.servicenow.com/docs/r/australia/it-service-management Release : - australia ft:locale : - en-US ft:publication_title : - Australia IT Service Management ft:clusterId : - itsm bundleId : - itsm workflow : - Technology --- # Commits included in DevOps change request # Commits included in DevOps change request {#ariaid-title1} Release version: Australia Updated March 12, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 6 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Commits included in DevOps change request This documentation explains how commits are associated with DevOps change requests in ServiceNow. It details the logic used to determine which commits are included in a change request based on change types, artifact packages, pipeline executions, and semantic versioning. This helps ServiceNow customers accurately track code changes related to deployment activities, ensuring precise visibility and traceability of changes in their DevOps processes. Show full answer Show less ## Commit Inclusion Based on Change Type * **Manual Changes:** Commits linked with artifact versions of the package and commits from pipeline executions with data types "plan" or "pipeline execution" are included. * **Automated Changes Without Package:** All commits from artifact versions linked to the pipeline execution and its tasks are included. * **Automated Changes With Package:** If any upstream task execution includes a production deploy step, commits from the last successful production deploy pipeline execution are included, avoiding duplicates. If no production deploy step exists, commits from all artifact versions in the package are included. * **Run Commits:** If no commits result from the above flows, commits from upstream task executions are associated. ## Semantic Versioning and Commit Inclusion Semantic versioning (format: MAJOR.MINOR.PATCH) is used to determine which commits are included. Commits from patch or hotfix versions (PATCH) are excluded. Only commits from the current major version after the last deployment date are considered. Failed task executions that didn't build artifacts but have associated commits are also linked to the artifact version. ## Types of Commits Handled * **Normal Commits:** Standard commits on the tracked repository associated with the change request. * **Revert Commits:** Commits marked as revert are excluded along with their reverted counterparts. * **Merge Commits:** Commits created by merging branches, either as standard merge commits or squash merges, with squash merges consolidating changes into a single commit marked as merged. ## Commit Calculation Logic Example The documentation provides a detailed example, illustrating how commits from different branches and pipelines are associated with artifact versions and change requests: * Commits on the same branch between the last and current artifact versions are associated with the new artifact version. * Commits on other branches are excluded unless a new artifact version is created on that branch. * Change requests include commits from all relevant artifact versions unless previous versions were already deployed to production. * Production deploy pipeline steps trigger association of commits from the last successful production deploy. ## Configuration for Additional Pipeline Step Types Customers can extend the commit association logic used for production deploy steps to other step types such as Test or Deploy by configuring the property **sndevops.commitrelchangesteptype**. Specifying these step types enables their commit association process to follow the same logic as production deploy steps. ## Practical Benefits for ServiceNow Customers * Ensures accurate mapping of code commits to change requests, improving traceability and auditability of deployed changes. * Supports complex pipeline and branching strategies by associating commits only from relevant branches and artifact versions. * Excludes irrelevant commits such as patch or hotfix versions and revert commits to maintain clear change histories. * Flexible configuration allows aligning commit association with organizational deployment practices and pipeline structures. 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.{#dev-ops-commits-release__table_myb_wnq_zzb__entry__2} | 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. {#dev-ops-commits-release__ul_rrq_gnq_zzb} | [ ] {#dev-ops-commits-release__table_myb_wnq_zzb} 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 {#dev-ops-commits-release__ul_chw_zyz_rkb} 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 {#dev-ops-commits-release__section_g12_lmq_zzb} * 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. {#dev-ops-commits-release__ul_h2y_tmq_zzb} {#dev-ops-commits-release__ul_nkx_nmq_zzb} ## Example: Commits and packages {#dev-ops-commits-release__section_pd4_zhv_rkb} 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) {#dev-ops-commits-release__ol_nsy_bzw_rkb} {#dev-ops-commits-release__ul_sny_xyw_rkb} {#dev-ops-commits-release__table_fk1_33v_rkb__entry__4} | 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 1. Package 1 (A 1.1.0)] {#dev-ops-commits-release__table_fk1_33v_rkb} {#dev-ops-commits-release__table_in3_ljv_rkb__entry__4} | 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 2. Package 2 (A 1.2.0, B 1.1.0)] {#dev-ops-commits-release__table_in3_ljv_rkb} {#dev-ops-commits-release__table_v5g_dnv_rkb__entry__4} | 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 3. Package 3 (B 1.2.0, C 1.0.0)] {#dev-ops-commits-release__table_v5g_dnv_rkb} {#dev-ops-commits-release__table_prg_xnv_rkb__entry__4} | 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. |||| [Table 4. Package 4 (A 1.4.0, B 1.3.0, C 1.2.0)] {#dev-ops-commits-release__table_prg_xnv_rkb} ## Example: Commit calculation logic {#dev-ops-commits-release__section_kxf_4z4_vbc} 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). {#dev-ops-commits-release__ul_qxh_41p_vbc}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). {#dev-ops-commits-release__ul_glf_gbp_vbc}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. {#dev-ops-commits-release__ul_ejh_4bp_vbc} 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. {#dev-ops-commits-release__ul_nxx_bjp_vbc} 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. {#dev-ops-commits-release__ul_vlv_4jp_vbc} 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. {#dev-ops-commits-release__ul_ylc_ykp_vbc} {#dev-ops-commits-release__ul_df1_pkp_vbc} 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. {#dev-ops-commits-release__ul_wg2_flp_vbc}