Spinnaker Running a Script with Run Job (Manifest)

External

• https://kb.armory.io/s/article/Run-a-Generic-Shell-Script-with-Spinnaker
• https://spinnaker.io/docs/guides/user/kubernetes-v2/run-job-manifest/
• https://blog.spinnaker.io/extending-spinnaker-with-kubernetes-and-containers-5d16ec810d81

Internal

• Spinnaker Concepts
• Run Job (Manifest)

Overview

The execution phase is implemented as a Run Job (Manifest) stage.

⚠️ Make sure you use Run Job (Manifest) and NOT Deploy (Manifest)!

Run Job (Manifest) only accepts Job manifests, so a ConfigMap to specify the script cannot be used. The functionality must be already present in the container image and can be controlled via command and arguments. The stage will deploy the job manifest and wait until it completes, thus gating the pipeline’s continuation on the job’s success or failure. The stage may optionally collect the Job output and inject it back into the pipeline. The Job will be automatically deleted upon completion.

An alternative to run configurable functionality is to use Running a Script with Deploy (Manifest), but in that case we lose the ability to inject output back into the pipeline.

Run Job (Manifest) Definition

Add a "Run Job (Manifest)" stage and name it "Script Job" or similar.

The Account is the target Kubernetes cluster.

In Manifest Configuration. set Manifest Source: Text, and use the following manifest. Replace 'REPLACE-WITH-TARGET-NAMESPACE-NAME' with the target namespace for the Job.

Note that the Job name will be available in kubectl -n <namespace> get job and it will also surface in pod names, so choose something meaningful.

apiVersion: batch/v1
kind: Job
metadata:
  name: script-job
  namespace: REPLACE-WITH-TARGET-NAMESPACE-NAME
spec:
  backoffLimit: 2
  template:
    spec:
      containers:
        - command:
            - kubectl
            - version
          image: 'bitnami/kubectl:1.12'
          name: script
      restartPolicy: Never

Viewing Execution Logs

https://spinnaker.io/docs/guides/user/kubernetes-v2/run-job-manifest/#viewing-execution-logs

The job execution log is captured and can be accessed in the pipeline Execution Details → Run Job Config → Logs → Console Output.

If the Spinnaker instance is configured as such, logs can be forwarded to dedicated infrastructure.

Also see:

Operations | Log Management

Generating and Using Execution Results

https://spinnaker.io/docs/guides/user/kubernetes-v2/run-job-manifest/#capturing-output

A job produces some output, and the Spinnaker "Run Job (Manifest)" stage can be configured to "capture it". Captured output will be available in the pipeline context for use in downstream stages. There are several ways to "capture output": from a job's container stdout or from an artifact produced by the job.

Capture Output from Container Stdout and Update Stage Outputs and Context

Output → Capture Output From → Logs. A Container Name must be specified.

SPINNAKER_PROPERTY_*=*

If the job sends to stdout SPINNAKER_PROPERTY_<key>=<value>, then <key>:<value>, where <key> is converted to lowercase, shows up in the stage output map .stages[stage_index].outputs, and also in the map .stages[stage_index].outputs.propertyFileContents. It also shows in the stage context map .stages[stage_index].context, and also in the map .stages[stage_index].context. propertyFileContents .

So, if the designated Job container sends this to stdout:

SPINNAKER_PROPERTY_COLOR=Blue

when the stage completes, it carries this in its JSON representation:

{
  "type": "PIPELINE",
  "stages": [
    {
      "type": "runJobManifest",
      "context": {
        "color": "Blue",
        "propertyFileContents": {
          "color": "Blue"
        }
      },
      "outputs": {
        "color": "Blue",
        "propertyFileContents": {
          "color": "Blue"
        }
      }
    }
  ]
}