There are some variables in this list which don't have the prefix RENOVATE_X, should they be included in this refactor too?
eg., https://docs.renovatebot.com/self-hosted-experimental/#otel_exporter_otlp_endpoint

Do you mean we store all these variables and values in experimentalFlags object?
ie.,
old

# .env
RENOVATE_X_HARD_EXIT=false

new

// config.js
"exprimentalFlags": {
  "HARD_EXIT": false
}

I was going to keep them as an array. If they need a value then it could be like abc=10. One like this could be turned around such as "softExit" or "exitCodeZero"

There are some options such as RENOVATE_X_IGNORE_RE2 which are used before GlobalConfig is initialized, what should be do about them?

How many of those are there? I guess we need to keep them

Two with the prefix RENOVATE_X:

RENOVATE_X_HARD_EXIT

RENOVATE_X_IGNORE_RE2

Ok keep them as is for now

I think we are clear on the requirements. Here's the implementation plan I came up with:

First make necessary changes in initial PR (ideally also convert 2,3 env vars to flags as examples). Then in many follow up PRs convert all the env vars to flags.

For this it would be best to create a new branch from the main branch, where all the initial and follow up PRs could be merged, before finally merging that one into main again. I am not sure about this btw, since these are experimental features doing all in one PR seems fine to me as well. But it should be easy in a multiple PRs.

Changes to be included in the initial PR:

• add experimentalFlags config option
• logic for validating experimentalFlags and type-based validation of each flag within it
• add description of experimentalFlags in the docs

I've put together this PR as a starting point. I've tried to implement the necessary logic to handle the exeperimental flags. I have also converted 2 env vars to flags in this PR as examples.

More details in the PR description.

@viceice @secustor what if we drop the "experimental" naming and instead use "globalFlags" or "adminFlags"? We can always flag individual flags as experimental if we want to consider removing them.

Part of using flags here was to reduce the volume of unique config options when many of them are simply boolean and need little more than a one-sentence description.

IMO it make sense to have experimental in the naming.
We communicate that these features are unstable and subject to change without looking at the docs.
Further that extra scrutiny is expected as they are not part of the normal configuration.

If that is not the intend we can migrate all flags to config options with the experimental setting. 🤷

ok

Fresh list of the the experimental vars which remain to be converted, with some related infromation.

This list doesn't include the env vars which have been converted in #28187, #28397 and #28880