Spinnaker Artifacts - Legacy UI

This section refers to the legacy artifacts UI, which was removed in release 1.21. Please refer to the standard artifacts guide instead.

In Spinnaker, an artifact is an object that references an external resource. That resource could be…

  • a Docker image
  • a file stored in GitHub
  • an Amazon Machine Image (AMI)
  • a binary blob in S3, GCS, etc.

Any of these can be fetched using a URI , and can be used within a Spinnaker pipeline.

However, a URI alone isn’t always enough. Take the following examples:

  • You have a “Bake Image” stage that defines which packages are to be consumed, which images are deployed into each environment, and which configuration files are mounted. If each of these artifact types is just a URI, you have to write (and maintain) RegEx (or similar) against URIs to match artifacts to stages.

  • Your build system produces provenance information about your Docker images (for example, which commit triggered the build, which build steps were used). This isn’t easy to store in or retrieve from the Docker image, but you want to trigger the pipeline on the arrival of a new image. If all you capture is the URI (for example, gcr.io/your-project/your-image:v1.0.0) you lose that provenance information.

  • Your Spinnaker instance is used by many teams in your organization, and your authorization policies isolate teams’ infrastructure and pipelines from each other. You probably want your packages, configs, and images published and accessible only by the teams that need them. You need a way to annotate a URI with an account that can fetch it based on a user’s permissions.

To address situations like these, Spinnaker includes a format for supplying URIs alongside pertinent metadata. We call this “artifact decoration”.

Decorate your artifacts

In Spinnaker, artifacts must match a specification. This specification is consistent among all artifacts, whether they’re supplied to pipelines, accessed within pipelines, or produced by pipelines.

Every time we refer to an Artifact, we mean a JSON payload matching this specification, not the actual artifact contents. The key distinction is that the artifact is a reference or a pointer to a resource, not the resource itself.

Format

  1. {
  2.   "type":       // How this artifact is classified. Allows for easy distinction
  3.                 // between docker images and debian packages, for example.
  5.   "reference":  // The URI.
  7.   "artifactAccount": // The account configured within Spinnaker that has
  8.                 // permission to download this resource.
  10.   "name":       // (Optional) A human-readable name that makes matching
  11.                 // artifacts simpler.
  13.   "version":    // (Optional) The version of this artifact. By convention, the
  14.                 // "version" should be compared against other artifacts with
  15.                 // the same "type" and "name".
  17.   "provenance": // (Optional) A link to whatever produced this artifact. This
  18.                 // is used for deep-linking into other systems from Spinnaker.
  20.   "metadata":   // (Optional) Arbitrary k/v metadata useful for scripting
  21.                 // within stages.
  23.   "location":   // (Optional) The region/zone/namespace this artifact can be
  24.                 // found in. This doesn't add information to the URI, but makes
  25.                 // multi-regional deployments easier to configure.
  27.   "uuid":       // (Assigned by Spinnaker) Used for tracing artifacts within
  28.                 // Spinnaker.
  29. }

Examples

  1. // A docker image
  2. {
  3.   "type": "docker/image",
  4.   "reference": "gcr.io/project/image@sha256:29fee8e284",
  5.   "name": "gcr.io/project/image",
  6.   "version": "sha256:29fee8e284"
  7. }
  1. // A GCS object
  2. {
  3.   "type": "gcs/object",
  4.   "reference": "gs://bucket/file.json#135028134000",
  5.   "name": "gs://bucket/file.json",
  6.   "version": "135028134000"
  7.   "location": "us-central1"
  8. }
  1. // An S3 object
  2. {
  3.   "type": "s3/object",
  4.   "name": "s3://bucket/file.json",
  5.   "location": "us-east-1"
  6. }

Example for providing artifacts with spin CLI

When you execute a pipeline with the <code>spin</code> CLI , the -t, --artifacts-file option expects a valid JSON file containing a top-level artifacts key that maps to an array of artifact definitions as mentioned here . For example, you can call…

  1. spin pipeline execute --application ${APPLICATION} --name ${PIPELINE} --parameter-file ${PARAMETER_FILE_PATH} --artifacts-file ${ARTIFACTS_FILE_PATH}

…with the contents of the file at ${ARTIFACTS_FILE_PATH} as follows:

  1. {
  2.   "artifacts" : [
  3.     {
  4.       "type": "s3/object",
  5.       "name": "s3://bucket/file.json",
  6.       "location": "us-east-1"
  7.     },
  8.     {
  9.       "type": "s3/object",
  10.       "name": "s3://bucket/file2.json",
  11.       "location": "us-east-1"
  12.     }
  13.   ]
  14. }
Artifacts from Build Triggers
Artifacts In App Engine (Legacy)
Artifacts In Kubernetes (Legacy)
Artifacts In Pipelines (Legacy)
Types of Artifacts

Last modified August 27, 2021: docs(fix): fix link to point to the correct artifacts reference page (#138) (6fed4a2)