Skip to content

Group multi-service deployments in single PRs #154

@bendiknesbo

Description

@bendiknesbo

We use 1 repo per system, and each system may contain multiple services, and usually the different services are built and released as a single GitHub release. Instead of creating 1 PR per service, we should create 1 PR per values-*.yaml helm-file.

Something like the following rules has been proven to work:

{
    $schema: "https://docs.renovatebot.com/renovate-schema.json",
    extends: ["github>coopnorge/github-workflow-renovate"],
    packageRules: [
        // Group deployments per environment, so that we can bump all services for an environment in 1 PR
        {
            matchPackageNames: [
                "europe-docker.pkg.dev/pallet-customer-master-d-2c27/pallet-customer-mas7c7e2-default/customer-master-data/**",
            ],
            matchFileNames: [
                "infrastructure/kubernetes/helm/customer-master-data-management/values-staging.yaml",
            ],
            groupName: "Deploy staging",
        },
        {
            matchPackageNames: [
                "europe-docker.pkg.dev/pallet-customer-master-d-2c27/pallet-customer-mas7c7e2-default/customer-master-data/**",
            ],
            matchFileNames: [
                "infrastructure/kubernetes/helm/customer-master-data-management/values-production.yaml",
            ],
            groupName: "Deploy production",
        },
    ],
}

addLabels: ["skip-changelog"] can also be used to not include these bump-PRs in the changelog.

Maybe some better matching is required to bring this into Coop-global renovate-config, and maybe the skip-changelog should be opt-in (or opt-out).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions