Helm manager with registryAliases in config containing '/' (slash)

[meyfa]

What would you like help with?

I think I found a bug

How are you running Renovate?

Self-hosted

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

GitLab, Renovate v37.397.0

Please tell us more about your question or problem

This is a follow-up bug report to GHSA-rqgv-292v-5qgr.
In our global config, we are defining the following registryAliases that are used with some internal Docker images hosted on a private Harbor registry:

registryAliases: {
    '$HARBOR_HOST/$HARBOR_PROJECT': 'registry.example.com/proxy',
    '$HARBOR_HOST/tools': 'registry.example.com/tools'
},

The images are used within GitLab CI/CD, hence the variables - they are replaced by GitLab during the CI run. The registryAliases are defined for Renovate so that Renovate knows how to fetch new image versions.

However, the helmv3 manager is adding the registryAliases meant for Docker via invocations of helm repo add <key> <value>. Unfortunately, this causes an error:

File name: services/some-helm-application/Chart.lock

Command failed: helm repo add '$HARBOR_HOST/$HARBOR_MROJECT' registry.example.com/proxy --force-update
Error: repository name ($HARBOR_HOST/$HARBOR_MROJECT) contains '/', please specify a different name without '/'

This unfortunately results in an incomplete merge request, and we are effectively prevented from updating any Helm dependency.

(Note: The string MROJECT instead of PROJECT in the output above is due to Renovate replacing all occurrences of PR with MR when using GitLab instead of GitHub, and is unrelated to this report.)

Since the registryAliases are only used for Docker, acceptable solutions would include:

1. Checking the key for invalid characters (invalid according to helm repo add), and if found, then don't use the registry alias with Helm.
2. Sanitizing the key before passing to helm repo add, e.g., turning $HARBOR_HOST/$HARBOR_PROJECT into _HARBOR_HOST_HARBOR_PROJECT before passing to Helm.
3. Warning about the failure in helm repo add, but still continuing the execution, such that at least a complete patch is created.

Logs (if relevant)

[meyfa]

We were able to solve it by configuring registryAliases under the top-level gitlabci manager object, such that no other manager attempts to use them:

gitlabci: {
    registryAliases: {
        '$HARBOR_HOST/$HARBOR_PROJECT': 'registry.example.com/proxy',
        '$HARBOR_HOST/tools': 'registry.example.com/tools'
    }
},

I think this issue still needs a fix because:

• Coming up with this solution is non-trivial
• The existence of top-level manager objects is not well-documented