Configure Pipelines-as-Code Optional Features

Where to configure the Dinghy service

• Spinnaker (Halyard): dinghy.yml section of your ConfigMap
• Spinnaker (Spinnaker Operator): spinnaker-kustomize-patches/plugins/oss/pipelines-as-code/dinghy.yml
• Armory CD: Either spinnaker-kustomize-patches/armory/features/pipelines-as-code/features.yml or spinnakerservice.yml

Auto lock pipelines - disable

Set autoLockPipelines: false to disable lock pipelines in the UI before overwriting changes.

• Spinnaker
• Armory CD

autoLockPipelines: false

spec:
  spinnakerConfig:
    config:
      armory:
        dinghy:
          autoLockPipelines: false

Branches

Custom branches

Configuring a custom branch is required if you are using a repo that does not use master or main as the default branch, or you want to use a branch other than master or main.

By default, Dinghy uses the master branch in your repository and fallbacks to main if master doesn’t exist. If you wish to use a different branch in your repository, you can configure that using the repoConfig tag in your YAML configuration.

The repoConfig tag supports a collection of the following values:

• branch - the name of the branch you wish to use

• provider - the name of the provider. Pipelines-as-Code supports the following:

  • github
  • bitbucket-cloud
  • bitbucket-server

• repo - the name of the repository

• Spinnaker
• Armory CD

repoConfig:
- branch: some_branch
  provider: bitbucket-server
  repo: my-bitbucket-repository
- branch: some_branch
  provider: github
  repo: my-github-repository

spec:
  spinnakerConfig:
    profiles:
      dinghy:
        repoConfig:
        - branch: some_branch
          provider: bitbucket-server
          repo: my-bitbucket-repository
        - branch: some_branch
          provider: github
          repo: my-github-repository

Multiple branches

• Spinnaker
• Armory CD

multipleBranchesEnabled: true
repoConfig:
- branch: branch_a
  provider: github
  repo: my-github-repository
- branch: branch_b
  provider: github
  repo: my-github-repository
- branch: some_branch
  provider: bitbucket-server
  repo: my-bitbucket-repository

spec:
  spinnakerConfig:
    config:
      armory:
        dinghy:
          multipleBranchesEnabled: true
    profiles:
      dinghy:
        repoConfig:
        - branch: some_branch
          provider: bitbucket-server
          repo: my-bitbucket-repository
        - branch: some_branch
          provider: github
          repo: my-github-repository

Custom dinghyfile name

This changes the name of the file that describes pipelines.

• Spinnaker
• Armory CD

dinghyFilename: <your-filename>

spec:
  spinnakerConfig:
    config:
      armory:
        dinghy:
          dinghyFilename: <your-filename>

External persistent database

The Pipelines-as-Code service uses an in-cluster Redis instance to store relationships between pipeline templates and pipeline config files (.dinghyfile). You can, however, configure the service to use an external persistent database.

Configure Redis

Armory highly recommends that you use an external Redis instance for production use. If Redis becomes unavailable, you need to update your pipeline config files in order for the service to repopulate Redis with the relationships.

You can only configure Dinghy to use a password with the default Redis user.

• Spinnaker
• Armory CD

redis:
  baseUrl: "redis://spin-redis:6379"
  password: "password"

spec:
  spinnakerConfig:
    profiles:
      dinghy:
        redis: "redis://spin-redis:6379"
        password: "<password>"

Configure MySQL

The Pipelines-as-Code service can use MySQL to store relationships between pipeline templates and pipeline Dinghy files. Armory recommends an external MySQL instance for production use because it can provide more durability for Pipelines-as-Code. If MySQL becomes unavailable, you need to update your Dinghy files in order to repopulate MySQL with the relationships.

Configure the RDBMS driver exactly as described in Set up Clouddriver to use SQL - Database Setup. The MySQL database schema must be configured to with:

• Default character set utfmb4
• Default collate utf8mb4_unicode_ci

First make sure the schema exists in your database.

CREATE SCHEMA IF NOT EXISTS dinghy DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
      CREATE USER IF NOT EXISTS 'dinghy_service'@'%' IDENTIFIED BY '${SOME_PASSWORD_HERE}';
      CREATE USER IF NOT EXISTS 'dinghy_migrate'@'%' IDENTIFIED BY '${SOME_PASSWORD_HERE}';
      GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, EXECUTE, SHOW VIEW ON dinghy.* TO 'dinghy_service'@'%';
      GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX, ALTER, LOCK TABLES, EXECUTE, SHOW VIEW ON dinghy.* TO dinghy_migrate@'%';

Next, configure Pipelines-as-Code to use your MySQL database.

• Spinnaker
• Armory CD

sql:
  baseUrl: mysql:3306
  databaseName: dinghy
  enabled: true
  password: <password>
  user: <user>

spec:
  spinnakerConfig:
    profiles:
      dinghy:
        sql:
          baseUrl: mysql:3306
          databaseName: dinghy
          enabled: true
          password: password
          user: user

Migration from Redis to SQL

There is a migration strategy to move the relationships from Redis to SQL. In order to do that, you need to have the configuration from your Redis and add the configuration for MySQL as shown previously. When you do this and the pod starts, what happens is that the migration is done automatically by a job. To verify that the migration was done successfully, you can access your database and run the following query:

select * from executions;
select * from fileurls;
select * from fileurl_childs;

In the executions table, you should be able to see one record with the name REDIS_TO_SQL_MIGRATION.

In fileurls and fileurl_childs, you should be able to see the migration information with the Dinghyfiles, modules, and their relationships.

After Dinghy finishes the migration, it closes the Redis connection and works in full MySQL mode.

Fiat

If you have enabled Fiat, add the field fiatUser: <your-service-account> to your config. Note that the service account has to be in a group that has read/write access to the pipelines you are updating.

If you have app specific permissions configured, make sure you add the service account. For information on how to create a service account, see Creating service accounts.

• Spinnaker
• Armory CD

fiatUser: <your-service-account>

spec:
  spinnakerConfig:
    config:
      armory:
        dinghy:
          fiatUser: <your-service-account>

Negative expressions support

The Regexp2 engine supports negative expressions, so you don’t need to define patterns for all files to be ignored. You can ignore everything other than required files. For example, in your project you have some project-specific files: file.js, file.ts, file.css. You also have files used by Dinghy: dinghyfile, minimum-wait.stage.module, maximum-wait.stage.module. If you enable dinghyIgnoreRegexp2Enabled, you can create your .dinghyfile with one of the following regular expressions:

• file.(js|ts|css)
• ^(?!.(.stage.module)|(dinghyfile)).

Both of those regular expressions product the same result:

• file.js -> ignored
• file.ts -> ignored
• file.css -> ignored
• dinghyfile -> processed by Dinghy
• minimum-wait.stage.module -> processed by Dinghy
• maximum-wait.stage.module -> processed by Dinghy

Add dinghyIgnoreRegexp2Enabled: true if you want Dinghy to ignore everything other than required files.

• Spinnaker
• Armory CD

dinghyIgnoreRegexp2Enabled: true

spec:
  spinnakerConfig:
    config:
      armory:
        dinghy:
          dinghyIgnoreRegexp2Enabled: true

Notifications

Slack notifications

If you configured Armory CD or Spinnaker to send Slack notifications for pipeline events, you can configure Pipelines-as-Code to send pipeline update results to Slack.

• Spinnaker
• Armory CD

notifiers:
  enabled: true         # Enable to allow any notifier type to occur
  slack:
    enabled: true       # Whether or not Slack notifications are enabled for Dinghy events
    channel: <my-channel> # Slack channel where notifications will be sent to
  github:
    enabled: false       # (Default: true) Whether or not github notifications are enabled for Dinghy events; once `spec.spinnakerConfig.profiles.dinghy.notifiers` are enabled, only enable this if you want both Slack and GitHub notifications at the same time

spec:
  spinnakerConfig:
    config:
      armory:
        dinghy:
          enabled: true
          notifiers:
            enabled: true         # Enable to allow any notifier type to occur
            slack:
              enabled: true       # Whether or not Slack notifications are enabled for dinghy events
              channel: my-channel # Slack channel where notifications will be sent to
            github:
              enabled: false       # (Default: true) Whether or not github notifications are enabled for Dinghy events, once spec.spinnakerConfig.prifles.dinghy.notifiers are enabled.  Only enable if you want both slack and github notifications at the same time

GitHub notifications

Dinghy can provide more robust information to GitHub about executed pipeline changes. This information appears as a comment in the PR.

Keep the following in mind when enabling GitHub notifications:

• When using Armory CD versions below 2.26.2, GitHub notifications are not supported with custom endpoints and should be disabled due to a known issue. This issue has been resolved as of 2.26.2, Dinghy Change #447.
• Enabling this functionality may lead to a large number of comments on a pull request if, for example, you update a module that is used by multiple pipelines. This can lead to the GitHub UI not loading or GitHub rate limiting cause of related API calls.

• Spinnaker
• Armory CD

notifiers:
  enabled: true
  github:
    enabled: true # (Default: true) Whether or not github notifications are enabled for Dinghy events; once `notifiers` are enabled, only enable this if you want both Slack and GitHub notifications at the same time

spec:
  spinnakerConfig:
    profiles:
      dinghy:
        notifiers:
          enabled: true
          github:
            enabled: true # (Default: true) Whether or not github notifications are enabled for Dinghy events, once spec.spinnakerConfig.profles.dinghy.notifiers are enabled

Permissions check for a commit

The userWritePermissionsCheckEnabled feature, when enabled, verifies if the author of a commit that changed app parameters has sufficient WRITE permission for that app. You can specify a list of authors whose permissions are not valid. This option’s purpose is to skip permissions checks for bots and tools.

How this feature works

A webhook generated by commits pushed to a branch contains information about the commit author. Dinghy extracts the author’s email and fetches user roles for that email from Fiat. Given the roles, Dinghy fetches app permissions and compares the app’s WRITE roles with the roles of the author. If they match, Dinghy processes the webhook and applies changes from the commit to the app or pipelines. If permissions don’t match, Dinghy rejects the webhook since the author doesn’t have the required write permissions.

How to enable

This feature is disabled by default to prevent users from experiencing unexpected application behavior. You can enable the feature by setting userWritePermissionsCheckEnabled to true. When you omit userWritePermissionsCheckEnabled or set it to false, Dinghy does not check permissions.

To skip permissions checks for users such as bots or service accounts, set the value of ignoreUsersWritePermissions to the comma-delimited list of repo user email addresses.

When userWritePermissionsCheckEnabled is false or omitted, ignoreUsersWritePermissions has no effect.

• Spinnaker
• Armory CD

userWritePermissionsCheckEnabled: true
ignoreUsersWritePermissions: “user1@example.com,user2@example.com”

spec:
  spinnakerConfig:
    config:
      armory:
        dinghy:
          userWritePermissionsCheckEnabled: true
          ignoreUsersWritePermissions: “user1@example.com,user2@example.com”

Template formats

Pipelines-as-Code supports two additional template formats in addition to the default JSON:

• HCL
• YAML

Selecting one of these parsers means that all of your templates must also be in that format.

• Spinnaker
• Armory CD

parserFormat: <parser-format>

spec:
  spinnakerConfig:
    profiles:
      dinghy:
        parserFormat: <parser-format>

Replace <parser-format with one of the parsers:

• json (Default)
• yaml
• hcl

What’s next

• Use Pipelines-as-Code in Armory Continuous Deployment