Monorepo update strategy suggestions

[pgmgb]

How are you running Renovate?

Self-hosted Renovate

If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.

GitLab

Please tell us more about your question or problem

We have a monorepository in GitLab with the following structure:

.
├── config
│   ├── dev
│   │   ├── app1
│   │   │   └── helmfile.yaml
│   │   └── app2
│   │       └── helmfile.yaml
│   ├── prod
│   │   ├── app1
│   │   │   └── helmfile.yaml
│   │   └── app2
│   └── qual
│       ├── app1
│       │   └── helmfile.yaml
│       └── app2
└── rendered
    ├── dev
    │   ├── app1
    │   └── app2
    ├── prod
    │   ├── app1
    │   └── app2
    └── qual
        ├── app1
        └── app2

In the config folder, we have for each environment apps, which use helmfile like this:

---
repositories:
  - name: app1
    url: https://charts.app1.com

releases:
  - name: app1
    namespace: app1
    chart: "app1/app1"
    version: 0.1.0

A custom script will parse the config folder and renders with helmfile --file "$helmfile" template | kubectl slice ... the needed YAML files to the corresponding rendered folder.

Renovate is able to automatically update the versions of the releases, which, based on CI/CD, re-renders the YAML files and keeps them up to date. ArgoCD on the other hand, is pointed to each rendered folder of the application and makes sure to synchronize all needed changes into our Kubernetes cluster.

At the moment, the environments dev, qual and prod will be updated as soon as Renovate detects a newer version of the corresponding helm chart. We, on the other hand, would like to introduce delayed patching. dev should be updated first, and after some time qual and at the end the prod environment. 

I'm aware of the minimumReleaseAge configuration, which somehow could fit because dev could have 2 days, qual 7 days and prod 14 days. This would enforce (in my understanding) a delayed patching. But these two points would not be addressed:

• Only patches that have been applied to dev should be applied in qual. And only patches applied to qual should be introduced in prod. No "untested" update should reach prod.
• How could we exclude certain updates if we encounter troubles with them?

Not sure, if there is a solution with Renovate or if there are other approaches for that kind of use case? Suggestions and inputs are more than welcome :-)

Logs (if relevant)

Logs

Replace this text with your logs, between the starting and ending triple backticks

[rarkins]

I'm not aware of any solution to this problem

[mfoo]

We have a monorepo with helm files with a similar structure. Our solution for making sure things get merged into lower environments and tested before prod is manual, however, the separate MRs problem we're solving like this:

flux: {
  additionalBranchPrefix: "{{packageFileDir}}-",
  commitMessagePrefix: "[{{{packageFileDir}}}]",
  fileMatch: ["\\.yaml$"],
},

This seems to cause separate MRs for the same version bump in different folders.

Edit: I'd love to see if we could delay each environment by a set number of days, or better, restrict specific files from receiving updates until the same update has been applied to different files.