Spinnaker 1.20 – What’s New

The updated Spinnaker version-Spinnaker 1.20, was released on 04th May 2020. This release brings fixes, features, and performance improvements across a comprehensive feature set in Spinnaker. Here we share the summary of essential improvements

Prerequisites:

• This release requires Halyard Version 1.32.0 or later.

List of Fixes and New Features:

Kubernetes V1 Provider:

• Now, its time to migrate all your data from V1 to standard Kubernetes accounts V2 providers as this release will the last to support for the legacy Kubernetes Provider (V1). Check out this RFC and Blog for more details.

Docker Registry Changes:

The Docker containers of Spinnaker are now hosted on us-docker.pkg.dev/spinnaker-community. Until now, they on gcr.io/spinnaker-marketplace.

ECS Fixes:

• From this release, the user will be able to view the Load Balancers, listeners, and target groups associated with their ECS services within the Load Balancers Infrastructure tab.
• Also, pipeline deployments now take into account container health checks and the overall task health status before determining a service to be up. If using a prior version, pipeline deployments would consider the service healthy once the tasks were started, but potentially before the container health checks were running. This could lead to prematurely marking a deployment as successful.

Kubernetes V2 Run Job Stage:

• From this version onwards, Spinnaker no longer automatically adds a unique suffix to the name of jobs. Before this release, the Kubernetes V2 Run Job stage added a unique suffix to the name of the deployed job, with no ability to control or configure this behavior.
• To continue having a random suffix added to the job name, set the metadata.generateName field instead of metadata.name, which causes the Kubernetes API to append a random suffix to the name.
• If a job sets metadata.name directly, that name will be used without modification for each execution of the job. As jobs are immutable, each execution of the stage will delete any existing job with the supplied name before creating the job.

UI Enabled by Default for Standard Artifacts:

• For the first time UI is available by default for artifacts. Until now, the legacy and standard (“rewrite”) artifacts UIs were hidden behind the artifacts and artifactsRewrite feature flags. These flags are no longer supported in 1.20, and the standard artifacts UI is enabled by default.
• The most noticeable difference for users previously using the legacy artifacts UI will be the absence of a separate Expected Artifacts section when configuring a pipeline. Expected artifacts are now defined inline against Triggers in the Artifacts Constraints section or inline in stages. For the 1.20 release only, a temporary legacyArtifactsEnabled flag is available to. Add this flag to your settings-local.js to revert to the legacy UI. See this RFC for more details.

Customize by default

Hiding Arbitary Stages from Users:

• All the stages that are not provider-specific will be exposed by default. Operators can now choose to hide any stages from end-users using Deck’s hiddenStages setting.

For more details and a complete list of the updates, check out the 1.20 changelog.