Architecture of Pipelines-as-Code for Spinnaker and Armory Continuous Deployment

Learn about the key components that comprise Pipelines-as-Code


The Pipelines-as-Code feature has the following components:

  1. Dinghy Service:

    • Keeps your repo pipeline definitions in sync with the corresponding pipelines in Spinnaker
    • Communicates with repos over SSL or TLS
  2. Spinnaker Plugin: extends Gate and Echo by adding endpoints that the Dinghy service uses


Dinghy works out-of-the-box with in-cluster Redis. You can configure Pipelines-as-Code to use an external Redis or a MySQL database.

How Pipelines-as-Code works

    actor User
    participant Repo
    participant Dinghy Service
    participant Spinnaker Plugin    

    User->>Repo: update pipeline template
    Repo->>Dinghy Service: send notification
    Dinghy Service->>Repo: fetch updated .dinghyfile
    Dinghy Service->>Spinnaker Plugin: update pipeline

  1. Your repo sends webhooks when you modify either the Templates or the Module definitions.
  2. The Pipelines-as-Code service looks for and fetches all dependent modules and parses the template. Then the service updates the pipelines in Spinnaker.
  3. The pipelines are automatically updated whenever a module that is used by a pipeline is updated in the version control system. This is done by maintaining a dependency graph. The Pipelines-as-Code service looks for a dinghyfile in all directories, not just the root path. The only exception is when you have modules in a local setting. In this case, you must update the dinghyfile in order to pull new updates from modules it is using.
  4. Dinghy processes changes found in a specific branch. By default, this branch is master. If you are using a repo that uses a different branch for the base branch, an administrator must configure the service to track that branch. For more information, see Custom branches.

Last modified May 26, 2023: (a7d5a9eb)