* 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>
* docs: add "previously known as" to renamed options
To provide a more searchable set of docs in the case that we migrate a
config option, we can introduce a `previouslyKnownAs` field in the
resulting generated documentation.
This allows someone to search for the previous name and find the new
option name.
For now we'll also not implement `RENOVATE_X_` variables.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fixup! docs: add "previously known as" to renamed options
This is a more involved change, which requires we handle the custom
coersion for `RENOVATE_REPOSITORY_CACHE_FORCE_LOCAL`.
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>
To provide more programmatic means to determine what environment
variables configure Renovate configuration options - and whether they're
Repo, Inherit or Global config options - we can expose these in two
forms:
- `getEnvOptionsMap()`
- a static JSON file, `renovate-env-options.ts`
This will provide programmatic use-cases from a plain JSON file that can
be used more readily - especially as it's distributed in the docs and
built package - as well as a function that can be used by users of
Renovate-as-a-library.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
As part of #41323, we noticed that the error that's thrown isn't super
helpful, as it doesn't include the environment variable name.
To improve this, we can wrap the `Error` with the environment variable
name that's in use, as well as the error message.
In the future we can improve this further.
* fix(workers/global): migrate string-based `repositoryCacheForceLocal`
For users who had previously set `RENOVATE_X_REPO_CACHE_FORCE_LOCAL` to
a non-empty string, we can make sure to auto-migrate them to the
expected value of `true`.
Because this is an environment variable, we cannot use a migration, and
so instead need to handle it when we're performing the manual migration.
* test(workers/global): clarify empty `X_REPO_CACHE_FORCE_LOCAL` does not get migrated
We've been happily using this with Mend Renovate Self-Hosted customers
since introduction in 2024, and so we're happy making this
non-experimental now.
This follows other changes where we've promoted an experimental option
to non-experimental, and heavily driven by Claude Sonnet 4.5.
We can also rename config item to use the same `repositoryCache` prefix.
Co-authored-by: Claude Sonnet 4.5 <jamie.tanna+github-copilot@mend.io>
Drops `allowCommandTemplating` so that templating is always allowed. Changes validation logic so that `allowedCommands` are now compared to the post-compiled command instead of pre-compiled.
BREAKING CHANGE: `allowedCommands` filters need to be updated to match against the post-compiled `postUpgradeCommands` in cases where templating was in use.
Unifies CLI and env coercions.
BREAKING CHANGE: boolean variables must be true or false when configured in env, and errors will be thrown for invalid values. Previously invalided values were ignored and treated as false.
Add configuration option `detectHostRulesFromEnv`.
BREAKING CHANGE: `hostRules` are no longer automatically derived from env variables such as `NPM_X_TOKEN`. Set `detectHostRulesFromEnv=true` in config to re-enable same functionality.
Existing `azureAutoComplete` and `gitLabAutomerge` options are now unified/renamed to `platformAutomerge`, and also defaulting to `true`.
BREAKING CHANGE: Azure autocomplete will now only be enabled when `automerge` is also enabled (to align with how GitLab automerge already worked). If you were using `azureAutoComplete` before without explicitly enabling Renovate `automerge` field then you will now need to do so. Platform automerge is now the default behavior whenever automerge is enabled.
Sebastian Poxhofer