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.

[pgmgb]

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.

Same for us - this would enable a "more less" automated rollout of patches.

[lehmanju]

I have the same issue and I also think it is quite common. Maybe Renovate could implement some form of custom status check, similar to the stability days branch status check.

Users then have the option to specify a CEL expression that has some predefined variables available. The status check is yellow/green based on the evaluation of this expression. The context could be the current state of all repository dependencies + available updates. These expressions would be defined in a packageRule.

Would this work?