* 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>
* fix(config/global): return default values for `GlobalConfig.get`
As noted in #39949, it can be awkward working with in `GlobalConfig.get`, where
we would previously need to specify the default value when calling `.get`,
which could lead to drift with the defaults for a given config option.
To reduce this risk, we can rely on a given `default` for a configuration
option, providing that as a default.
Because this now definitely returns a value that matches the config option, it
now allows us to remove `!` assertions.
* fixup! fix(config/global): return default values for `GlobalConfig.get`
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
* fixup! fix(config/global): return default values for `GlobalConfig.get`
* test(presets): remove impossible test
As it's now not possible to set a value as `undefined` (as
`GlobalConfig` will then use the default), this test no longer validates
anything.
* test(workers/repository): add mock
Now `platform` defaults to `github`, we need to mock out the call to
fetch config.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* test: coverage
* test: coverage
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
As `fileName` makes more sense (as it's not always a lock file we're
updating).
Also, if you set `fileName`, it would never actually output the
filename.
This renames the usages of `lockFile` to `fileName`.
Co-authored-by: Claude Sonnet 4.5 <jamie.tanna+github-copilot@mend.io>
As noted in #39559, we should also make it possible to use Renovate's
`toolSettings` to tune the Java Virtual Machine that's used to spawn
Gradle, via the Gradle Wrapper.
This will affect any `gradle` manager invocations, but will not apply to
`postUpgradeTasks`, as this is passed in as a parameter.
Co-authored-by: Claude Sonnet 4.5 <jamie.tanna+github-copilot@mend.io>
As a safety measure for self-hosted administrators, we can make sure
that we set `allowedUnsafeExecutions` to not allow any commands by
default.
This closes off a significant risk of executing Gradle Wrapper
commands, which use the repository's copy of the wrapper, and any
Gradle buildscript, when executing, which can lead to significant remote
code execution, even before you take into account malicious dependencies.
As this is now off-by-default, we can enable it by default in our tests
to make sure that there are minimal changes required.
We recently introduced the ability for self-hosted administrators to
control execution of possibly unsafe commands with
`allowedUnsafeExecutions`.
An existing attack vector of Gradle Wrapper commands being executed
(i.e. for Verification Metadata or lockfile updates) needs to be
retrofit into `allowedUnsafeExecutions` as part of #39657.
This will be kept on-by-default until the next breaking change, after
which self-hosted administrators will be able to opt-in to enabling this
functionality is required.
Sebastian Poxhofer