Spinnaker 1.13 – What’s New

Spinnaker 1.13 release was released on March 25th,2019 and it brings a lot of exciting updates including the following.

• Improved streamlined experience for building, baking, and deploying of your applications to Azure on Spinnaker
  • The older over of Azure provider has been updated. Current latest(1.13) updates provide a significantly improved experience that streamlines the building, baking, and deploying of your applications to Azure on Spinnaker. You can now create a continuous-delivery pipeline to deploy your custom application via Azure VM Scale Sets. More details about the actual capabilities can be found below. This is an initial version, and as we continue to invest, we encourage your feedback, via Spinnaker GitHub issues, Slack channels, the community forum, and so on.
  • Server Groups (Virtual Machine Scale Sets) now support consuming managed images, VM size choice selection, availability zones, tagging, and the option of using ssh public key or password to provision Linux VM. There is also support for Network Security Groups being applied to a subnet within a virtual network, and source IP/CIDR filtering has been added. Lastly, the Azure Java SDK has been upgraded to 1.19.0.
  • More information about Azure Spinnaker Support, Check out Microsoft blog.
• Integration with Jenkins pipeline in Spinnaker Artifact support in Spinnaker from Jenkins file
  • Spinnaker always had first-class support for Jenkins as continuous integration (CI) phase of the continuous deployment (CD) pipeline. Jenkins pipeline or Jenkins job can be triggered from Spinnaker as a pipeline stage of Spinnaker. This is a common use case where the source control changes trigger the pipeline and Jenkins job is run for build part of the pipeline. Now the question is how does the output of the Jenkins pipeline get passed on to the Spinnaker to be used in subsequent stages in the pipeline? For example, the output of the build process could be the location of the jar file built or Debian package or a Docker file which needs to be used in subsequent stages of the pipeline to install on target or to update manifest file with the container reference.
  • Until recently, the output of Jenkins is to create a properties file <url reference>, set it as an archive file in Jenkins and access it from Spinnaker context after the Jenkins stage completes. This allows only name-value pairs to be passed and hence if the artifact built by Jenkins job is a docker file then the docker reference is treated as a variable and not as an artifact reference. This is important because in deploy manifest stage of Spinnaker, one can only bind artifacts to the template and hence bind feature could not be used on the Jenkins output of the pipeline.
  • The newest release of Spinnaker addresses this problem and allows Jenkins job output as an artifact which can be bound to the manifest file in deploy manifest stage of the Spinnaker. This requires the Igor configuration to enable template format <reference url> and generate output from the job in the format specified in the template. Additionally, enable the feature flag for artifact template in thee Igor-local yml file. You still need to enable archive in the Jenkins job for the output file. Now, after the Jenkins job is run, the artifact is available to you to bind in the deploy manifest stage

• Custom Banner for Applications
  • With Custom Banner for Application, a user can now add application-specific customized banners to Deck from the Config Tab. For example – user will be able to make customized Header Customization, Cloud provider override, Custom Data Source, Custom Help Contents, Home Page and Custom Exception Handler.
• Artifacts included when re-running pipelines
  • This feature is mainly used when re-running a pipeline that had received artifacts on the first execution, all the artifacts will now be included during the re-run. With this, user will have the advantage to prevent “Unmatched expected artifact” errors when re-running pipelines.
• Artifacts produced by CI Stages (Jenkins, Travis) now available for downstream stages
  • This feature was initially introduced in Spinnaker 1.11, it has been possible to use a Jinja template to inject artifacts into a pipeline triggered by a CI build. This functionality is now also available in CI stages (ex: Jenkins Stage, Travis Stage), with produced artifacts available to downstream stages.
  • Users who have defined custom templates via the artifacts.templates field in echo’s configuration should move these custom templates (unchanged) to igor’s configuration. Users who have configured custom templates via Halyard should upgrade to at least Halyard 1.17 but otherwise do not need to take any action.

For detail and a complete list of the updates, check out the 1.13 changelog