Add template compilation support for sourceUrl in package rules,
allowing users to dynamically construct source URLs using template
syntax. This enables use cases like OpenTofu providers where the
source URL needs to be constructed from the package name.
This also makes sure that our URL fragments should be more consistent
over the years, as duplicate names (across parent and child options)
cannot clash.
This also corrects links from the code to include the new fragment.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
As it was in the middle of the `customManagers` documentation.
As it's now in the correct place, we need to re-sort the headers so the
`customDatasources` options are in the right place.
As noted in #40608, we're currently showing an outdated list of possible
configuration filenames.
We can instead automate this by using the known configuration files we
know.
As we don't yet support the Platform-specific filenames, we shouldn't
include them, but add a TODO so we don't miss it.
* feat(managers/npm): allow specifying `toolSettings.nodeMaxMemory`
As noted in #40942, we're seeing an increase in memory usage across
`pnpm` and `yarn` users in Mend-hosted apps.
To allow limiting the maximum memory that any `node` child processes
will use, we can add a new `toolSettings.nodeMaxMemory` to (hopefully)
mitigate this.
Similar to the `toolSettings.jvmMaxMemory`, the self-hosted
administrator can set a maximum, which cannot be exceeded by repo-level
configuration.
* fixup! feat(managers/npm): allow specifying `toolSettings.nodeMaxMemory`
* feat(postUpgradeTasks): allow specifying `installTools`
As noted in #8111 and #41569, it is possible that when using
`binarySource=install`, you can execute a `postUpgradeTasks`' given
command without Renovate having the right tools installed, dependent on
the Manager used for the update.
To make it possible for users to indicate that they explicitly need
given tools (at a given `constraint`), we can introduce a new
`installTools` option which will allow specifying which tools +
constraints to use when invoking the `postUpgradeTasks`'s command.
Right now, we're not defining what the `installTools'` interior type is,
but leaving it open to extension.
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
* docs: add examples for `toolVersions`
---------
Co-authored-by: gpt-4.1 <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>
* feat(nuget): add supportsLockFileMaintenance flag
The NuGet manager supports lock file maintenance via `packages.lock.json`
but was missing the `supportsLockFileMaintenance` export.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* feat(manager): add lockFileNames metadata to all lock file managers
Add `lockFileNames` field to `ManagerApi` interface and export it from
all 24 managers that support lock file maintenance. This metadata will
be used to auto-generate the lock file support table in docs.
Also adds a validation test ensuring managers with
`supportsLockFileMaintenance` always provide `lockFileNames`.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* feat(docs): auto-generate lockFileMaintenance lock files table
Replace the hardcoded lock file support table in configuration-options.md
with autogenerate markers and generate it from manager metadata during
docs build. This ensures the table stays in sync with manager code
automatically.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
This change introduces a heap size limitation for the Gradle daemon used
when updating the Gradle wrapper, defaults to 512m.
The heap size is limited to the globally configured limit, which
defaults to 512m. It can be configured on the repository level, but not
exceed the globally configured limit. A hard coded mimiumum heap size of
512m is enforced.
The configuration option is named `toolSettings`, which has two
properties for the maximum and initial heap size. See
`docs/usage/configuration-options#toolSettings` for more details.
As noted in #40716, we should provide more in-depth documentation about
Renovate's JSON Schemas as they are very useful for editor/agent
autocomplete.
Additionally, as part of the Renovate 43 release, it's something that
would be useful to link out to.
* registryAlias for bazel-module oci.pull
* use getDep from dockerfile manager instead
* expand testing for oci.pull
* test: merge autoReplaceStringTemplate assertion into registryAliases test
* move assertion to other test
* Update lib/modules/manager/bazel-module/extract.spec.ts
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
---------
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
* feat: add support for go:generate directives in gomod
This change adds a `goGenerate` postUpdateOption which enables
running `go generate ./...` after a dependency update.
Frequently when dependencies are brought in via tools or using
vendored code, and those dependencies are used for go:generate
instructions, we want to update the generated code after the dependency
has been updated.
Adding this as a postUpdateCommand wasn't really satisfactory since that
necessarily requires making a change in two spots (one in the allowed
commands, one in the postUpdateCommand). The other reason this was
undesirable was it would cause generate to run after every dependency
update, regardless of language.
* Updates
* Update fixes
* Self PR
* Fix docs link
* Trying to find the right path
* Fix
* Add deleted
* Fix
* And fix test...
* docs: tweak wording for `goGenerate`
* fix(types): don't default GlobalConfig
In a future change, `GlobalConfig.get` will correctly pull in the
defaults.
---------
Co-authored-by: Jamie Tanna <jamie.tanna@mend.io>
As it was renamed in #39406, but looks like there were warnings we
didn't spot, which are now failing when the docs attempt to build with
these new changes.
* docs(constraints): clarify that `binarySource=global` ignores them
Although this is a somewhat commonly known behaviour, it's worth making
this more clear, by clarifying this in the `constraints` docs, as well
as add a debug log.
* docs(constraints): simplify message
As noted by Michael, these may not be user-facing `constraints`, but the
constraints a Manager sets.
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
---------
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
Ahead of Renovate 42, where `minimumReleaseAge` is enforced by default
for `config:best-practices` users of npm, and an increase in users of
the functionality given recent supply chain attacks, we should add more
in-depth documentation about how it works, how to tune it, and how to
determine which datasources, registries, packages and `updateType`s
support it.
Co-authored-by: gpt-oss:20b <jamie.tanna+ollama@mend.io>
As we've had a few recent questions about how to use it and to confirm
whether it works on a given registry, and as we're promoting it to a
"best practices" feature, we should clarify how to confirm the
datasource supports it, as well as hint at how to add it yourself.
As noted in #38290, #38348, a "rough edge" of the current implementation
of `minimumReleaseAge` is that:
- if we have set `minimumReleaseAge` to apply to a given dependency
- and we have 3 dependencies that need an update
- 2 of which have a `releaseTimestamp` that is not yet "stable"
- 1 of which does not have a `releaseTimestamp`
The dependency update that does not have a `releaseTimestamp` will be
treated as "stable", and will receive an update immediately.
To make this a little more predictable, and explicit, we should add a
new configuration item, `minimumReleaseAgeBehaviour`, to control this
behaviour.
This adds the new configuration field, as well as making it available as
a strongly typed field in the codebase.
In the case that `minimumReleaseAgeBehaviour=timestamp-optional` is
being used, we will WARN on any packages that are being updated, but
maybe shouldn't be, as a way to proactively inform the user of possible
misconfiguration.
Closes#38290, #38348.
Thomas Rouaux