Spinnaker – Types of Artifacts

Docs: Bitbucket File

Mon, 01 Jan 0001 00:00:00 +0000

These artifacts are generally consumed by stages that read configuration from text files, such as a Deploy Manifest stage.

Bitbucket file artifact in the UI

The pipeline UI exposes the following fields for the Bitbucket file artifact:

Field	Explanation
Account	A Bitbucket artifact account.
File path	The full path (including filename) for retrieval via the Bitbucket API. Example: `https://api.bitbucket.org/2.0/repositories/$ORG/$REPO/src/$VERSION/$FILEPATH`.

In a trigger

When configuring certain triggers, you can use a Bitbucket file as an expected artifact.

Configuring Bitbucket file fields in a pipeline trigger’s expected artifact settings.

In a pipeline stage

When configuring a “Deploy (Manifest)” or “Deploy” stage, you can use a Bitbucket file as a manifest or application artifact. You can either use a previously-defined artifact (for example, an artifact defined in a trigger) or define an artifact inline.

Bitbucket file artifact in a pipeline definition

The following are the fields that make up a Bitbucket file artifact:

Field	Explanation
`type`	Always `bitbucket/file`.
`reference`	The full path (including filename) for retrieval via the Bitbucket API. Example: `https://api.bitbucket.org/2.0/repositories/$ORG/$REPO/src/$VERSION/$FILEPATH`.
`name`	The path to the file within your repository. Example: `path/to/file.yml`.
`version`	N/A–must be specified in `reference`.
`location`	N/A.

The following is an example JSON representation of a Bitbucket file artifact, as it would appear in a pipeline definition:

{
  "type": "bitbucket/file",
  "reference": "https://api.bitbucket.org/2.0/repositories/org/repo/src/master/manifests/config.yaml",
  "name": "manifests/config.yaml"
}

Docs: Debian Package

Mon, 01 Jan 0001 00:00:00 +0000

These artifacts are generally consumed by the Bake stage.

HTTP file artifact in the UI

The pipeline UI exposes the following fields for the Debian Package artifact:

	Explanation
Account	An HTTP artifact account.
URL	The fully-qualified URL from which the file can be read.

In a trigger

When configuring certain triggers, like Pubsub you can use a custom artifact.

Configuring Debian Package fields in a pipeline trigger’s expected artifact settings.

In a pipeline stage

When configuring a “Bake” stage, it automatically searches for a Debian package artifact in the context.

Debian Package artifact in a pipeline definition

The following are the fields that make up an HTTP file artifact:

Field	Explanation
`type`	Always `deb`.
`reference`	The full name of the package file.
`name`	The name of the package.
`version`	Version of the package.
`location`	N/A

The following is an example JSON representation of an HTTP file artifact, as it would appear in a pipeline definition:

{
    "type": "deb",
    "name": "spinnaker-igor",
    "version": "1.54.0.224.692755-3_all",
    "reference": "spinnaker-igor_1.54.0.224.692755-3_all.deb"
}

Docs: Docker Image

Mon, 01 Jan 0001 00:00:00 +0000

The artifacts can be deployed to Kubernetes or App Engine, and generally trigger pipelines from notifications sent by their registry.

Docker image artifact in the UI

The pipeline UI exposes the following fields for the Docker image artifact:

Field	Explanation
Account	A Docker registry artifact account.
Docker image	The name of the Docker image, including the registry and image repository.

In a trigger

When configuring the Docker Registry trigger, you can use a Docker image as an expected artifact.

Configuring Docker image fields in a pipeline trigger’s expected artifact settings.

In a pipeline stage

When configuring certain stages, such as a “Deploy (Manifest)” stage, you can use a Docker image as a required artifact. You can either use a previously-defined artifact (for example, an artifact defined in a trigger) or define an artifact inline.

Configuring a Deploy (Manifest) stage to use a Docker image as a required artifact.

Docker image artifact in a pipeline definition

The following are the fields that make up a Docker image artifact:

Field	Explanation
`type`	Always `docker/image`.
`reference`	The fully-qualified image name, including the version and registry. This can be done by either tag (`gcr.io/project/my-image:v1.2`) or image digest `gcr.io/project/my-image@sha256:28f82eba`.
`name`	The image’s name (typically the registry and repository) without the image’s version. Example: `gcr.io/project/my-image`
`version`	The image’s tag or digest.
`location`	N/A

The following is an example JSON representation of a Docker image artifact, as it would appear in a pipeline definition:

{
  "type": "docker/image",
  "reference": "gcr.io/project/my-image@sha256:28f82eba",
  "name": "gcr.io/project/my-image",
  "version": "sha256:28f82eba"
}

Docs: Embedded Base64

Mon, 01 Jan 0001 00:00:00 +0000

Embedded Base64 artifact in the UI

The pipeline UI exposes the following fields for the embedded Base64 artifact:

Field	Explanation
Account	Always "embedded-artifact".
Name	A human-readable identifier for the artifact.
Contents	The Base64-encoded contents of the artifact.

In a trigger

When configuring a trigger, you can (for example) configure an embedded Base64 default artifact.

Providing an embedded Base64 default artifact for a trigger’s expected artifact.

In a pipeline stage

When configuring certain stages, such as a “Deploy (Manifest)” stage, you can use embedded Base64 for a required artifact. You can either use a previously-defined artifact (for example, an artifact defined in a trigger) or define an artifact inline.

Configuring a Deploy (Manifest) stage to use an embedded artifact.

Embedded Base64 artifact in a pipeline definition

The following are the fields that make up an embedded Base64 artifact:

Field	Explanation
`type`	Always `embedded/base64`.
`reference`	The Base64-encoded artifact contents.
`name`	An optional human-readable identifier.

The following is an example JSON representation of an embedded Base64 artifact, as it would appear in a pipeline definition:

{
  "type": "embedded/base64",
  "reference": "dmFsdWU6IDEKbXlrZXk6IG15dmFsdWU=",
  "name": "my-properties-file",
}

Docs: GCS Object

Mon, 01 Jan 0001 00:00:00 +0000

These artifacts are generally consumed by stages that read configuration from text files, such as a Deploy Manifest or App Engine Deploy stage.

GCS object artifact in the UI

The pipeline UI exposes the following fields for the GCS object artifact:

Field	Explanation
Account	A GCS artifact account.
Object path	The path to the artifact file, beginning with `gs://`.

In a trigger

When configuring certain triggers (such as a Pub/Sub trigger with Pub/Sub System Type “Google”), you can use a GCS object as an expected artifact.

Configuring GCS object fields in a pipeline trigger’s expected artifact settings.

In a pipeline stage

When configuring a “Deploy (Manifest)” or “Deploy” stage, you can use a GCS object as a manifest or application artifact. You can either use a previously-defined artifact (for example, an artifact defined in a trigger) or define an artifact inline.

Configuring a Deploy (Manifest) stage to use a GCS object as a manifest source.

GCS object artifact in a pipeline definition

The following are the fields that make up a GCS object artifact:

Field	Explanation
`type`	Always `gcs/object`.
`reference`	The reference to the artifact file, beginning with `gs://` and optionally ending with the object’s version . Example: `gs://bucket/file.yml#1360383693620000`
`name`	The same as `reference`, but never with a version.
`version`	The object’s version , if applicable.
`location`	N/A

The following is an example JSON representation of a GCS object artifact, as it would appear in a pipeline definition:

{
  "type": "gcs/object",
  "reference": "gs://bucket/file.yml#1360383693620000",
  "name": "gs://bucket/file.yml",
  "version": "1360383693620000"
}

Docs: Git Repo

Mon, 01 Jan 0001 00:00:00 +0000

The Git Repo artifact is available in version 1.17 or later.

They are consumed by stages that need multiple files to produce an output, such as the Bake (Manifest) stage when using the Kustomize template renderer. Unlike other artifact implementations, the Git Repo artifact works with any Git hosting service as long as the repository can be cloned using the Git CLI.

Git Repo artifact in the UI

The pipeline UI exposes the following fields for the Git Repo artifact:

Field	Explanation
Account	A Git Repo artifact account.
URL	HTTP or SSH URL of your Git repository. Use HTTP for artifact accounts configured to use a username and password, and use the SSH URL format for accounts configured to use the SSH private key.
Branch	Name of the branch to check out. Default is `master`.
Sub Path (Optional)	Relative path of files within the repository to fetch. If set, only files this path will be available to stages consuming this artifact.

In a trigger

Work to support Git Repo artifacts in triggers is currently underway.

In a pipeline stage

When configuring the “Bake (Manifest)” stage, you can use a Git Repo artifact as an expected artifact.

Configure a Bake (Manifest) stage to use a Git Repo artifact.

Git Repo artifact in a pipeline definition

Field	Explanation
`type`	Always `git/repo`.
`reference`	HTTPS or SSH URL of your Git repository. Use HTTPS for artifact accounts configured to use a username and password, and use the SSH URL format for accounts configured to use an SSH private key.
`version`	Name of the branch to check out. Default is `master`.
`metadata.subPath`	Relative path of files within the repository to fetch. If set, only files in this path are available to stages consuming this artifact.

Artifact accounts using an SSH private key for authentication.

{
    "type": "git/repo",
    "reference": "git@github.com:spinnaker/spinnaker.github.io",
    "version": "feat-123"
}

Artifact accounts using a username and password or token for authentication.

{
    "type": "git/repo",
    "reference": "https://github.com/spinnaker/spinnaker.github.io",
    "version": "feat-123"
}

When checking out an explicit sub path within repository.

{
    "type": "git/repo",
    "reference": "https://github.com/spinnaker/spinnaker.github.io",
    "version": "feat-123",
    "metadata" : {
        "subPath": "reference/artifacts/types"
    }
}

Docs: GitHub File

Mon, 01 Jan 0001 00:00:00 +0000

These artifacts are generally consumed by stages that read configuration from text files, such as a “Deploy (Manifest)” stage.

GitHub file artifact in the UI

The pipeline UI exposes the following fields for the GitHub file artifact:

Field	Explanation
Account	A GitHub artifact account.
File path	The path to the artifact file, beginning at the root of the Git repository.
Content URL	The GitHub API content URL for the artifact file.
Commit/Branch	The commit hash or branch name to use when retrieving the artifact file from GitHub.

In a trigger

When configuring a Git trigger with Type “GitHub”, you can use a GitHub file as an expected artifact.

Configuring GitHub file fields in a pipeline trigger’s expected artifact settings.

In a pipeline stage

When configuring certain stages, such as a “Deploy (Manifest)” or “Deploy” stage, you can use a GitHub file as a manifest or application artifact. You can either use a previously-defined artifact (for example, an artifact defined in a trigger) or define an artifact inline.

Configuring a Deploy (Manifest) stage to use a GitHub file as a manifest source.

GitHub file artifact in a pipeline definition

The following are the fields that make up a GitHub file artifact:

Field	Explanation
`type`	Always `github/file`.
`reference`	The full path (including filename) for retrieval via the GitHub API. This is the `contents_url` referenced by a PushEvent . GitHub example: `https://api.github.com/repos/myorg/myrepo/contents/path/to/file.yml`. GHE example: `https://github.mydomain.com/api/v3/repos/myorg/myrepo/contents/path/to/file.yml`.
`name`	The path to the artifact file, beginning at the root of the Git repository. Example: `path/to/file.yml`.
`version`	The commit hash, branch name, or tag to use when retrieving the artifact file from GitHub.
`location`	N/A

The following is an example JSON representation of a GitHub file artifact, as it would appear in a pipeline definition:

{
  "type": "github/file",
  "reference": "https://api.github.com/repos/myorg/myrepo/contents/path/to/file.yml",
  "name": "path/to/file.yml",
  "version": "aec855f4e0e11"
}

Docs: GitLab File

Mon, 01 Jan 0001 00:00:00 +0000

These artifacts are generally consumed by stages that read configuration from text files, such as a Deploy Manifest stage.

GitLab file artifact in the UI

The pipeline UI exposes the following fields for the GitLab file artifact:

Field	Explanation
Account	A GitLab artifact account.
File path	The path to the artifact file, beginning at the root of the Git repository.
Commit/Branch	The commit hash or branch name to use when retrieving the artifact file from GitLab.

In a trigger

When configuring a Git trigger with Type “GitLab”, you can use a GitLab file as an expected artifact.

Configuring GitLab file fields in a pipeline trigger’s expected artifact settings.

In a pipeline stage

When configuring certain stages, such as a “Deploy (Manifest)” or “Deploy” stage, you can use a GitLab file as a manifest or application artifact. You can either use a previously-defined artifact (for example, an artifact defined in a trigger) or define an artifact inline.

GitLab file artifact in a pipeline definition

The following are the fields that make up a GitLab file artifact:

Field	Explanation
`type`	Always `gitlab/file`.
`reference`	The full path (including filename) for retrieval via the GitLab API. Example: `https://gitlab.example.com/api/v4/projects/13083/repository/files/manifests%2Fconfig%2Eyaml/raw`. For more information, see the GitLab API documentation .
`name`	The path to the artifact file, beginning at the root of the Git repository. Example: `path/to/file.yml`.
`version`	The commit hash or branch name to use when retrieving the artifact file from GitLab.
`location`	N/A

The following is an example JSON representation of a GitLab file artifact, as it would appear in a pipeline definition:

{
  "type": "gitlab/file",
  "reference": "https://gitlab.example.com/api/v4/projects/13083/repository/files/manifests%2Fconfig%2Eyaml/raw",
  "name": "manifests/config.yaml",
  "version": "master"
}

Docs: HTTP File

Mon, 01 Jan 0001 00:00:00 +0000

These artifacts are generally consumed by stages that read configuration from text files, such as a Deploy Manifest stage.

A file represented by an HTTP file artifact can be downloaded using HTTP Basic authentication.

HTTP file artifact in the UI

The pipeline UI exposes the following fields for the HTTP file artifact:

Field	Explanation
Account	An HTTP artifact account.
URL	The fully-qualified URL from which the file can be read.

In a trigger

When configuring certain triggers, you can use an HTTP file as an expected artifact.

Configuring HTTP file fields in a pipeline trigger’s expected artifact settings.

In a pipeline stage

When configuring a “Deploy (Manifest)” or “Deploy” stage, you can use an HTTP file as a manifest or application artifact. You can either use a previously-defined artifact (for example, an artifact defined in a trigger) or define an artifact inline.

Configuring a Deploy (Manifest) stage to use an HTTP file as a manifest source.

HTTP file artifact in a pipeline definition

The following are the fields that make up an HTTP file artifact:

Field	Explanation
`type`	Always `http/file`.
`reference`	The fully-qualified URL from which the file can be read.
`name`	An optional identifier used for future references to the artifact.
`version`	N/A
`location`	N/A

The following is an example JSON representation of an HTTP file artifact, as it would appear in a pipeline definition:

{
  "type": "http/file",
  "reference": "https://raw.githubusercontent.com/....",
  "name": "My manifest stored in GitHub",
}

Docs: Kubernetes Object

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes object artifact in the UI

The pipeline UI exposes the following fields for the Kubernetes object artifact:

Field	Explanation
Account	An HTTP artifact account.
URL	The fully-qualified URL from which the file can be read.

Kubernetes object artifact in a pipeline definition

The following are the fields that make up a Kubernetes object artifact:

Field	Explanation
`type`	`kubernetes/<kind>`, where `<kind>` is the Kubernetes Kind (such as `Deployment`).
`reference`	The name of the object.
`name`	The name of the object.
`version`	The version of the object. Only set if the resource was deployed with a version (for example, a `ConfigMap` deployed at version `-v120`).
`location`	The namespace of the object.
`artifactAccount`	The Spinnaker account (Kubernetes context) to which the object was deployed.

The following is an example JSON representation of a Kubernetes object artifact, as it would appear in a pipeline definition:

{
  "type": "kubernetes/deployment",
  "reference": "frontend",
  "name": "frontend",
  "namespace": "staging",
  "artifactAccount": "gke-us-central1-xnat"
}

Docs: Maven Artifact

Mon, 01 Jan 0001 00:00:00 +0000

These artifacts are generally consumed by stages that deploy application artifacts, such as a Deploy stage.

The files stored in a Maven repository are typically called “artifacts”, so on this page, “Maven artifact” may refer to a Spinnaker artifact of type maven/file or to a file (e.g. a JAR file) stored in a Maven repository.

Maven artifact in the UI

The pipeline UI exposes the following fields for the Maven artifact:

Field	Explanation
Account	A Maven artifact account.
Maven Coordinate	The Maven coordinates for the artifact (in the standard Maven form `groupId:artifactId:version`).

In a trigger

When configuring certain triggers (such as an Artifactory trigger), you can use a Maven artifact as an expected artifact.

Configuring Maven artifact fields in a pipeline trigger’s expected artifact settings.

In a pipeline stage

When configuring a Deploy stage, you can use a Maven artifact as an application artifact. You can either use a previously-defined artifact (for example, an artifact defined in a trigger) or define an artifact inline.

Configuring a Deploy stage to use a Maven artifact as an application artifact.

Maven artifact in a pipeline definition

The following are the fields that make up a Maven artifact:

Field	Explanation
`type`	Always `maven/file`.
`reference`	The Maven coordinates for the Maven artifact, in the standard Maven form `groupId:artifactId:version`.

The following is an example JSON representation of a Maven artifact, as it would appear in a pipeline definition:

{
	"reference": "io.pivotal.spinnaker:multifoundationmetrics:.*",
	"type": "maven/file"
}

Docs: Oracle Object

Mon, 01 Jan 0001 00:00:00 +0000

These artifacts are generally consumed by stages that read configuration from text files, such as a Deploy Manifest stage.

Oracle object artifact in a pipeline definition

The following are the fields that make up an Oracle object artifact:

Field	Explanation
`type`	Always `oracle/object`.
`reference`	The full path to the artifact file, beginning with`oci://`.

The following is an example JSON representation of an Oracle object artifact, as it would appear in a pipeline definition:

{
  "type": "oracle/object",
  "reference": "oci://bucket/file.json"
}

Docs: S3 Object

Mon, 01 Jan 0001 00:00:00 +0000

These artifacts are generally consumed by stages that read configuration from text files, such as a Deploy Manifest or AWS Deploy stage.

S3 object artifact in the UI

The pipeline UI exposes the following fields for the S3 object artifact:

Field	Explanation
Account	An S3 artifact account.
Object path	The full path to the artifact file, beginning with `s3://`.

In a trigger

When configuring a trigger, you can use an S3 object as an expected artifact.

Configuring S3 object fields in a pipeline trigger’s expected artifact settings.

In a pipeline stage

When configuring a “Deploy (Manifest)” or “Deploy” stage, you can use an S3 object as a manifest or application artifact. You can either use a previously-defined artifact (for example, an artifact defined in a trigger) or define an artifact inline.

Configuring a Deploy (Manifest) stage to use an S3 object as a manifest source.

S3 object artifact in a pipeline definition

The following are the fields that make up an S3 object artifact:

Field	Explanation
`type`	Always `s3/object`.
`name`	The full path to the artifact file, beginning with `s3://`.
`reference`	The full path to the artifact file, beginning with `s3://`.
`location`	The region of the bucket containing the object.

The following is an example JSON representation of an S3 object artifact, as it would appear in a pipeline definition:

{
  "type": "s3/object",
  "name": "s3://bucket/file.json",
  "reference": "s3://bucket/file.json",
  "location": "us-east-1"
}