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.
* feat(datasource/github-runners): add `releaseTimestamp`s
As per #46806, we can retrospectively add the relevant
`releaseTimestamp`s for the `github-runners` Datasource.
Claude Sonnet has cross-referenced this with announcements [0] with
rough measures from the Git history, and seems confident.
We can also add a test to make sure that all known release channels have
a `releaseTimestamp`, to aid future contributions.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
[0]: https://github.blog/changelog/label/actions/
* fixup! feat(datasource/github-runners): add `releaseTimestamp`s
Co-authored-by: RahulGautamSingh <rahultesnik@gmail.com>
---------
Co-authored-by: RahulGautamSingh <rahultesnik@gmail.com>
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>
* refactor(datasource): expose the source URL of the git host tags datasources
getSourceUrl() becomes a public instance method of every git host tags datasource. github-tags and gitlab-tags gain it next to a static getSourceUrl(), and the Gitea base derives it from its default registry.
* refactor(datasource/gitea-tags): extend GitHostTagsDigestDatasource
The Gitea and Forgejo tags and releases datasources keep their cache keys and only cache lookups against the public instance, through a new isCacheable() hook of the base class. The cache key of a releases lookup now ends in ':tags' like every other one, in its own namespace.
* refactor(datasource/gitlab-tags): extend GitHostTagsDigestDatasource
The tags, digests and tag commits are cached under the '<registryUrl>:<repo>:<type>' keys of the base class, so the first lookup after the upgrade misses the package cache.
* refactor(datasource/github-tags): extend GitHostTagsDigestDatasource
getReleases() and getDigest() skip the package cache of the base class, because the GraphQL fetcher already caches the tags with their commits and the HTTP client caches the latest commit in memory. The releases now carry their registryUrl like the other tags datasources.
* fix(datasource): only cache git host tags lookups known to be public
A tags lookup may read a private repository, so GitHostTagsDatasource no longer writes it to the package cache by default. Gitea and Forgejo keep caching their public instance; Bitbucket Cloud, Bitbucket Data Center, Azure DevOps and GitLab lookups are cached only with cachePrivatePackages. The Bitbucket main branch cache follows the same rule.
* test(datasource): cover the default registry of github-tags and gitlab-tags
* docs(datasource/github-tags): drop the cache note from getDigest
* refactor(datasource): keep caching git host tags lookups by default
* refactor(datasource): keep getSourceUrl of the git host tags datasources protected
* refactor(datasource): default getRegistryUrl and resolve the URL for isCacheable
* fix(datasource/gitlab-tags): normalise the registry URL like main
* refactor(datasource): cache tag digests only once
* refactor(datasource/github-tags): skip the package cache through a base hook
* refactor(datasource): document getSourceUrl once in the base class
* refactor(datasource/bitbucket-tags): inline the static registry URL helper
* refactor(datasource): rename usePackageCache to useGitHostTagCaching
* refactor(datasource): drop isCacheableFor and useGitHostTagCaching
* feat(datasource/go): look up modules from a `go-import` `mod` proxy
When interacting with a Go module, a host can advertise that a module is
served by a Go module proxy, instead of a Version Control System (VCS),
by noting the following in the `go-import` HTML meta tag:
<meta name="go-import" content="bsr.example.com/gen/go mod https://bsr.example.com/gen/go">
Previously, we only handled the `git` protocol, which would lead to
users integrating with a (private) Buf Schema Registry (BSR) not being
able to download generated Go modules.
When interacting with public Go modules on `buf.build`, these are served
successfully through `proxy.golang.org`, but a private BSR can't be
routed through the public proxy, and therefore fail to be looked up.
We should instead follow how `go` does it[0] and add support for
directly calling a `mod` proxy.
We leverage `getDirectReleases()`s' checks to make sure we don't
try and follow this flow when we're on a "known" host, i.e. if we're
pulling a module called `github.com/...` or a vanity domain package name
that resolves to `gitlab.com`.
The `?go-get=1` will keep the in-memory HTTP cache's result.
[0]: https://go.dev/ref/mod#serving-from-proxy
Co-Authored-By: Claude Opus 5.5 <jamie.tanna+claude-code@mend.io>
* fixup! feat(datasource/go): look up modules from a `go-import` `mod` proxy
fixup! feat(datasource/go): look up modules from a `go-import` `mod` proxy
Co-Authored-By: Claude Sonnet 5.5 <jamie.tanna+claude-code@mend.io>
* fixup! feat(datasource/go): look up modules from a `go-import` `mod` proxy
* fixup! feat(datasource/go): look up modules from a `go-import` `mod` proxy
---------
Co-authored-by: Claude Opus 5.5 <jamie.tanna+claude-code@mend.io>
* 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.
* fix(prune): refresh PR state before autoclosing
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* refactor(platform): align getPr refresh param with bitbucket-server
Signed-off-by: Adam Setch <adam.setch@outlook.com>
---------
Signed-off-by: Adam Setch <adam.setch@outlook.com>
When determining whether a Go module is public - which infers whether to
cache it - we had previously miscategorised authenticated traffic to Go
module proxies, as we only looked for `GOPROXY`, `GONOPROXY` and
`GOPRIVATE`.
Instead, we should treat a package as private if there is an
authenticated Host Rule that matches the Go module.
We can do this by checking for `hostType: go`, to catch only Go module
specific authentication, and to avoid catching i.e. auth to
`github.com`.
If any credentials (`token`, `password` or `httpsPrivateKey`) are found,
we treat this as credentialed.
Co-authored-by: Claude Opus 5.5 <jamie.tanna+claude-code@mend.io>
* fix(http): share concurrent identical cache provider requests
Identical requests that use a cache provider and run at the same time now
share one in-flight request instead of each fetching from the server.
Callers that join an in-flight request get a deep copy of the response.
This replaces the per-URL mutex, which only covered the cache check and
was released before the fetch finished.
Co-Authored-By: Claude Opus 5.5 <michael.kriese+claude-code@mend.io>
* fix(http): reuse cache providers for npm and typst lookups
The npm and typst datasources now use one module-level cache provider, so
concurrent lookups of the same package share one request. The request key
is only hashed for GET and HEAD requests and includes `throwHttpErrors`.
Co-Authored-By: Claude Opus 5.5 <michael.kriese+claude-code@mend.io>
Co-Authored-By: Claude Sonnet 5.5 <michael.kriese+claude-code@mend.io>
* fix(http): don't share requests that differ in response type
Add `responseType` and `responseBecomesConfig` to the key of shared
requests, and test that requests with different headers aren't shared
and that a shared response is copied for every caller.
Co-Authored-By: Claude Opus 5.5 <michael.kriese+claude-code@mend.io>
Co-Authored-By: Claude Sonnet 5.5 <michael.kriese+claude-code@mend.io>
* fix(http): keep in-flight requests per Http class and copy binary bodies
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>
A 404 from the tag or commit request in the digest lookup was thrown as
an HTTP error and failed the whole dependency lookup. Return `null`
instead, as gitlab-tags does, so only the digest is missing. This also
applies to the Forgejo datasources, which share this implementation.
Co-authored-by: Claude Opus 5.5 <michael.kriese+claude-code@mend.io>
* 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>
* fix(github): rendered md alerts
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* fix(github): rendered md alerts
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* fix(github): rendered md alerts
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* refactor(pr): use `codeBlock` and address review feedback
- Use `codeBlock` template helper for Caution/Important PR body notes
- Drop the all-platform truncation notice text change (moved to separate PR)
- Remove GitHub truncation-notice test depending on the extracted change
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* remove extra space
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* fix(github): tolerate blockquote blank line whitespace in alert conversion
The emoji callout to GitHub alert syntax conversion relied on the blank
blockquote line being exactly '> ' (trailing space). Linters/CI strip
trailing whitespace from the emitted notes, so also accept '>' without
a trailing space.
* fix(dashboard): render abandoned-dependencies note as a GitHub alert
The '[!NOTE]' callout inside the abandoned-dependencies <details> block
never rendered: GitHub alerts only render at the top level of a body, not
inside collapsible sections, and the description text sat outside the
blockquote (no '> ' prefix), leaving the alert empty.
Move the note outside (above) the <details> block and keep the
description inside the blockquote with '> ' prefixes.
* Revert "fix(dashboard): render abandoned-dependencies note as a GitHub alert"
This reverts commit 55a5d9490e.
* incorporate feedback
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* update test case per feedback
Signed-off-by: Adam Setch <adam.setch@outlook.com>
---------
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* 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>
The PR list endpoint returns descriptions truncated to 400 characters, so
the body hash of every PR with a longer description never matched and
Renovate updated those PRs on every run. Read the full description with
`getPullRequestById` in `getPr` and compute the body struct from it.
Co-authored-by: Claude Opus 5.5 <michael.kriese+claude-code@mend.io>
renovate[bot]