Overriding a preset that contains inaccessible encrypted, secrets

[stekern]

How are you running Renovate?

Mend Renovate hosted app on github.com

If you're self-hosting Renovate, tell us what version of Renovate you run.

No response

If you're self-hosting Renovate, select which platform you are using.

None

What is your question?

I have stumbled upon an issue that I'd like some guidance on.

There's a shared preset in GitHub organization X that contains a secret scoped to that organization used for authenticating to a package registry. I want to use that preset in a repository in GitHub organization Y. I thought I would be able to do this by creating a new preset in GitHub organization Y that contains a secret scoped to that organization, and use a renovate.json similar to this:

{
  "extends": [
    "github>x:renovate-config:default",
    "github>y:renovate-config:override-secret"
  ]
}

The idea would be that presets will be merged, and that the secrets in the latter preset override the ones in the first preset. This, however, does not seem to work as it seems like preset validation is performed before the presets are merged into the final configuration.

My questions are:

• Should this work?
• Are there other ways to do solve the issue I'm describing?

Logs (if relevant)

Logs

DEBUG: Found encrypted config
{
  "config": {
    "token": "***********"
  }
}

DEBUG: Trying to decrypt token
DEBUG: Decrypted config using openpgp
DEBUG: Secret is scoped to a different org
{
  "orgPrefixes": [
    "X/"
  ]
}

WARN: Could not parse decrypted string
{
  "err": {
    "validationError": "Encrypted secret is scoped to a different org: \"X/\".",
    "message": "config-validation",
    "stack": "Error: config-validation\n    at tryDecrypt (/opt/containerbase/tools/renovate/37.153.2/node_modules/renovate/lib/config/decrypt.ts:142:31)\n    at processTicksAndRejections (node:internal/process/task_queues:95:5)\n    at decryptConfig (/opt/containerbase/tools/renovate/37.153.2/node_modules/renovate/lib/config/decrypt.ts:186:30)\n    at decryptConfig (/opt/containerbase/tools/renovate/37.153.2/node_modules/renovate/lib/config/decrypt.ts:238:13)\n    at mergeRenovateConfig (/opt/containerbase/tools/renovate/37.153.2/node_modules/renovate/lib/workers/repository/init/merge.ts:266:24)\n    at getRepoConfig (/opt/containerbase/tools/renovate/37.153.2/node_modules/renovate/lib/workers/repository/init/config.ts:12:12)\n    at initRepo (/opt/containerbase/tools/renovate/37.153.2/node_modules/renovate/lib/workers/repository/init/index.ts:52:12)\n    at Object.renovateRepository (/opt/containerbase/tools/renovate/37.153.2/node_modules/renovate/lib/workers/repository/index.ts:55:14)\n    at attributes.repository (/opt/containerbase/tools/renovate/37.153.2/node_modules/renovate/lib/workers/global/index.ts:184:11)\n    at start (/opt/containerbase/tools/renovate/37.153.2/node_modules/renovate/lib/workers/global/index.ts:169:7)\n    at /opt/containerbase/tools/renovate/37.153.2/node_modules/renovate/lib/renovate.ts:18:22"
  }
}

[rarkins]

Secrets can be encrypted with multiple orgs (comma separated). If the preset is intended to be used in multiple orgs, then re-encrypt the secrets that way. If the preset is not intended to be used in multiple orgs.. stop doing it

[stekern]

I'm totally onboard with this as a general concept being a bad practice. But let's say you did have a good reason for doing this (e.g. as a temporary solution) - is it technically possible to do this, or will the validation always be performed before merging the presets into the final configuration?

[rarkins]

My memory (but without code review to confirm) is that presets are resolved immediately. What you're after is some type of "lazy" resolution and merging, which is not possible. If you can find an elegant way to do so in a PR you are welcome to propose one