* docs: explicitly document `depTypes` each manager supports
A long-standing question we receive is "what `depTypes` can I match
against in my project".
Although the best recommendation we usually have is "check the
`packageFiles with updates" log line (as a very key log line for users),
we can go one step further and try and create a stronger contract.
To do this, I've used Claude Sonnet 4.6 to work through the codebase,
determine areas that a `depType` is set in a manager (statically or
dynamically) and generate a structured, typed, means to document how
they're used.
Through a few iterations of the process, and attempts at human-written
documentation, we've settled on:
- prioritising autogenerated documentation (for humans to read) to note
what `depTypes` are known, and what they are
- `knownDepTypes`, to describe any known, static, `depType`s and their
human-readable meaning
- with the `prettyDepType`, if used
- `supportsDynamicDepTypesNote`, to add a Markdown note to the generated
documentation
While here, we also:
- make sure to note this in the "adding a new package manager"
documentation
- remove any hand-written references to `depTypes` in each manager's
documentation page
- correct the Gleam `depTypes`
- make sure to use the `knownDepTypes`'s `prettyDepType` definition if
we know it, for a given `depType`
The descriptions have been generated by Claude Sonnet, with some
human-written tweaks where appropriate.
[0]: https://github.com/renovatebot/renovate/discussions/15176
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fixup! docs: explicitly document `depTypes` each manager supports
* docs(manager): display `depTypes` documentation if none present
For consistency, and to make it more explicit.
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* feat(datasource): add elm-package datasource
* refactor(elm): inline test fixtures
* fix(elm): correct import ordering in test file
* fix(elm): use zod/v3 import to match codebase conventions
* refactor(elm): rename types.ts to schema.ts
Follow project convention of using schema.ts for zod schema files.
* test(elm): add test for invalid JSON response
Use v8 ignore if directive and add test covering the null result
path when the API returns invalid JSON.
* refactor(elm): remove unreachable null check
* test(elm): add test for default registry URL fallback
* refactor(elm): guard against missing registryUrl instead of fallback
* fix(elm): handle ZodError gracefully instead of throwing
* feat(elm): add package cache for elm-package datasource
* feat(manager/npm): pass --before to npm install when minimumReleaseAge is set
* use logger metadata
* Apply suggestion from @viceice
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
---------
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
* fix(cache): instrument repository cache load and save
Wrap repository cache `load()` and `save()` calls with the existing
`instrument()` helper to create OpenTelemetry spans for cache lifecycle
operations. This gives operators visibility into repository cache
performance, especially useful with S3 backends.
Refs #41760
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* fix(cache): instrument package cache init and destroy
Wrap package cache `init()` and `destroy()` with `instrument()` to
create OpenTelemetry spans, matching the repository cache instrumentation
from the previous commit. Covers redis, sqlite, and file backends.
Refs #41760
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* docs: document cache lifecycle tracing in OpenTelemetry guide
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Move destroy() outside init instrument span
Avoids nesting the package-cache.destroy span inside
package-cache.init, making them sibling spans instead.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Use 'verb NounClass' span naming convention
Rename instrument span names from dot-notation (e.g.
'package-cache.init') to 'verb NounClass' pattern (e.g.
'init PackageCache') per reviewer feedback.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* feat: port Ubuntu versioning support to Debian container images
Resolves#27862.
Signed-off-by: Alexander Gil <pando855@gmail.com>
* refactor: Remove dead code in debian versioning
Signed-off-by: Alexander Gil <pando855@gmail.com>
* refactor: Rename groups to match
* perf: optimize isStable method by reusing getVersionByCodename result
* fix(debian): specify radix in parseInt for dated container image version
---------
Signed-off-by: Alexander Gil <pando855@gmail.com>
Co-authored-by: Jamie Tanna <jamie.tanna@mend.io>
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.
* feat(exec): register bazelisk as containerbase tool
* test(bazel-module): add failing tests for updateArtifacts
* feat(bazel-module): implement updateArtifacts for lockfile support
* feat(bazel-module): export updateArtifacts from manager index
* fix(bazel-module): address code review feedback
- Use logger.warn instead of debug for artifact errors
- Add utf8 encoding to readLocalFile calls
- Use getSiblingFileName for lockfile path derivation
- Add empty updatedDeps guard
- Strengthen test assertions
* docs(bazel-module): document lockfile support
* Update lib/modules/manager/bazel-module/index.ts
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
* Apply suggestions from code review
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
* fix(bazel-module): address review feedback
- Remove unnecessary afterEach in tests
- Use partial<StatusResult> for all StatusResult mocks
- Add lockfile maintenance support
- Export supportsLockFileMaintenance flag
* fix(bazel-module): handle untracked lock files and clarify docs
Check status.not_added alongside status.modified for lock file changes,
matching the pattern used by other managers (composer, gomod, etc.).
Clarify that Bazelisk (not Renovate) reads .bazelversion. Add test for
lockfile maintenance with no changes.
* feat(bazelisk): implement updateArtifacts for MODULE.bazel.lock
When the Bazel version in .bazelversion changes, run `bazel mod deps` to
regenerate MODULE.bazel.lock and return the updated lockfile as an artifact.
* feat(bazelisk): add lockfile maintenance support
* docs(bazelisk): add lockfile support section linking to bazel-module docs
* refactor(bazel-module): extract shared lockfile update helper
* refactor(bazel-module): delegate lockfile update to shared helper
Replace inline lockfile update logic in artifacts.ts with a call to the
shared updateBazelLockfile() helper, and update tests to mock the helper.
* refactor(bazelisk): delegate lockfile update to shared helper
Replace inline lockfile update logic in bazelisk/artifacts.ts with a
call to the shared updateBazelLockfile() helper from bazel-module/lockfile.ts.
* fix(bazelisk): use index.md for cross-manager docs link
The docs pipeline renames readme.md to index.md, so cross-manager
links must reference index.md to pass the docs link checker.
* feat(bazel-module,bazelisk): support bazelisk version constraint
Pass config.constraints.bazelisk through to toolConstraints so users
can pin the bazelisk version if the newest release is broken.
* fix(bazel-module): rename lockFile to fileName in ArtifactError
Upstream renamed lockFile to fileName in ArtifactError type (#41631).
---------
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
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`
As we've had a few Discussions about it (bugs and feature requests), and
it'd be good to clarify how they work together, as well as future work
planned to integrate better.
* docs/41127-parents-may-want-to-split-over-multiples-lines
* refactor(docs): sort parents alphabetically in table and add unit tests
* refactor(docs): table - use expect instead of assert
* refacto(docs) : remove unnecessary vitest import
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
* refactor(docs): table - rename index so there are rowIndex and colIndex
* refactor(docs): rename config.test.ts to utils.test.ts
---------
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
* 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>
Sergei Zharinov