* poetry manager respects primary source
* Retain backward poetry version compatibility
* Add test that asserts PyPI is inserted before supplemental sources
* Centralize PoetrySources logic in schema
test(manager/github-actions): update pinned version of `gh-actions-lock` via Renovate
So we can get dependency updates for the extension, without needing
manual code changes.
* test(manager/github-actions): cover digest pinned `renovate-image`
As noted in #46969, if `renovatebot/github-action`'s `renovate-image`
was tag+digest pinned, we would not correctly generate an update for it.
We can add test coverage for this scenario first, documenting the
current (incorrect) behaviour, so we have a clear regression test for
the fix in the next commit.
Co-Authored-By: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* fix(manager/github-actions): handle digest pinned `renovate-image`
Previously we split on `@` which would result in `packageName:
ghcr.io/renovatebot/renovate:44.104.2`, which was incorrectly extracted,
and so if no `renovate-version` was set, this would lead to `skipReason:
'unspecified-version'`.
We can instead reuse `splitImageParts`, already used for
Dockerfile-style `image:tag@digest` parsing, so a tag embedded in
`renovate-image` is extracted correctly. Its own tag takes priority over
the separate `renovate-version` input when both are set, matching how
the action itself resolves the image to pull.
Co-Authored-By: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* feat(manager/apm): scope per-package tags to their own package
APM packages are often published from monorepos that tag each package
separately (`foo--v1.2.0`, `bar--v3.0.0`). A dependency pinned to such a tag
was looked up against every tag in the repository under the default
versioning, which reads any prefixed tag as unstable, because `isStable` only
accepts values starting with `v` or a digit. Two wrong outcomes follow from
that, depending on what else the repository is tagged with:
- Only per-package tags: the unstable-current filter keeps only releases with
the same major.minor.patch, so nothing is proposed and the dependency looks
up to date.
- Per-package tags plus repository-wide ones: every stable `vX.Y.Z` passes
that filter, so `foo--v1.0.0` is proposed an update to the unrelated `v2.0.0`.
For a pinned tag of the form `<name>--v<version>`, `<name>-v<version>` or
`<name>_v<version>`, the forms `apm outdated` resolves, the extractor now sets
a `versionCompatibility` whose `compatibility` group is the package prefix.
Only tags with the same prefix are candidates, and the new value keeps it.
This covers SHA pins too, through the tag in their trailing comment.
The compatibility is only set when the pinned tag matches, since
`versionCompatibility` also filters the datasource's releases and would drop
every release of a dependency on repository-wide tags. Those keep their
existing behaviour.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RZk1J7hJZRCXMBEwByp5fu
* docs(manager/apm): keep the lockfile paragraph out of the monorepo section
The new heading sat above the existing lockfile paragraph, which then
read as part of "Per-package tags in monorepos". Move the section to the
end of the readme.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RZk1J7hJZRCXMBEwByp5fu
* refactor(manager/apm): apply review suggestions
Shorter comments, no readme section, and a looser per-package tag
pattern whose version part is anything starting with a digit.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RZk1J7hJZRCXMBEwByp5fu
* refactor(manager/apm): use a regex literal for per-package tags
Brings back the full x.y.z version part, so a ref like foo-v1 is
compared as-is again, and passes the pattern on through its source.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RZk1J7hJZRCXMBEwByp5fu
* refactor(manager/apm): drop the redundant -- alternative
The lazy .+?[-_] already captures foo-- for foo--v1.0.0. The SHA pin
test now also checks that the pin gets a versionCompatibility, so it
fails if the SHA branch stops scoping the tag.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RZk1J7hJZRCXMBEwByp5fu
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
* feat(manager/github-actions): extract `slsa-framework/actions/*`' `with`s
As there are a few `with` inputs that are dependency versions, we should
support extracting and updating them.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* fixup! feat(manager/github-actions): extract `slsa-framework/actions/*`' `with`s
---------
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* feat(datasource/crate): use host rule credentials for git index registries
Co-Authored-By: Claude Opus 5.5 <michael.kriese+claude-code@mend.io>
* test(datasource/crate): cover host rule authentication for the crates.io git index
Co-Authored-By: Claude Opus 5.5 <michael.kriese+claude-code@mend.io>
* test(datasource/crate): state that the crates.io git index needs no allowCustomCrateGitRegistries
Co-Authored-By: Claude Opus 5.5 <michael.kriese+claude-code@mend.io>
* test(datasource/crate): drop the git auth helper assertion
Co-Authored-By: Claude Opus 5.5 <michael.kriese+claude-code@mend.io>
* test(datasource/crate): name the git authentication tests after what they assert
Co-Authored-By: Claude Opus 5.5 <michael.kriese+claude-code@mend.io>
* feat(manager/cargo): accept crate host rules for git auth in artifact updates
Co-Authored-By: Claude Opus 5.5 <michael.kriese+claude-code@mend.io>
---------
Co-authored-by: Claude Opus 5.5 <michael.kriese+claude-code@mend.io>
* refactor(manager/gradle): add helper for matching `group:artifact` strings
As part of follow-up changes, we'll extract dependencies whose version
is declared separately from their coordinates, so we need a way to
validate a bare `group:artifact` notation. `isDependencyString` can't
be used, as it requires a version to be present.
This isn't currently used.
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
* feat(manager/gradle): support rich version constraints in the Groovy/Kotlin DSL
As noted in discussion #45481, Renovate doesn't extract dependencies
whose version comes from a Gradle rich version constraint[0], so a
`strictly` pin never receives updates - not even for a security fix:
```groovy
dependencies {
implementation('org.slf4j:slf4j-api') {
version {
strictly '[1.7, 1.8['
}
}
}
```
The version catalog extractor already handles rich versions, so the
missing piece is the `version { ... }` block in the Groovy and Kotlin
DSLs.
Renovate can only rewrite a single version literal per dependency, so
we pick one constraint to update and record which one in
`managerData.versionConstraint`:
- `strictly` -> bump `strictly`
- `strictly` (single version) + `prefer` -> bump `strictly`, as `prefer`
is inert when there's nothing to choose between
- `require`, optionally with `prefer` -> bump `require`, as `prefer` is
only a hint and may not be what gets resolved
- `prefer` alone -> bump `prefer`
- `require` + `strictly` -> skip as `multiple-constraint-dep`, as Gradle
applies `require()` before `strictly()`, so bumping only `strictly`
would leave the `require` literal behind as stale text
- `strictly` range + `prefer` -> skip as `multiple-constraint-dep`, as
`prefer` has to keep pointing inside the range and we can't move both
- anything with `reject`/`rejectAll` -> skip as `unsupported-version`,
matching what the version catalog extractor already does
As `strictly` and `prefer` pin a version on purpose, updating them by
default would be surprising, so those deps are extracted with
`enabled: false` - meaning they only receive updates for vulnerability
alerts, which force through. Users who want regular updates can opt in
with a package rule matching `managerData.versionConstraint`, similar to
how `manager/gomod` handles `depType: indirect`. A `require` constraint
means the same thing as a plain version declaration, so it is updated
like any other dependency.
This doesn't unify behaviour with version catalogs, which extract a
single `require`/`prefer`/`strictly` and update it without disabling it.
Aligning them would take away updates users get today, so that's left as
a separate decision.
The `!!` shorthand (i.e. `foo:bar:1.7.25!!`) is untouched - it already
extracts as an opaque version string. Rich versions declared in the
Groovy/Kotlin `versionCatalogs { }` builder, as opposed to TOML, are
still dropped silently.
[0]: https://docs.gradle.org/current/userguide/dependency_versions.html#sec:rich-version-constraints
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
* fix(vulnerabilities): raise fixes for deps their manager disables by default
* test(workers/fetch): set packageName on disabled-dep fixtures
* test(manager/gradle): assert enabled is not set
---------
Co-authored-by: Jamie Tanna <jamie.tanna@mend.io>
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
* feat(npm): extract devEngines.runtime and devEngines.packageManager
Adds extraction for the npm devEngines field
(https://docs.npmjs.com/cli/v11/configuring-npm/package-json#devengines)
covering both single-object and array forms. Uses dot-notated depTypes
("devEngines.runtime", "devEngines.packageManager") consistent with
"pnpm.overrides", and reuses the existing engines/packageManager
datasource resolution. Items without a version are skipped.
Refs #38067.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* feat(npm): update devEngines.runtime and devEngines.packageManager versions
Adds an update path for the new devEngines depTypes. Handles both the
single-object form and the array form (the array element is identified
via managerData.devEnginesIndex set at extraction time). Uses the same
anchored search-and-verify approach as the existing replaceAsString
(indexOf("devEngines") + dequal check), so unrelated occurrences of the
same version string elsewhere in the file are not touched.
Refs #38067.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(npm): skip lockedVersion and apply @yarnpkg/cli for devEngines deps
Extends the locked-versions post-extract step to cover the new
devEngines depTypes:
- devEngines.runtime and devEngines.packageManager are added to the
npm-lock skip list (mirrors the engines/packageManager/volta handling
added in #38598)
- devEngines.packageManager with depName "yarn" gets the @yarnpkg/cli
packageName fallback when the project is on Yarn 2+, matching the
existing behavior for engines / packageManager
Refs #38067.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(npm): harden devEngines handling against malformed input
- Register devEngines.runtime and devEngines.packageManager in
knownDepTypes (matches the existing pnpm.overrides pattern)
- Guard against null/non-object array elements in devEngines.* during
extraction so malformed JSON does not throw
- Use JSON.stringify when interpolating versions into the source search
string, so any future versions containing JSON-escaped characters are
matched correctly
- Add an extraction test for a mixed array containing a null item, a
valid entry, and a version-less entry
Refs #38067.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(npm): set hasPackageManager when devEngines.packageManager is an array
The previous hasPackageManager check used isNonEmptyObject which returns
false for arrays. Now that the array form of devEngines.packageManager
is actually extractable and updatable, the corepack post-update step
needs to be triggered for those users as well. Introduces a shared
hasDevEnginesPackageManager helper and uses it from both
extractPackageJson and extractPackageFile.
Refs #38067.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(npm): require at least one non-empty array item for hasPackageManager
Align the array branch of hasDevEnginesPackageManager with the
single-object branch by requiring at least one non-empty object item.
Previously, an array containing only null/empty entries would set
hasPackageManager to true and trigger corepack post-update even though
no usable item exists. Add coverage for the empty-array and
only-invalid-items cases.
Refs #38067.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* test(npm): document hasPackageManager semantics for stray-key array items
Make the chosen semantic explicit: an array element with arbitrary keys
but no `name` (e.g. `[{ foo: 'bar' }]`) still sets hasPackageManager to
true, mirroring the pre-existing single-object behavior. The extract
step independently filters out items lacking `name`/`version`.
Refs #38067.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* test(npm): cover dequal rejection in devEngines array update
Adds a test where two devEngines.packageManager array items share the
same version string. The first source-level match belongs to the wrong
index, so the dequal verification rejects it and the loop continues to
the correct occurrence. This exercises the false branch of the dequal
check in updateDevEnginesDependency.
Refs #38067.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* docs(node): list devEngines.runtime as a supported field for Node.js
The npm manager now updates the version inside devEngines.runtime in
package.json, so include it in the file-support list alongside engines
and volta.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Apply the comment changes suggested in the code review
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
* test(npm): cover devEngines update error path instead of ignoring it
Remove the v8 ignore on the updateDevEnginesDependency catch and add a
test that reaches it with invalid JSON, matching how the main
updateDependency catch is covered.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix(npm): drop unnecessary spread fallback in devEngines managerData
Object spread ignores null/undefined, so the `?? {}` fallback is
redundant. Removing it satisfies the oxlint no-unnecessary-spread-fallback
rule that now runs in CI.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* refactor(npm): type devEnginesIndex on NpmManagerData
Declare devEnginesIndex on NpmManagerData so the value no longer needs a
`as number | undefined` cast when reading it back during update.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* docs(node): document package manager version fields
List packageManager and devEngines.packageManager separately from the Node.js runtime file support entries.
Co-authored-by: Codex <noreply@openai.com>
* feat(npm): support Bun and Deno devEngines runtimes
* fix(npm): preserve Corepack hashes in devEngines
* test(npm): use partial helper for devEngines fixture
Co-authored-by: Codex <noreply@openai.com>
* fix(npm): warn on invalid devEngines update state
Co-authored-by: Codex <noreply@openai.com>
* fix(npm): include devEngines in extracted tool constraints
Co-authored-by: Codex <noreply@openai.com>
* fix(npm): prefer devEngines over volta for package manager versions
Co-authored-by: Codex <noreply@openai.com>
* fix(npm): update Yarn binaries for devEngines package manager upgrades
Co-authored-by: Codex <noreply@openai.com>
* fix(npm): recognize devEngines package managers for Yarn catalogs
Co-authored-by: Codex <noreply@openai.com>
* fix(npm): exclude devEngines from Yarn locked versions
Co-authored-by: Codex <noreply@openai.com>
* refactor(npm): reuse Bun extraction for devEngines runtime
Co-authored-by: Codex <noreply@openai.com>
* test(npm): cover Yarn devEngines manifest preservation and grouped updates
Co-authored-by: Codex <noreply@openai.com>
* refactor(npm): pass packageJsonResult directly to hasDevEnginesPackageManager
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
* test(npm): simplify malformed devEngines fixture
Co-authored-by: Codex <noreply@openai.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Codex <noreply@openai.com>
Similar to changes in d8705054b0, we
should make sure that when there is an annotated Git tag (on GitHub) we
use the tag's `tagger.date` by using the `queryTags()`, and then using
the latest date, instead of relying on the GO module proxy's `Time`
field.
We can use an example from `github.com/kr/pretty@v0.3.1`, whose tag was
created some weeks after the commit it points to.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* feat(manager/mise): support remote `include` entries
* feat(manager/mise): support digest pinning of `include` refs via comment hints
* feat(manager/mise): support git references of remote task files
* fix(manager/mise): use gitlab-tags for gitlab.com references
* refactor(manager/mise): only support `# <version>` and `# <branch>` hints
* refactor(manager/mise): parse git references with parseGitUrl
* feat(manager/mise): support http and Azure DevOps ssh git references
* refactor(manager/mise): separate remote reference datasources from backends
* docs(manager/mise): add tag ref example for remote includes
As we're now managing them via a `afterEach` in `test/setup.ts`, we can
remove any entries in tests themselves.
We don't update overrides of an outer hook or cases where there are more
explicit `clear()`s.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* fix(manager/mise): commit native dependency sidecars with the lock file
`mise lock` pins npm and Python tool dependencies in sidecar lock files
under `.mise/locks/` and records each sidecar's path and digest in
`mise.lock`. Only `mise.lock` was returned as an artifact, so a version
change committed a lock file pointing at a sidecar directory that was
never added, and `mise install --locked` failed.
Return the sidecar files that `mise lock` modified, created or deleted,
using the same sidecar location rules as mise.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* test(manager/mise): cover local lock files in getSidecarDir
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* refactor(manager/helmv3): share generateHelmEnvs with kustomize
Move kustomize's generateHelmEnvs into helmv3/common.ts and delete the
kustomize copy. The merged function always sets the three HELM_*
path variables and sets HELM_EXPERIMENTAL_OCI unless a helm
constraint is present and proves helm >= 3.8 (which ignores the
variable).
Behaviour change: kustomize now sets HELM_EXPERIMENTAL_OCI when the
helm constraint is unknown (previously it only set it for a known
constraint below 3.8). helmv3 and helmfile now omit the variable
once a resolved helm constraint proves helm >= 3.8.
* refactor(manager/helmv3): share OCI registry login helper with helmfile
Extract a shared generateRegistryLoginCmd(name, registry) helper in
helmv3/common.ts that strips the oci:// prefix, derives the host and
looks up the matching host rule before delegating to generateLoginCmd.
helmv3/artifacts.ts and helmfile/artifacts.ts now both call this
helper instead of each building a RepositoryRule inline, removing the
stale oci:// TODO. helmfile/utils.ts loses its duplicate
generateRegistryLoginCmd, and its unrelated isOCIRegistry(repository)
(checking the oci flag) is renamed to isOciRepositoryFlagSet so it no
longer collides in name with helmv3/oci.ts's prefix-based
isOCIRegistry(string), which helmfile/extract.ts also imports.
Addresses audit finding M8. Generated `helm registry login` commands
are unchanged, proved by the existing artifacts specs passing with
their original expectations untouched.
* fix(manager): share one local Helm chart path check
helmfile, flux, fleet and terraform each decided differently whether a Helm chart reference points at a local path. fleet and terraform used terraform's checkIfStringIsPath, whose regex was unanchored with unescaped dots, so it matched any string containing a slash followed by a non-slash character.
Add isLocalChartPath to helmv3/utils.ts with helmfile's prefix check and use it in all four managers. This drops the fleet to terraform dependency and removes checkIfStringIsPath, which had no other users.
* refactor(manager/helm-requirements): reuse helmv3 alias and repository helpers
Replace the duplicated alias-resolution and repository-classification logic in helm-requirements/extract.ts with the shared isAlias, resolveAlias and parseRepository helpers from helmv3/utils.ts (audit finding M9). Behaviour is unchanged: same skipReasons, same registryUrls, same handling of a missing repository or missing registryAliases config.
* refactor(manager/dockerfile): add an options form of getDep for CI managers
`getDep()` gains an overload taking a `GetDepOptions` object with
`specifyReplaceString`, `registryAliases` and `depType`, replacing the
opaque boolean second positional argument at the CI manager call sites.
The positional form keeps working for all other callers.
Migrated: bitbucket-pipelines, droneci, circleci, github-actions,
azure-pipelines and woodpecker.
Behaviour changes:
- azure-pipelines container resources now honour `registryAliases`, which
`extractContainer()` previously ignored
- woodpecker dependencies now carry `depType: 'docker'`, matching the
other CI managers
* refactor(manager/woodpecker): do not set depType on docker image deps
* refactor(manager/dockerfile): drop the positional getDep signature
* refactor(manager/helm-requirements): reuse helmv3 alias and repository helpers
Replace the duplicated alias-resolution and repository-classification logic in helm-requirements/extract.ts with the shared isAlias, resolveAlias and parseRepository helpers from helmv3/utils.ts (audit finding M9). Behaviour is unchanged: same skipReasons, same registryUrls, same handling of a missing repository or missing registryAliases config.
* refactor(workers): assemble the per-dependency lookup config in one place
The extracted constraints were merged with the same spread twice in
`fetch.ts`, once per package file and once per dependency, and
`constraintsVersioning` only at the package file level. Both levels now go
through `mergeExtractedConstraints()`, and `PackageDependency` gained the
`constraintsVersioning` which only `PackageFileContent` had.
The datasource `defaultConfig` was applied in `fetch.ts` before the lookup and
again in `flatten.ts` afterwards, because `Object.assign(dep, upd)` only copies
the `UpdateResult` fields back onto the dependency. Both call
`applyDatasourceDefaultConfig()` now. Persisting the merged defaults on the
dependency instead would have moved them into another precedence layer of
`flatten.ts`, which merges them over the update config, so the defaults keep
being applied twice.
Behaviour change: a `constraintsVersioning` set on a dependency by a manager is
now honoured, below the package file and the repository config. No manager sets
it yet.
* refactor(workers): normalise depName and packageName once after extraction
`massageDepNames()` only copied `packageName` into a missing `depName`, so the
opposite fallback was applied again in `fetch()` and re-derived at seven worker
call sites.
Extraction now normalises both directions once, via an exported
`normalizeDepNames()`, which also takes over the `depName` trimming that
`fetch()` used to do. Every consumer downstream of extraction reads the field it
wants directly: `fetch()`, the dependency dashboard, the auto-replace deps
signature, the attestation PR note, the commit body table, the OSV lookup and
the rollback PR note.
Both places which re-extract a package file outside the extract phase -
`checkBranchDepsMatchBaseDeps()` and `checkForPendingVersions()` - call
`normalizeDepNames()` on the freshly parsed deps first, so their names stay
comparable with the deps that went through extraction.
In-manager fallbacks are left alone: they run before extraction normalises the
names.
No behaviour change.
* Apply suggestion from @secustor
* refactor(workers): assemble the per-dependency lookup config in one place
The extracted constraints were merged with the same spread twice in
`fetch.ts`, once per package file and once per dependency, and
`constraintsVersioning` only at the package file level. Both levels now go
through `mergeExtractedConstraints()`, and `PackageDependency` gained the
`constraintsVersioning` which only `PackageFileContent` had.
The datasource `defaultConfig` was applied in `fetch.ts` before the lookup and
again in `flatten.ts` afterwards, because `Object.assign(dep, upd)` only copies
the `UpdateResult` fields back onto the dependency. Both call
`applyDatasourceDefaultConfig()` now. Persisting the merged defaults on the
dependency instead would have moved them into another precedence layer of
`flatten.ts`, which merges them over the update config, so the defaults keep
being applied twice.
Behaviour change: a `constraintsVersioning` set on a dependency by a manager is
now honoured, below the package file and the repository config. No manager sets
it yet.
* refactor(config): move applyDatasourceDefaultConfig next to getManagerConfig
Importing config/utils from the datasource module made tools/generate-imports.mjs load config options before manager-default-configs.generated.ts exists, breaking install in CI.
* test(manager/gomod): normalise dep names before running the lookup
* test(manager/gomod): explain why dep names are normalised
* test(workers): give the jsonata base dep a packageName like extraction does
* refactor(workers): assemble the per-dependency lookup config in one place
The extracted constraints were merged with the same spread twice in
`fetch.ts`, once per package file and once per dependency, and
`constraintsVersioning` only at the package file level. Both levels now go
through `mergeExtractedConstraints()`, and `PackageDependency` gained the
`constraintsVersioning` which only `PackageFileContent` had.
The datasource `defaultConfig` was applied in `fetch.ts` before the lookup and
again in `flatten.ts` afterwards, because `Object.assign(dep, upd)` only copies
the `UpdateResult` fields back onto the dependency. Both call
`applyDatasourceDefaultConfig()` now. Persisting the merged defaults on the
dependency instead would have moved them into another precedence layer of
`flatten.ts`, which merges them over the update config, so the defaults keep
being applied twice.
Behaviour change: a `constraintsVersioning` set on a dependency by a manager is
now honoured, below the package file and the repository config. No manager sets
it yet.
* refactor(config): move applyDatasourceDefaultConfig next to getManagerConfig
Importing config/utils from the datasource module made tools/generate-imports.mjs load config options before manager-default-configs.generated.ts exists, breaking install in CI.
* Apply suggestion from @secustor
* refactor(config): drop any from applyDatasourceDefaultConfig
* refactor(workers/lookup): move the gomod pseudo-version check into the go datasource
The only manager-name check in `lookupUpdates()` relabelled an update between
two Go pseudo-versions as a `digest` update (#29034). Knowing that
`v0.0.0-<timestamp>-<commit>` identifies a commit rather than a release belongs
to the Go ecosystem, so `DatasourceApi` gains an optional `isPseudoVersion()`,
`GoDatasource` implements it, and the lookup asks the datasource instead of the
manager. The gomod manager's own `v0.0.0-` check calls the same helper.
Behaviour change: the relabelling is keyed on the `go` datasource instead of the
`gomod` manager, so it now also applies to the other managers using that
datasource (bazel, mise, ocb), and no longer applies to a `gomod` dependency
whose datasource was overridden to something else. The recognised
pseudo-version form is unchanged: only the `v0.0.0-` prefix, not every form
matched by `GoDatasource.pversionRegexp`.
* refactor(workers/lookup): ask the go-mod-directive versioning about pseudo-versions
Review feedback: version predicates are the domain of `lib/modules/versioning`,
not of the datasource API. `isPseudoVersion()` now lives in the
`go-mod-directive` versioning (the Go versioning module) and the optional
`DatasourceApi.isPseudoVersion?()` hook is gone. The lookup worker and the gomod
manager import the versioning helper directly.
Because the lookup no longer asks the datasource, the predicate has to be exact:
it matches the anchored `v0.0.0-<timestamp>-<commit>` shape (with the optional
pre-release segment `GoDatasource.pversionRegexp` also allows) instead of the
`v0.0.0-` prefix, so that no manager or datasource gating is needed. The forms
derived from tags (`v1.2.3-0.…`) stay unrecognised, as before.
* refactor(workers/lookup): keep the pseudo-version relabelling limited to gomod
Review feedback: the move of the predicate into the versioning module should
not widen which dependencies get relabelled. The `config.manager === 'gomod'`
condition is back in front of the `isPseudoVersion()` checks, so the lookup
behaves as on main.
* refactor(workers/lookup): ask the gomod versioning about pseudo-versions
Review feedback: the pseudo-version predicate has nothing to do with the `go`
directive, so it moves from `go-mod-directive` to the new `gomod` versioning,
which is the home for Go module version helpers (#44184).
The lookup worker and `gomod/update.ts` use its `isUntaggedPseudoVersion()`,
which is `isPseudoVersion()` limited to `v0.0.0-` pseudo-versions, so which
dependencies are relabelled or written directly stays as on main.
`go-mod-directive` is unchanged against main again.
* fix(workers/lookup): treat pseudo-versions of major version modules like v0 ones
Review feedback: Go writes a pseudo-version without a base release as
`vX.0.0-<time>-<commit>`, with the major version of the module path, so a
`/v2` module without releases gets `v2.0.0-…`. Only `v0.0.0-` was
recognised, so an update between two such pseudo-versions was not relabelled
as a digest update (#29034), and gomod/update.ts wrote the bare commit
instead of the new pseudo-version.
The lookup and the update now use `isPseudoVersion()` from the `gomod`
versioning, and `isUntaggedPseudoVersion()` is gone. The go datasource only
returns pseudo-versions for modules without releases, which always have that
form, so nothing else changes. The lookup keeps its `config.manager ===
'gomod'` condition.
* refactor(workers/lookup): drop the guards around isPseudoVersion()
Review feedback: `isPseudoVersion()` now accepts an undefined version, so
the lookup and gomod/update.ts pass their optional values to it directly.
Go writes a placeholder pseudo-version for a module whose `replace`
directive points to a local path, with the major version of the module
path, such as `v2.0.0-00010101000000-000000000000` for a `/v2` module.
#41521 only skipped `v0.0.0-00010101000000-000000000000`, so Renovate
still looked up replaced `/v2` modules and proposed updates for them, such
as `v2.8.0` for oapi-codegen's `examples/go.mod`.
Any `vX.Y.Z-00010101000000-000000000000` is now skipped.
refactor(manager/helm-requirements): reuse helmv3 alias and repository helpers
Replace the duplicated alias-resolution and repository-classification logic in helm-requirements/extract.ts with the shared isAlias, resolveAlias and parseRepository helpers from helmv3/utils.ts (audit finding M9). Behaviour is unchanged: same skipReasons, same registryUrls, same handling of a missing repository or missing registryAliases config.
As noted in #46343, upstream mise renamed a large number of `pipx`
registry entries to use the `pypi` backend instead, e.g. `ansible`
went from `pipx:ansible` to `pypi:ansible`.
This was caught during code review, but we should add something to
automagically catch this, by making sure that none of the backends in
use on an updated `mise registry` is unknown to Renovate.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
As we have a `conda` Datasource, we should support the `conda` backend
in mise.
This appears to have been missed from earlier implementations in the
mise manager.
(cherry picked from commit 8fa353f04ae1fe30d05eee0df60d0ca4749fdc1c)
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* feat(datasource): add GraalVM version datasource with support for JDK and JRE releases
* feat(datasource): add GraalVM version datasource with support for JDK and JRE releases
* feat(datasource): add GraalVM version datasource with support for JDK and JRE releases
* feat(datasource): add GraalVM version datasource with support for JDK and JRE releases
* feat(datasource): add GraalVM version datasource with support for JDK and JRE releases
* add coverage
* fix
* fix
* fix
* code cov
* code cov
* code cov
* refactor(datasource): integrate GraalVM into java-version datasource
Merges graalvm-version datasource into java-version as a unified multi-vendor
Java distribution datasource. Implements vendor-based modular architecture with
routing layer for Adoptium (Eclipse Temurin) and Oracle GraalVM.
Architecture:
- Vendor-specific handlers (adoptium.ts, graalvm.ts) with routing in index.ts
- Vendor-aware system detection with different arch/os mappings per vendor
- Custom registry support for GraalVM's mise-java API
- Adoptium remains the default registry for backwards compatibility
Package names:
- New explicit: adoptium-jdk, adoptium-jre, oracle-graalvm-jdk, oracle-graalvm-jre
- Legacy (map to Adoptium): java, java-jdk, java-jre
Changes:
- Created adoptium.ts and graalvm.ts vendor handlers
- Enhanced common.ts with vendor detection and vendor-specific system mappings
- Updated index.ts with routing layer and custom registry support
- Merged test suites with comprehensive coverage for both vendors
- Updated mise manager integration to use JavaVersionDatasource
- Removed graalvm-version datasource directory
All 65 datasource tests and 93 mise manager tests passing.
* fix
* test(datasource): add coverage for non-HttpError paths in java-version
* fix(datasource): remove dead code and add coverage for java-version
Remove unreachable HttpError handling from _getReleases catch block
since both getAdoptiumReleases and getGraalvmReleases handle HttpError
internally. Add test for the graalvmRegistryUrl fallback when
registryUrl is undefined.
* fix(datasource): address review comments for GraalVM datasource
- Remove unused 'datasource-graalvm-version' cache namespace
- Convert MiseJavaRelease interface to Zod schema and derive type from it
- Use http.getJson() with the Zod schema in getGraalvmReleases instead
of getJsonUnchecked, letting the schema handle invalid/empty responses
- Update getGraalvmReleases test mock to use getJson
* docs: remove unused datasource-graalvm-version from cacheTtlOverride docs
* fix(datasource): preserve Adoptium config typing
* fix(datasource): harden GraalVM release parsing
* fix(datasource): address GraalVM review feedback
* test: cover GraalVM mise package mapping
* test(datasource): cover default GraalVM registry fallback
* test(datasource): cover legacy registry resolution
* test(datasource): type legacy datasource mocks
* fix(datasource): harden GraalVM defaults and responses
* refactor(datasource): use function-only registry accessors
* test(datasource): cover registry accessor functions
* test: restore coverage exclusions
* chore: retrigger CI checks
Sebastian Poxhofer