Custom NodeJS registry not supported in post-update step of npm manager

[pmaieref]

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, Renovate 39.29.0

Please tell us more about your question or problem

General Description

Hello,
I tried to make use of the https://docs.renovatebot.com/configuration-options/#updatelockfiles setting, to automatically update our dependencies via Yarn, but I am running into an error that "https://nodejs.org/dist/index.json" can't be reached as it is blocked via our firewall.

After building a custom image that adds additionall logging I found out that albeit it is possible to overwrite the registry and redirect "everything" to for example a Nexus installation (allowedEnvs, URL_FROM/TO, package rules, ...), it does not work when suppling a version range (caret version, ...) within the supported files (package.json - engine, nvmrc or nodenev).

Keep in mind, this isn't an issue when pinning the version as the lookup isn't required and the version is forwarded to the containerbase install-tool as-is. Not using a caret-range isn't really feasible though.

For example: ^22 does not work, but 22.11.0 would work.

Issue within the code:

During post-update execution and collecting some data, building commands, etc, the ToolConfiguration is eventually forwarded to the containerbaise.ts where constraints are resolved. But this call completely ignores any configuration from outside and instead uses a seemingly hardcoded default set for all tools:

renovate/lib/util/exec/containerbase.ts

Line 280 in d97c937

const toolConfig = allToolConfig[toolName];

Following the code path / call-chain, we end up in the resolveRegistryUrls(...) method in the datasource/index.ts, which would usually handle setting up the custom registry, but due to not passing all the necessary information, this results in the registryUrls[] being undefined and the default value is used:

renovate/lib/modules/datasource/index.ts

Line 231 in d97c937

registryUrls: string[] | undefined | null,

This then leads to fetching the available releases via the node-version datasource using the wrong (default) url:

renovate/lib/modules/datasource/node-version/index.ts

Line 50 in bd8a187

joinUrlParts(registryUrl, 'index.json'),

If I am not missing something (which might very well be), the containerbase.ts needs to use the config from outside, instead of using the default configuration.

As a side note, when starting up renovate, it first checks for required updates, which utilizes getRawPkgReleases(...), similar to the other code path. But instead of passing only a subset of the GetPkgReleasesConfig (

renovate/lib/util/exec/containerbase.ts

Line 231 in bd8a187

return getPkgReleases(toolConfig);

), the full configuration is passed (

renovate/lib/workers/repository/process/lookup/index.ts

Line 140 in bd8a187

const { val: releaseResult, err: lookupError } = await getRawPkgReleases(

) and the index.json is fetched via the rewritten / custom registry.

Mitigation / Fixes:

Option 1) Allow https://nodejs.org/dist/index.json through the firewall
=> Sure that might be a potential solution, but then it should be documented somewhere that this isn't possible. Or maybe I just didn't find where this is documented.

Option 2) Build a custom image, manually overwriting the "hardcoded" nodejs.org registry.
=> Can be mostly automated and changes to the affected file are probably minimal, but not the best solution imho.

Option 3) "Fix it." I am not 100% if this is a bug or intended by design. It seems the containerbase.ts assumes default values for basically all tools, so it seems like it would be some work to pass through the correct configuration, but I think if overwriting registries (and more) is supported, it should work for this too.

Option 4) Using a full image, not "install".
=> Sure an option. But the image is much bigger and requires some more handling in regards to node-versions.

Other related issues

There is the following issue / discussion: #31643
=> Has been closed with the comment to use containerbase/base, but as far as I can see, this wouldn't work. The error occurs earlier and not in containerbase itself, but maybe I misunderstood this.

Additionally there is this discussion: #31660
=> In hindsight it seems to describe the exact same problem, I maybe should have just posted my answer there. Sorry if I am now duplicating things. But as described above, the allowedEnvs would not work as far as I can see.

If there is anything else needed, I'd be happy to help out.
Thanks!

Logs (if relevant)

Logs (I can add some if requested, but the description above will hopefully suffice)

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