We previously enforced `allowedHeaders` by making sure that each
`hostRules.add()` call had `filterAllowedHeaders`.
This isn't super future proofed, and although we could add a linting
rule, we should instead enforce this by making sure that
`hostRules.add()` applies the filtering.
This also catches cases like host rules from `.npmrc` which wasn't
currently being filtered - albeit there was no means to bypass
`allowedHeaders`.
Moving `filterAllowedHeaders` into `lib/util` removes a dependency from
the global bootstrap and `config-validator` importing from
`lib/workers/repository/init/`.
While doing so, we can also make sure that:
- we log only one WARN for global `hostRules` being invalid, rather than
once per `repositories[]`
- `renovate-config-validator` validates a global config file's
`hostRules` against that file's own `allowedHeaders`, like a real run
would after parsing it
Co-authored-by: Claude Fable 5 <jamie.tanna+claude-code@mend.io>
For some time, admin configuration for `hostRules[].headers` was
enforced through `allowedHeaders`, but no validation feedback was given
to administrators, as it was silently ignored when `applyHostRule` runs.
To provide visibility to administrators who were setting headers that
were silently being ignored, we can instead provide validation at the
time we set our global host rules.
In a future change, we'll align the behaviour of `allowedHeaders` and
`allowedEnv` to make it so admin-controlled `hostRules` aren't bound by
the `allowedHeaders` flag.
We can also make it clear in the documentation that this is the
behaviour.
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
* fix(config-validator): warn when RE2 is not in use
Without RE2 the validator checks patterns with the JS RegExp engine, which
accepts syntax RE2 rejects, so configs can validate clean here and then be
rejected when Renovate runs.
Co-Authored-By: Claude (Opus 5) <noreply@anthropic.com>
* fix(config-validator): debug log for the RE2 opt-out
Setting RENOVATE_X_IGNORE_RE2 is deliberate, so it does not warrant a warning,
matching what the global worker already does.
Co-Authored-By: Claude (Opus 5) <noreply@anthropic.com>
---------
Co-authored-by: Claude (Opus 5) <noreply@anthropic.com>
Co-authored-by: Jamie Tanna <jamie.tanna@mend.io>
Per #40738 and #44034, we're seeing recent changes to
`renovate-config-validator` that have led to either a gap in
functionality or a breaking change that makes
`renovate-config-validator` unusable.
To make sure that we ensure that we're always making reasonable changes
to `renovate-config-validator`, we can introduce an integration test
harness to validate the call end-to-end.
We can make sure to handle:
- `--version`
- using global/repo config files
- any of the known config filenames (#44034)
- explicitly test a JSONC and JSON5 file with their respective example
content
Due to the full end-to-end run of `renovate-config-validator`, which
creates a full Node process, we can run the tests concurrently to ensure
that we speed up the test runs, as they're fairly slow in comparison to
regular tests.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
Jamie Tanna