Artifacts and packages
-
- UpdatedJan 30, 2025
- 11 minutes to read
- Yokohama
- DevOps
Artifacts and packages enable DevOps Change Velocity to track development and testing activities across a wide range of deployment and release models. This feature ensures that pipeline activity stored in the DevOps data model can be retrieved and applied when artifacts are created and released at different times or in different pipelines.
Artifacts
When an artifact version is registered, related activities like commits, tests, and code scans are tracked so that regardless of when the artifact version is deployed, those details can be retrieved. It can be in the current pipeline execution, a later execution of the same pipeline, a pipeline that is triggered by the current one, or a separate pipeline that is triggered independently.
When you associate commits with an artifact version (CI pipeline), and define an artifact package (CD pipeline), all artifact versions generated since the last time the app was deployed to production are included in the list of commits for the change. Consolidation of these items is helpful, especially when there are multiple CI builds before the deployment.
- Category DevOps or the Categorize DevOps change requests on "DevOps Change" field check box is selected in DevOps properties. For more information, see DevOps change request without mandating category as DevOps.
- Commits and Work Items related lists
Packages
- Retrieval of activities for all artifact versions declared in the package. For example, for use in an automated change approval policy.
- Recording when a specified artifact version was successfully released, ensuring that information tied to them is no longer considered. For example, for later change requests.
Artifact setup
- Create an artifact tool record in DevOps.Note: An artifact tool isn’t necessary unless a webhook or user-created integration subflow configuration is required to look up artifact versions.
- Register artifacts in the CI pipeline.
- Create a package in the CD pipeline.Note: The package creation step must be before the Prod Deploy step.
Artifact registration
Configure artifact registration in a scripted pipeline or freestyle job using the DevOps API /artifact/registration endpoint. Multiple artifact versions are supported.
Scripted and declarative pipeline (snDevOpsArtifact Jenkinsfile command)
For example:Freestyle job (Register Artifact build step)
For example:
Artifact package creation
Freestyle job (Create Package build step)
For example:
Declarative and scripted pipeline (snDevOpsPackage Jenkinsfile command)
Package with more than one artifact (from different repos) in the payload, for example:
Jenkins plugin step includeBuildInfo can be used to include build details in the API call.
Artifact workflow and objects
The orchestration tool job publishes the new artifact (consisting of versions) to the artifact repository. Each artifact version is associated with a task execution (consisting of the related code commits). A package is created for the release (consisting of specific artifact versions flagged for deployment) and, after the deployment stage completes, the package is marked as deployed to production.
These objects are part of the artifact structure.
Artifact tool
Used to support artifact repository managers such as JFrog Artifactory.
Note: An artifact tool isn’t necessary unless a webhook or user-created integration subflow configuration is required to look up artifact versions.Artifact repository
Target for artifacts generated in a build, and also a source of artifacts required by a build. Can be created manually, or through the RegisterArtifact API as new artifacts are published under new repositories in a tool.
Artifact
Artifact name for which different builds (artifact versions) are generated. Can be created manually, or through the RegisterArtifact API. Artifacts (versions) are associated with a task execution and published to an artifact repository.
Artifact version
Specific version of the artifact. Deployable component of an application generated by a CI build. When provided, semantic version is used.
Can be created through discovery, or through the RegisterArtifact API. Artifacts (versions) are associated with a task execution and published to a tracked artifact repository.
Semantic version
Optional attribute of an artifact version that, when provided, is used to determine commits for a change. Semantic version format is (MAJOR.MINOR.PATCH).
Package
Collection of artifact versions used as input to a CD pipeline, or for associating test results.
Package creation is triggered by the CreatePackage API call from the orchestration tool and contains the name, version, and repository name of all the artifact versions included in the package. A check box indicates whether the package has been deployed to production.
Example






You can also see all existing pipeline change requests directly from the Changes module in the application navigator.
You can see all existing change control and pipeline change requests directly using the Changes module in the application navigator.
Navigate to
for all change-related information.Pipeline change requests

You can see all the existing artifacts and packages directly using the List module in the application navigator.
Navigate to
for all artifact-related information.
Artifacts and packages monitoring
When artifacts and packages are registered from a source tool into ServiceNow, they are often staged in the sn_devops_artifact_staging table, while the remaining necessary data for creation and linkage of these objects is either received from inbound events, or fetched by DevOps flows.
Most of the times, these staging records are processed within a few seconds. But there may be cases where the necessary data is never received, so these records may be left idle. The Description field on the table below contains a summary of the details missing in such cases to help in easier monitoring.