* fix(versioning/github-actions): don't parse `allowedVersion`-style ranges as a range
As noted in #42824, when using a range for `allowedVersion`, changes to
how ranges are parsed with `semver.coerce` led to incorrectly matching
this as a version that would like to be updated to.
We can guard this by making sure a SemVer style version number is used.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* perf(versioning/github-actions): create constants for regexes
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* test: skip coverage
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fixup
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(versioning/github-actions): treat floating tags as equal
As noted in #42662, if a floating tag `@v2` is used, Renovate currently
tries to roll it back to `@v1`, as it doesn't see that `@v2 === @v2`.
* fix(versioning/github-actions): allow `v` prefix matching too
* fix(versioning/github-actions): correctly handle `major.minor` and `major`
As part of the final set of changes needed to support Immutable Releases
with GitHub Actions and the `github-actions` versioning, we need to
modify how our versioning works to handle correctly surfacing the
shortest version available.
To make this more resilient, and help us test-drive the change, we'll
also add an integration test that:
- extracts from a GitHub Actions workflow
- performs a lookup (with mocked data)
- determines the available updates that would be proposed
This provides more confidence in the change itself, as well as
validates the intended changes.
This also moves `prefix` and `minLevel` to a single definition.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fixup! fix(versioning/github-actions): correctly handle `major.minor` and `major`
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fixup! fix(versioning/github-actions): correctly handle `major.minor` and `major`
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
So all lookups downstream can be performed in `O(1)` time.
Suggested by Claude Sonnet.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
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>
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>
Jamie Tanna