Note: this is a first pass at this documentation; more details will be added soon.
This article describes the currently-supported stages that you can add to your Spinnaker pipelines.
Note that when you’re creating a pipeline, you probably won’t see every stage that’s listed here: you’ll only see the stages that Spinnaker supports on your provider.
Bake an image from the specified packages. Baking here refers to the process of creating a machine image. Spinnaker’s bakery is backed by Hashicorp’s Packer. Spinnaker provides default Packer templates and base machine images in order to get you started, but see the bakery configuration guide if you want to customize your bake process.
Note that Spinnaker skips the bake process if it detects that a new bake is unnecessary. Spinnaker generates a unique key for each bake based on the bake stage parameters: base OS, versioned packages, etc. If either the packages or the bake stage parameters have changed, Spinnaker triggers a new bake. To change the default behavior and re-bake your image each time the pipeline runs, select Rebake in the Bake Configuration section.
Use Kayenta to run automated canary analysis against the deployment before fully deploying. Note that this stage only handles analysis; you’re responsible for provisioning and cleaning up your canary instances. This is typically done within the same pipeline via stages surrounding the Canary Analysis stage.
For a step-by-step explanation of how to set up a Canary Analysis stage see the how-to guide.
Check for preconditions before continuing. For example, you can check that your cluster is a particular size, or add a pipeline expression. See the pipeline expressions guide for more information about creating and using pipeline expressions.
Clone Server Group
Copies all attributes of the original Server Group into a new Server Group (the image that was deployed to it, its capacity, etc). You can choose to override any of the properties of the original Server Group when creating the new one.
Deploy the previously baked or found image using the specified deployment strategy. Spinnaker provides built-in support for both red/black (also known as blue/green) and Highlander deployment strategies. You can also choose to deploy with no impact on existing Server Groups, or build your own custom deployment strategy.
Destroy Server Group
Delete a Server Group and its resources from the specified Cluster. You must specify whether you want to delete the newest, oldest, or previous (second-most-recently deployed) Server Group when this stage starts.
Disable the specified Cluster, which means that the cluster remains up but stops handling traffic. If desired, you can leave a specific number of Server Groups running while the rest of the cluster is disabled.
Disable Server Group
The specified Server Group remains up but stops handling any traffic. Any auto-scaling policies related to this Server Group will also be disabled. Disabling Server Groups makes it easy to both route traffic to a new Server Group and roll back those changes if necessary. You must choose whether to disable the Server Group which is newest, oldest, or previous (second-most-recently deployed) when this stage starts.
Enable Server Group
Tell Spinnaker to resume sending traffic to the Server Group. The configuration of your Load Balancer determines how traffic is routed among newly-enabled Server Groups and any existing Server Groups. Enabling a Server Group also re-enables auto-scaling policies, if applicable.
Find Artifact From Execution
Find and bind an artifact from a different pipeline execution to the current one, including artifacts from different Spinnaker applications. To do this, specify the type of artifact (GCS, GitLab, Docker, etc) and its name. You can specify that Spinnaker should only consider executions that meet certain criteria, such as ones that have completed successfully or that are currently running. Spinnaker will always return the artifact from the most recent execution that matches your criteria.
Find Image From Cluster
Find an image to deploy from an existing Cluster. Make sure that you specify the Cluster and Server Group such that there is exactly one match, or this may behave in unexpected ways.
Find Image From Tags
Find the newest image that matches all specified tags. The image tag can come from any source. Regardless of whether you tagged your image through the Spinnaker Tag Image stage or through a process outside of Spinnaker, the Find Image From Tags stage can find it as long as Spinnaker has previously interacted with the image.
In Spinnaker, tags can only contain lowercase letters, numeric characters, underscores and dashes. Depending on your provider, you may need to specify what region to search for the image.
Run the specified job in Jenkins. You must set up Jenkins in order to use this stage. Once Jenkins is configured, your Jenkins master and available jobs are automatically populated in the respective drop-down menus.
Wait for the user to click Continue before continuing. You can specify instructions for how to decide whether to continue, or add input options that users can choose from. These input options can be used to determine pipeline behavior in downstream stages. For example, you can use the Check Preconditions stage to ensure that a given stage only runs if a particular input is specified.
Select any pipeline and run it as a sub-pipeline. You can run pipelines from both the current application and any other Spinnaker applications that you have access to. You can choose whether to wait for the results of the sub-pipeline before this stage completes. If you wait for results, the end state of this stage reflects the end state of the sub-pipeline. Otherwise, the this stage is marked successful as soon as the sub-pipeline starts.
Resize Server Group
Resize the oldest, newest, or second newest Server Group. You can resize the Server Group by either a percentage of its current size or a specific amount. The available resizing strategies are:
- Scale Up, which increases the size of the target Server Group.
- Scale Down, which decreases the size of the target Server Group.
- Scale to Cluster Size, which increases the size of the target Server Group to match the largest Server Group in the Cluster. Optionally, you can specify additional capacity to add as well.
- Scale to Exact Size, which adjusts the size of the target Server Group to match the specified capacity.
Roll back one or more regions in a Cluster.
Run a container.
Scale Down Cluster
Scale down a cluster. You can prevent this stage from scaling down active Server Groups, or choose to keep a certain number of Server Groups at their current size while the rest are scaled down.
Execute an arbitrary script as part of your pipeline. Spinnaker uses Jenkins to sandbox your scripts, so you need to set up Jenkins in order to use it. If you already have Jenkins set up, make sure that you have configured it to run scripts.
The only required field in this stage is Command, where you must specify the command to run the script. Otherwise, you can use any of the fields that are relevant to your use case in order to describe the script location and specifics about its output, environment, and so on.
Shrink a given cluster to contain nothing except a specified number of either the newest or the largest Server Groups. You can choose whether to delete active Server Groups if they don’t fit the specified criteria.
Tag the current image in your pipeline with all specified tags. Tags can only contain lowercase letters, numeric characters, underscores and dashes. Spinnaker converts the tags to your provider’s equivalent: for example, it creates labels for GCE images, whereas it creates tags for AWS images, and so on.
Wait a specified period of time before proceeding. You can choose to manually skip some or all of the wait period during execution.
Make an API call to an external system as part of your pipeline.
Supply the URL to send the request to and the desired HTTP method, as well as optionally any desired custom headers and a JSON payload to add to the request. At this point, this stage is marked successful as if it receives a 2XX or 3XX response, fails on a 4XX, or retries on 5XX. The webhook URL, payload, status endpoint, and final status are all shown under the pipeline execution details in the Spinnaker UI.
Note that you can use pipeline expressions
in both the URL field and the payload. When the stage completes, the
field of the stage context contains the payload, which allows you to use it in
future pipeline expressions. For example, you can reference the final status
code with the expression
If you need more details to determine the success of your request, check the Wait for completion checkbox. Spinnaker then polls a status URL to determine the progress of the stage. You can supply the status URL to Spinnaker in one of the following ways:
- GET method against webhook URL: Spinnaker polls the webhook URL using GET to determine the status.
- From the Location header: Spinnaker parses the Location header of the webhook’s response call to find the status URL, and polls that URL.
- From webhook’s response: Spinnaker parses the response from the original request, and polls the returned URL.
In all cases, you then need to provide details about how to access and interpret the status:
- Status JsonPath is a required field which you use to specify the path to
the status information in the response JSON of the status URL, such as
- SUCCESS, CANCELED, and TERMINAL status mappings are comma-separated lists of strings that represent successful, canceled, or terminal (failed) statuses, respectively. These are required fields: Spinnaker continues polling until it sees one of the specified statuses in the status URL’s response.
- Progress location is optional, and lets you specify the path to detailed
progress information in the status URL’s response JSON, such as
buildInfo.progress. It shows up in the Info field of the pipeline execution details.
If you find yourself recreating the same webhook stage repeatedly, you can create a custom webhook stage. A custom webhook stage is a webhook stage specifically named and configured for your application’s needs, which shows up in the standard pipeline stages dropdown menu.
Run the specified Wercker pipeline. You must set up Wercker in order to use this stage. Once Wercker has been configured, your Wercker masters and the applications and pipelines available for your master’s credentials will be shown in the drop-down menus. When a Wercker pipeline stage runs, a link to the Wercker run will be available, and the status of the Wercker run will be reported in Spinnaker.
Start AppEngine Server Group
Start a Server Group.
Stop AppEngine Server Group
Stop a Server Group.
Upsert AppEngine Load Balancers
Edit a Load Balancer.
Modify AWS Scaling Process
Suspend/resume scaling processes.
Bake a manifest (or multi-doc manifest set) using a template renderer such as Helm.
Destroy a Kubernetes object created from a manifest. If multiple label selectors are specified, they are combined with the logical AND operator. See the Kubernetes reference page for more details.
Deploy a Kubernetes manifest YAML/JSON file.
Find Artifacts From Resource
Find artifacts from a Kubernetes resource.
Update an already existing Kubernetes resource in place using the Kubernetes patch operation. Spinnaker can update the resource without knowing the entire resource (that is, you have to specify only the portion of the manifest you want to update).
The patch stage can be used to add a label or update a sidecar container image for a set of resources. It can also be used to implement a rainbow deployment strategy for Kubernetes by first deploying a new ReplicaSet and then patching the fronting service’s selectors to point to the new ReplicaSet.
Spinnaker also supports artifact substitution for the patch content just like the resource manifest in the deploy stage.
Scale a Kubernetes object created from a manifest.
Undo Rollout (Manifest)
Rollback a manifest a target number of revisions.