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>
* ci(linter): add renovate/logger-static-message rule
Adds a custom oxlint rule that enforces a static msg component for
logger.warn/error/fatal calls (including logger.once variants) so the
messages can be grouped in metrics and error catching services, per
docs/development/best-practices.md. It also flags metadata properties
named 'error' that hold error-ish values, because the bunyan serializer
only handles the 'err' key.
The rule is enabled as an error for lib/ production code and disabled
for spec files. All 33 pre-existing violations are fixed by moving
interpolated values into the metadata object, making messages static,
and renaming 'error' metadata keys to 'err'. Affected log-message
assertions in co-located specs are updated accordingly.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* ci: ignore validator output
* fixup new merged in log messages
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Enable no-else-return (with allowElseIf: false) and unicorn/no-lonely-if
as errors in .oxlintrc.json and fix all 131 pre-existing violations
(91 no-else-return, 40 unicorn/no-lonely-if) across 98 files.
The no-else-return violations were fixed with the oxlint autofix
(iterated to a fixpoint, plus two else-if chains that required
--fix-dangerously) followed by Prettier formatting. One comment dropped
by the autofix in lib/modules/manager/pub/artifacts.ts was restored
manually. The unicorn/no-lonely-if violations were merged by hand,
preserving comments and coverage-ignore hints.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* chore: ensure we use `productLinks` for docs site links where possible
Where possible, we should be making sure that we're using the
`productLinks`' configuration for the documentation site, especially
where self-hosted users may create a mirror of their docs[0].
To make sure we catch this in the future, we can introduce a custom
linting rule with Oxlint to enforce this.
Where we (currently) can't wire in the config, we can disable it against
that line.
[0]: https://www.jvt.me/posts/2024/11/19/renovate-private-docs/
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fixup! chore: ensure we use `productLinks` for docs site links where possible
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fixup! chore: ensure we use `productLinks` for docs site links where possible
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
As noted in #43280, there may be cases where users attempt to perform
config validation via stdin, or in a directory that doesn't contain any
configuration files, and it may be unexpected to see that the `Config
validated successfully`, if we didn't actually process anything.
To improve this, we can track how many file(s) are being validated, and
more visibly note when 0 files have been validated.
As noted in #41667, we didn't correctly handle the `--version` flag's
code coming back, so were unnecessarily reporting an error.
Co-authored-by: Claude Sonnet 4.5 <jamie.tanna+github-copilot@mend.io>
feat(renovate-config-validator): automagically detect global configuration
A long-standing issue with `renovate-config-validator` has been that
setting global configuration options such as `RENOVATE_ALLOWED_ENV` or
`RENOVATE_ALLOWED_COMMANDS` has no effect.
To make it possible to validate alongside the `config.js` (or other
self-hosted global configuration) as well as setting environment
variables while performing validation, we can ensure that we partially
initialise the `GlobalConfig`.
We can also make sure that this is documented as part of this change.
Functionality such as authenticating to the platform to retrieve remote
presets will be done at a future point.
As we want to be able to wire in Global Configuration (i.e. from a
`config.js` or environment variables) in the future, we need to first
make sure that we first make it possible to specify whether a specific
file is global or repo config.
As part of recent proposed changes with `renovate-config-validator`,
we've found that before new changes are made, we should align
`renovate-config-validator` with `renovate` in using Commander for a
lightweight framework for command-line applications.
As a replacement for #39953, we can introduce a more targeted help
message, providing more examples about usage.
We also introduce `@commander-js/extra-typings` to make sure that we
have better types for the `action` function.
We also need to make sure we call `parseAsync`, as we're using an
`async` function.
Adds support for alternative admin config file formats.
BREAKING CHANGE: Renovate will now fail if RENOVATE_CONFIG_FILE is specified without a file extension
Jamie Tanna