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>
* refactor(manager/github-actions): make `extractPackageFile` async
As part of follow-up changes we'll need to read `.github/workflows/actions.lock`
while extracting, which requires we are an async function.
To reduce the diff, we can prefactor this change first.
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
* feat(manager/github-actions): add support for Actions Lockfiles
In June, GitHub announced a public preview for the GitHub Actions
lockfile functionality[0].
To add support for this, we can extend our support for GitHub Actions to
handle the presence of an `actions.lock` file, and if so, update it
after updating other manager files.
Although our ideal case would be to have a pure Typescript-based parsing
and updating of the `actions.lock`, due to the early nature of the
Actions Lockfile syntax, and its lack of stability, we can invoke the
`gh actions-lock` extension when updating.
After the schema has reached a v1 release, we can then migrate to
Typescript.
To make sure that the version of the `actions-lock` extension is always
version pinned, we can expose a `constraints` to control the version,
but allow Renovate to keep the pinned default updated as needed.
This doesn't imply that we have support for `lockFileMaintenance`, as we
are only updating the lockfile when there is a dependency update, not
periodically recreating the lockfile from the current ranges.
`gh actions-lock` re-reads every workflow from disk and rewrites the
whole lockfile, so it does not fit `updateArtifacts`, which is called
once per updated package file.
We can instead follow the shape the `npm` manager uses for its
lock files, and have `processBranch` invoke this once per branch, after
every updated package file has been written to disk.
We skip workflows that aren't onboarded to the lockfile, but still run
for any other package file, as a local composite action can be a
transitive dependency of a workflow which is.
`gh actions-lock` rewrites the workflows it manages back to plain refs
when it regenerates them, which strips out any inline digest pin:
```diff
- uses: actions/setup-java@1bcf9fb12c # v5.4.0
+ uses: actions/setup-java@v5.7.0
```
This would lead to a repository with `pinDigests` set "flip flopping",
and would cause a lot of erroneous noise for repository owners.
Instead, we can make sure that:
- we don't suggest a `pinDigest` for workflows that are managed by the
lockfile
- digest pinning is still enabled for `docker://` references
- already-committed digests are updated when they're present - we only
avoid suggesting /new/ digests to be pinned
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Claude Fable 5 <jamie.tanna+claude-code@mend.io>
[0]: https://github.com/github/actions-lockfile
* coverage
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* fixup! feat(manager/github-actions): add support for Actions Lockfiles
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
* 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>
Jamie Tanna