Architecture of Pipelines-as-Code for Spinnaker and Armory Continuous Deployment
The Pipelines-as-Code feature has the following components:
- Keeps your repo pipeline definitions in sync with the corresponding pipelines in Spinnaker
- Communicates with repos over SSL or TLS
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
sequenceDiagram 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
- Your repo sends webhooks when you modify either the Templates or the Module definitions.
- The Pipelines-as-Code service looks for and fetches all dependent modules and parses the template. Then the service updates the pipelines in Spinnaker.
- 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
dinghyfilein 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
dinghyfilein order to pull new updates from modules it is using.
- 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.
Was this page helpful?
Thank you for letting us know!
Sorry to hear that. Please tell us how we can improve.
Last modified May 26, 2023: (a7d5a9eb)