When using `docker` versioning, we correctly treat a `v1.2` -> `v1.3`
version update as valid.
However, when using the previous implementation of `github-actions`'
versioning, we would silently ignore them, filtering them in
`filterValidVersions`.
This leads to cases where a `v1.2` would be upgraded to `v1.3.0`, which
wasn't correct.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* Take nuget.config into account for registryUrls of nuget packages
* Remove 'afterEach' in tests
* Fix PR remarks
* Remove 'any' as suggested in code review
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
* Update lib/modules/manager/cake/index.ts
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
* Verify mock parameters in cake manager tests
---------
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
GitHub Actions' versioning somewhat mirrors the SemVer-style versioning,
but doesn't quite.
This is in the case that it's common to use (mutable) tags like `v7` or
`v4.2`, as well as full SemVer style` `v1.2.3` and `v1.3.4-rc2`, doesn't
quite match it.
In addition, with GitHub's recent move to introduce Immutable Tags,
these require new releases to be a full SemVer `major.minor.patch` tag.
However, we don't currently have a way to take users from `@v7` to
`@v8.1.1`, in the case they're using Immutable Tags.
Given this isn't currently straightforward with any of our existing
SemVer-y versioning modules like `semver-coerced` or `semver-partial`,
we should instead introduce a specific Versioning module.
This mostly covers the functionality that `semver-partial` has, but
needs to take advantage of the `allVersions` parameter to find the
"shortest" possible tag for a given resolved Semantic Version.
This was previously attempted in previous changes, but reverted in
db64cc6de0 due to additional complexity.
We won't turn it on by default right now, but as a future change.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
As part of future changes, we'll introduce a new Versioning module for
GitHub Actions, which requires knowing if the version it's proposing
actually exists.
This is a more useful concept for Versioning modules to be able to take
advantage of, so we can expose this as an optional capability that
Versioning modules can use.
The changes in da04b8edac mostly worked,
but given `astral-sh/setup-uv` is now using Immutable Tags it _must_ be
resolved as `versioning=semver`, to make sure that version updates are
correctly raised.
However, we can't treat it as `versioning=semver`, as that will then
fail to parse the current version correctly.
Instead, we must use a `regex` versioning scheme, which allows us to
optionally parse the minor and patch versions.
This allows `newVersion` to be pinned accordingly to SemVer, but does
not require previous versions to be so.
We can do this - for now - with an explicit allowlist.
As per #42331, we should migrate to using `semver-partial` for GitHub
Actions' tags versions, instead of `docker`.
This mirrors actual usage of the way that the ecosystem tags Action
versions, and also has the benefit of automagically migrating users of
Actions that have enabled Immutable Tags, which now must be a full
SemVer tagged version.
As we're now specifying the `versioning: semver-partial`, we don't need
to specify it in `pinGitHubActionDigestsToSemver`.
* feat: add XcodeGen manager for Swift package dependencies in project.yml files
* chore(xcodegen): inline project.yml fixture
* fix(xcodegen): use semver instead of swift versioning
* fix(xcodegen): use glob syntax for manager file pattern
* tests(xcodegen): expect logger is called on invalid packages
* tests(xcodegen): better assert extracted package contents
* chore(xcodegen): simplify regex usage
* chore(xcodegen): log projects without dependencies
* chore(xcodegen): simplify dependency resolving and remove regular expressions in favor of the `detectPlatform` helper function
* chore(xcodegen): use `coerceString` on package versions to simplify testing and improve coverage
* chore(xcodegen): address PR review comments.
---------
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
* feat(manager/ant): add registry URL discovery from settingsFile and remoteRepository
Read Maven registry URLs from settingsFile attribute on dependency
blocks (parsed via Maven's extractRegistries) and from inline
<remoteRepository url="..." /> elements. Registries are merged,
deduplicated, and scoped to their dependency block.
* update java docs
* fix coverage
* apply suggestions
* fix ci issues
* feat(manager/ant): add coords= attribute syntax support
Support Maven coords attribute format (group:artifact:version and
group:artifact:version:scope) as an alternative to separate
groupId/artifactId/version attributes.
* add trace logs
* fix coverage
* feat: timing statistics for getReleases
Adds collection and reporting of timing statistics for
`datasource.getReleases()` calls. Each call records the datasource, registryUrl,
packageName, and duration. The intent is to visibility into where
renovate is retrieving release information and how long that might take.
The report consists of a nested data-structure that provides increasing
detail as we descend datasource, registryUrl, and packageName.
The full report is logged at trace level
`getReleases statistics with packages`.
A summary report including only datasources and registryUrls is logged
at debug level `getReleases statistics summary`.
* add GetReleasesSpanProcessor
- Re-instrument getReleases calls using open telemetry.
- Adds GetReleasesSpanProcessor, which can adapt
`getReleases` spans to GetReleasesStats.
* fixup instrumentation tests
* pr feedback
* pr feedback: naming
* pr feedback: comments
Support <import file="..."/> elements in Ant build files to follow
cross-file dependencies. Properties defined before the import are
available in the imported file. Cycle detection via visited-file
tracking prevents infinite loops.
* feat(bitbucket-pipelines):update file patterns to support shared configs
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* feat(bitbucket-pipelines):update file patterns to support shared configs
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* feat(bitbucket-pipelines):update file patterns to support shared configs
Signed-off-by: Adam Setch <adam.setch@outlook.com>
---------
Signed-off-by: Adam Setch <adam.setch@outlook.com>
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
* chore(types): add a strong type for `ToolName`s
Until #41849, we can use our local definitions of the tool names that
Containerbase supports by extracting out a `ToolName` type.
* fixup! chore(types): add a strong type for `ToolName`s
Co-authored-by: Claude Opus 4.6 <jamie.tanna+claude-code@mend.io>
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
* fixup! fixup! chore(types): add a strong type for `ToolName`s
* no-never
* simplify
* coverage
* sq
* warn
* sq
* fixup! sq
* sq
* fixup! sq
---------
Co-authored-by: Claude Opus 4.6 <jamie.tanna+claude-code@mend.io>
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
As part of future changes in the Go datasource, this will allow
detecting whether we do want to perform the API calls necessary to
discover `constraints` for a given Go module.
For performance reasons, we do not want to always perform this.
As part of the Enrichment module functionality, it would be useful to
have a consistent type for the status checks.
As a means to be able to use the underlying status check, without a
branch name, we can extract this into a separate type, while keeping the
existing type for use where we know the branch name.
* refactor(lint): extract custom oxlint rules into separate files
Split `tools/lint/rules.js` into one file per rule under
`tools/lint/rules/`. Also simplify `test-root-describe` with
early-exit guard clauses.
* feat(lint): add `enforce-ts-extension` oxlint rule
Add a custom JS-based oxlint rule that enforces `.ts` extensions on
local imports. The rule catches two problems:
- `.js` extension used instead of `.ts` (auto-fixable)
- missing file extension entirely (report only)
Checked locations:
- static import/export declarations
- dynamic `import()` expressions
- vitest module APIs: `vi.mock`, `vi.doMock`, `vi.unmock`,
`vi.doUnmock`, `vi.importActual`, `vi.importMock`
Both relative paths (`./`, `../`) and path aliases (`~test/`)
are treated as local. Package imports are ignored.
Also fixes 26 pre-existing violations across 18 spec files.
* Update tools/lint/rules/enforce-ts-extension.js
Co-authored-by: Anne Stellingwerf <1637358+astellingwerf@users.noreply.github.com>
---------
Co-authored-by: Anne Stellingwerf <1637358+astellingwerf@users.noreply.github.com>
* fix(manager/github-actions): disable updates for naked SHA pins without version comment
* docs(manager/github-actions): document disabled updates for bare SHA pins
* test(manager/github-actions): use single toEqual for version comment assertions
* docs(manager/github-actions): recommend version comment as primary fix for bare SHA pins
* fix(manager/github-actions): add skipReason for naked SHA pins
* docs(manager/github-actions): remove package rule example for re-enabling bare SHA updates
Co-authored-by: Jamie Tanna <github@jamietanna.co.uk>
---------
Co-authored-by: Jamie Tanna <github@jamietanna.co.uk>
* feat(manager): add Apache Ant manager with basic inline version extraction
Add new ant package manager that extracts Maven dependencies from
Ant build.xml files using the maven-resolver-ant-tasks library.
Supports inline version attributes on dependency elements.
* fix test
* reuse fn
* fix lint
* fix coverage
* apply suggestions
* simplify tests
* use extractPackageFile and extractPackageFiles
* coverage fix
* apply sugestions
* test: add additional case for attestation changes
* fix: correctly warn when an attestation is missing
As noted in #37258, when a package registry had previously seen an
attestation for authenticity of a given package release, Renovate should
warn if future updates then lose authenticity.
Our previous attempt at this didn't quite pass around the current
package's attestation, which results in no warnings.
Given recent supply chain attacks where an attestation was removed (such
as Axios in MSC-2026-3522), we should make sure that this logic does
work correctly, and flags to our users.
In the future, we'll add more checks and a failing status check.
By introducing `hasAttestation` in the `LookupUpdate`, this can now be
matched on with `matchJsonata`, as well as providing visibility in the
`packageFiles with updates` log line.
* fixup! fix: correctly warn when an attestation is missing
> Run `pnpm run jest
> lib/workers/repository/process/lookup/index.spec.ts` and handle any test
> failures - the implementation is correct, so update the tests
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* test: clarify that we don't check for intermediate releases
Which we'll look to improve as part of future changes.
* chore: fix typo
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
* fix(swift): don't write `from:` range to `Package.resolved`
When a dependency uses a range specifier like `from: "1.0.0"` in
Package.swift, the `newValue` produced by the versioning module contains
the range expression (e.g. `from: "603.0.0"`) rather than a plain version
string. Using `newValue` directly to update `Package.resolved` results in
the lock file containing the range expression instead of a resolved version,
which corrupts it.
Fix by using `dep.newVersion` with the `v` prefix stripped, which is
the actual resolved version and the correct value for `Package.resolved`.
* Update lib/modules/manager/swift/artifacts.ts
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
---------
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
Jamie Tanna