As part of changes towards #46438, it was noticed that there wasn't
coverage for the ability to specify `constraints` inside `packageRules`.
Co-authored-by: Claude Opus 5.5 <jamie.tanna+claude-code@mend.io>
* fix(manager/gomod): allow modules with an older `go` directive
As noted in #47313, when using `constraintsFiltering=strict`, any Go
modules which declare a `go` directive on an /older/ minor version than
the repository's are filtered out, even though they would not require
bumping the repository's `go` directive.
This seems to have been documented as the intent in
0e5e384237 - hence the test added to note
the behaviour - but this leads to us not updating versions we should do.
We can instead convert it into the range `<=1.26.x`, which allows the
same or older minor versions, and continues to filter out newer ones,
which applies with the `semver-coerced` versioning scheme.
Co-authored-by: Claude Opus 5.5 <jamie.tanna+amp@mend.io>
* fixup! fix(manager/gomod): allow modules with an older `go` directive
---------
Co-authored-by: Claude Opus 5.5 <jamie.tanna+amp@mend.io>
As noted in #47292, since `gh actions-lock` v0.2.0 locked pins are
sticky: running `gh actions-lock` only resolves refs that the lockfile
doesn't record yet.
If a ref updates (i.e. `pnpm/setup@v3.0.0` to `pnpm/setup@v3.1.1`), then
`gh actions-lock` fails with a `Ref changed` error and `Unused lockfile
entry`, and writes nothing out, leaving the branch in an unusable state.
Per v0.2.0's release notes, we should use `--relock` to re-resolve every
ref and rebuilds the lockfile graph.
This updates floating tags i.e. `@v4` when occurring, because they are
technically a floating tag that has now updated.
Co-authored-by: Claude Sonnet 5.5 <jamie.tanna+claude-code@mend.io>
When a GitHub Actions Workflow digest pins against a repository that
tags releases with the `v` prefix, but the Workflow itself doesn't use
the `v` like:
uses: renovatebot/github-action@abd08c7549 # 46.1.5
we correctly match `46.1.5` to the release `v46.1.5` and propose an
update, but when we do a `digest` update (which confirms whether the
current digest SHA is still what the tag is pointing to) it uses
`46.1.5` as its `newValue`.
We look for a release with that version verbatim, and because it's
missing the `v` prefix, we'll perform a failed tag lookup:
DEBUG: github/tags.findCommitOfTag: Tag 46.1.5 not found for renovatebot/github-action
DEBUG: Could not determine new digest for update.
As we have a `currentDigest`, this also adds a warning for the
dependency, and we'll never be able to update if the underlying tag has
moved, because we can't look up the tag's SHA.
Although we could retry the lookup with the `v` prefix, we should
instead treat this as the misconfiguration it is, and surface it more
visibly to users with a WARN log.
If we did provide a retry, this could lead to a supply chain attack
where a repository maintainer could push both a `1.2.3` and `v1.2.3` and
convince Renovate to update to a malicious version.
Co-authored-by: Claude Sonnet 5.5 <jamie.tanna+claude-code@mend.io>
* feat(datasource/github-runners): add xcode-27
Add `xcode-27` and `xcode-27-xlarge` runner labels to the datasource.
* feat(datasource/github-runners): add release date
Add release date for the XCode 27 runners.
Set `depType: "HelmChart"` on charts from `HelmRelease` and `HelmChart`
resources, and on `OCIRepository` resources whose
`spec.layerSelector.mediaType` selects the Helm chart layer, matching the
`kustomize` and `vendir` managers.
Signed-off-by: Devin Buhl <devin@buhl.casa>
* 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>
renovate[bot]