Enable Pipelines-as-Code in Armory Continuous Deployment

Learn how to enable Armory CD’s Pipelines-as-Code feature.

Before you begin

  • You are running Armory Continuous Deployment.
  • You manage your instance using the Armory Operator.

Pipelines-as-Code is a built-in feature of Armory CD. You only need to configure your repo, enable the Dinghy service, and apply your changes to use Pipelines-as-Code.

If you are running open source Spinnaker, see the Pipelines-as-Code landing page for installation paths based on whether you are using Halyard or the Spinnaker Operator.

Where to configure the service

  • If you are using the spinnaker-kustomize-patches repo, put your config in the armory/features/pipelines-as-code/features.yml file.

  • If you are using a single spinnakerservice.yml manifest, put your config in the spec.spinnakerConfig.config.armory.dinghy section.

    apiVersion: spinnaker.armory.io/v1alpha2
kind: SpinnakerService
metadata:
  name: spinnaker
spec:
  spinnakerConfig:
    config:
      armory:
        dinghy:

Enable Pipelines-as-Code

The Dinghy service is already enabled in the armory/features/pipelines-as-code/features.yml file, so you only need to modify your Kustomization recipe. Add an entry for Pipelines-as-Code in the components section of your kustomization.yml file:

components:
  - core/base
  - core/persistence/in-cluster
  - targets/kubernetes/default
  - armory/features/pipelines-as-code/

Add enabled: true to your dinghy section.

spec:
  spinnakerConfig:
    config:
      armory:
        dinghy:
          enabled: true

Configure your repo

Before configuring your repos, ensure you have the following:

  1. A personal access token that has read access to the repo where you store your dinghyfile and the repo where you store module files. You should create a Kubernetes Secret for your personal access token so you don’t store the token in plain text in your config file.
  2. The organization where the app repos and templates reside; for example, if your repo is armory-io/dinghy-templates, your template-org is armory-io.
  3. The name of the repo containing your modules; for example, if your repo is armory-io/dinghy-templates, your template-repo is dinghy-templates.

Add the following to your config file:

spec:
  spinnakerConfig:
    config:
      armory:
        dinghy:
          enabled: true 
          templateOrg: <repo-org>
          templateRepo: <dinghy-templates-repo>
          githubToken: <abc>
          githubEndpoint: <https://api.github.com>

All fields are required.

  • templateOrg: VCS organization or namespace where application and template repositories are located
  • templateRepo: VCS repository where module templates are located
  • githubToken: GitHub token; This field supports “encrypted” field references; see Secrets for details.
  • githubEndpoint: (Default: https://api.github.com) GitHub API endpoint. Useful if you’re using GitHub Enterprise.

GitHub webhooks

Set up webhooks at the organization level for push events. You can do this by going to https://github.com/organizations/<your_org_here>/settings/hooks.

  1. Set content-type to application/json.

  2. Set the Payload URL to your Gate URL. Depending on whether you configured Gate to use its own DNS name or a path on the same DNS name as Deck, the URL follows one of the following formats:

    • https://<your-gate-url>/webhooks/git/github if you have a separate DNS name or port for Gate
    • https://<your-spinnaker-url>/api/v1/webhooks/git/github if you’re using a different path for Gate

If your Gate endpoint is protected by a firewall, you need to configure your firewall to allow inbound webhooks from GitHub’s IP addresses. You can find the IPs in this API response. Read more about GitHub’s IP addresses.

You can configure webhooks on multiple GitHub organizations or repositories to send events to Dinghy. Only a single repository from one organization can be the shared template repository in Dinghy. However, Dinghy can process pipelines from multiple GitHub organizations. You want to ensure the GitHub token configured for Dinghy has permission for all the organizations involved.

Pull request validations

When you make a GitHub pull request (PR) and there is a change in a dinghyfile, Pipelines-as-Code automatically performs a validation for that dinghyfile. It also updates the GitHub status accordingly. If the validation fails, you see an unsuccessful dinghy check.

PR that fails validation.

Make PR validations mandatory to ensure users only merge working dinghyfiles.

Perform the following steps to configure mandatory PR validation:

  1. Go to your GitHub repository.
  2. Click on Settings > Branches.
  3. In Branch protection rules, select Add rule.
  4. Add master in Branch name pattern so that the rule gets enforced on the master branch. Note that if this is a new repository with no commits, the “dinghy” option does not appear. You must first create a dinghyfile in any branch.
  5. Select Require status checks to pass before merging and make dinghy required. Select Include administrators as well so that all PRs get validated, regardless of user.

The following screenshot shows what your GitHub settings should resemble:

Configured dinghy PR validation.

Bitbucket has both cloud and server offerings. See the Atlassian docs for more on the name change from Stash to Bitbucket Server. Consult your company’s Bitbucket support desk if you need help determining what flavor and version of Bitbucket you are using.

Add the following to your config file:

spec:
  spinnakerConfig:
    config:
      armory:
        dinghy:
          enabled: true
          templateOrg: <repo-org>
          templateRepo: <dinghy-templates-repo>
          stashUsername: <stash_user>
          stashToken: <abc>
          stashEndpoint: <https://my-endpoint>

All fields are required.

  • templateRepo: VCS repository where module templates are located
  • stashUsername: Stash username
  • stashToken: Stash token. This field supports “encrypted” field references; see Secrets for details.
  • stashEndpoint: Stash API endpoint. If you’re using Bitbucket Server, update the endpoint to include the api e.g. https://your-endpoint-here.com/rest/api/1.0

If you’re using Bitbucket Server, update the endpoint to include the api, e.g. --stash-endpoint https://your-endpoint-here.com/rest/api/1.0

You need to set up webhooks for each project that has the dinghyfile or module separately. Make the webhook POST to: https://spinnaker.your-company.com:8084/webhooks/git/bitbucket. If you’re using Stash <v3.11.6, you need to install the webhook plugin to be able to set up webhooks.

Add the following to your config file:

spec:
  spinnakerConfig:
    config:
      armory:
        dinghy:
          enabled: true 
          templateOrg: <repo-org>
          templateRepo: <dinghy-templates-repo>
          gitlabToken: <abc>
          gitlabEndpoint: <https://my-endpoint>

All fields are required.

  • templateOrg: VCS organization or namespace where application and template repositories are located
  • templateRepo: VCS repository where module templates are located
  • gitlabToken: GitLab token. This field supports “encrypted” field references; see Secrets for details.
  • gitlabEndpoint: GitLab endpoint

Under Settings -> Integrations on your project page, point your webhooks to https://<your-gate-url>/webhooks/git/gitlab. Make sure the server your GitLab install is running on can connect to your Gate URL. Armory also needs to communicate with your GitLab installation. Ensure that connectivity works as well.

Deploy

Apply your updates.

kubectl apply -k <kustomization-directory-path>

kubectl -n spinnaker apply -f spinnakerservice.yml

What’s next


Last modified May 26, 2023: (a7d5a9eb)