Sebastian Poxhofer
4b4d14ec00
* feat(manager): pass extracted constraints to updateArtifacts `extractedConstraints` were collected during extraction but only ever read by `fetch.ts` for the lookup. At artifact time every manager had to derive the same tool constraints a second time, and when the updated package file no longer carried the constraint there was nothing to fall back to. `generateBranchConfig()` now merges the `extractedConstraints` of all upgrades of a branch onto the branch config, which reaches `updateArtifacts()` through `patchConfigForArtifactsUpdate()`. `UpdateArtifactsConfig` declares the field and documents what it contains. The new `resolveToolConstraint()` helper implements the ladder once: user `constraints` > an optional artifact-time derivation > the extracted value. The derivation is ranked above the extracted value on purpose: it reads the package files as the branch changed them, so poetry (python is an updatable dependency there), composer, pipenv (`pipenv` can be a dev package) and pep621 (`requires-python` is an updatable dependency) would otherwise regress to a stale constraint. pipenv, pep621 uv/pdm, poetry and composer are migrated to the helper and keep their derivation. Behaviour change: these managers now use the extract-time constraint as a last resort instead of running unconstrained, for example on lock file maintenance where pipenv deletes `Pipfile.lock` before deriving. `execute-post-upgrade-commands.ts` is unaffected: it reads `upgrade.constraints` per upgrade, and the extracted values are kept in a separate field rather than folded into `constraints`, so post-upgrade task tool constraints still come from user config only. Not migrated, because their constraints are never extracted, so the fallback would be dead code: bundler (`ruby`/`bundler`), pixi (`pixi`), pep621 uv (`required-version`) and npm's node ladder, whose last step already reads `package.json` engines. * refactor(manager): resolve tool constraints through resolveToolConstraint() Every manager now obtains the constraint of a tool it runs through `resolveToolConstraint()` instead of reading `config.constraints` itself, so the precedence "user config, then a value derived from the updated files, then the constraints collected during extraction" applies everywhere. The helper treats an empty string as not set at every step and accepts the `PostUpdateConfig` shape, whose `constraints` may be `null`. Behaviour changes that go beyond the new fallback to extracted constraints: - `mix` applies its hardcoded erlang default only after the extracted constraint, so an erlang version collected at extraction can win over it. - `kustomize` decides `HELM_EXPERIMENTAL_OCI` from the fully resolved helm constraint; `generateHelmEnvs()` takes that value instead of the config. - `npm` (yarn): an upgrade of yarn without a new value now consults the user constraint before deriving one from package.json or the lock file. - The "Using <tool> constraint from config" debug lines in bundler, composer, copier and pip-compile are gone, as the helper is the only reader of the config now. Helpers that read the config synchronously became async: bundler `getBundlerConstraint()`, copier `getPythonVersionConstraint()` and `getCopierVersionConstraint()`, pip-compile `get*VersionConstraint()` and `getToolVersionConstraint()`, gomod `deriveGoToolchainConstraints()` and `getUpdateImportPathCmds()`, mise `getMiseLockToolConstraints()`. composer `getPhpConstraint()` is removed. Each converted manager has a test showing the extracted constraint reaching the executed tool, and, where a derive callback exists, that the derived value still wins over it. * refactor(linters): add prefer-resolve-tool-constraint rule Reports member reads and destructuring of `constraints` and `extractedConstraints` from a manager config in `lib/modules/manager/**`, so that tool constraints are resolved through `resolveToolConstraint()` in `lib/modules/manager/util.ts` only. Writes and the same properties on package files, which extraction has to populate, are not reported. The helper itself and spec files are exempt in `.oxlintrc.json`. * refactor(manager): inline thin resolveToolConstraint wrappers Drop copier/utils.ts and the pip-compile getPipToolsVersionConstraint / getUvVersionConstraint helpers, which only forwarded to resolveToolConstraint(). Callers now call it directly. * docs(development): note lock file maintenance in tool constraints section * refactor(manager): address review on tool constraint resolution composer only runs extractConstraints() when a user constraint is missing, via Lazy. UpdateArtifactsConfig no longer re-declares constraints and extractedConstraints, which ToolConstraintsConfig already provides.
The github-actions manager extracts dependencies from GitHub Actions workflow and workflow template files.
It can also be used for Gitea and Forgejo Actions workflows as such are compatible with GitHub Actions workflows.
Digest pinning and updating
If you like to use digest pinning but want to follow the action version tag, you can use the sample below:
name: build
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # v4.0.0
Renovate will update the commit SHA according to the GitHub tag you specified.
Renovate can update digests that use SHA1 and SHA256 algorithms.
The GitHub tag is in the format of <PREFIX><SEPARATOR><VERSION>.
PREFIX and SEPARATOR are optional.
Valid separators are the ASCII hyphen (-) or forward slash (/).
VERSION can include the major, minor, and patch components and may optionally include a v prefix.
Here are the examples of valid GitHub tags:
1.0.1, 1.0, 1,
v1.0.1, v1.0, v1,
prefix-1.0.1, prefix-1.0, prefix-1,
prefix-v1.0.1, prefix-v1.0, prefix-v1.
prefix/1.0.1, prefix/1.0, prefix/1,
prefix/v1.0.1, prefix/v1.0, prefix/v1.
If you want to automatically pin action digests add the helpers:pinGitHubActionDigests preset to the extends array:
{
"extends": ["helpers:pinGitHubActionDigests"]
}
Actions pinned to a bare SHA without a version comment are disabled by default, because Renovate cannot determine which branch or tag the SHA belongs to. To enable updates, add a tag or branch name as a version comment, as shown above.
Reusable workflows
A job-level uses: which points at owner/repo/.github/workflows/<file>.yml@<ref> calls a reusable workflow instead of running an action, so Renovate gives it the workflow depType.
Every other uses: reference to a repository keeps the action depType, including an action in a subdirectory such as github/codeql-action/init@v3.
Use matchDepTypes to configure the two separately.
For example, to keep pinning action digests but leave reusable workflow calls on their tag:
{
"extends": ["helpers:pinGitHubActionDigests"],
"packageRules": [
{
"matchDepTypes": ["workflow"],
"pinDigests": false
}
]
}
GitHub Actions lockfile (actions.lock)
!!! warning "This feature is flagged as experimental"
Experimental features might be changed at any time.
Due to GitHub classing this functionality as a "public preview", there may be changes to Renovate's functionality - in a possibly breaking manner - while GitHub work to stabilise the feature.
Renovate keeps the GitHub Actions dependency lockfile in sync.
The lockfile is an alternative to inline digest pinning: your workflows keep readable tags like actions/checkout@v4.3.1, and .github/workflows/actions.lock records the commit each tag resolved to.
If the repository has a .github/workflows/actions.lock, then Renovate regenerates it whenever it updates an action.
Renovate installs the gh-actions-lock extension for the gh CLI, and runs gh actions-lock once per branch, from the repository root, after writing every updated workflow:
gh extension install github/gh-actions-lock --pin <version> --force
gh actions-lock --no-interactive --no-narrow --no-migrate-local-actions
Renovate opts out of two rewrites that gh actions-lock performs by default, as both would change more than the dependency being updated: narrowing a ref like @v4 to @v4.2.1, which would contradict the version in the pull request and defeat a deliberately floating major tag, and migrating same-repo uses: ./… references to the uses: $/… form.
You do not need to configure anything: if there's no actions.lock file, then there's nothing to update.
Workflows which are not onboarded to the lockfile are skipped.
Local composite actions are still regenerated, as they can be transitive dependencies of a workflow which is onboarded.
!!! note
The lockfile is an alternative to inline digest pinning: your workflows keep readable tags like actions/checkout@v4.3.1, and .github/workflows/actions.lock records the commit each tag resolved to.
When updating the lockfile, gh actions-lock replaces digest pinned GitHub Actions to the version reference:
-uses: actions/setup-java@1bcf9fb12cf4aa7d266a90ae39939e61372fe520 # v5.4.0
+uses: actions/setup-java@v5.7.0
Digests that are already pinned will be updated by Renovate, until they are removed by gh actions-lock.
This does not apply if your organization or repository enables the Require actions to be pinned to a full-length commit SHA policy, found in your Actions settings.
If this is enabled, gh actions-lock leaves the digests in place, so your workflows stay digest pinned and Renovate carries on updating them.
Renovate pins the version of the actions-lock extension to provide deterministic updates, which is then bumped in a later Renovate release.
To use a different version, set the ghActionsLock constraint:
{
"constraints": {
"ghActionsLock": "v0.1.7"
}
}
The version must be a full release tag, like v0.1.7.
Because constraints is mergeable, setting "constraints": {} does not remove the pin: set the value to an empty string to always install the latest extension.
{
"constraints": {
"ghActionsLock": ""
}
}
You can also control the gh CLI version using constraints.gh.
!!! note
With binarySource=global, Renovate does not install or re-pin the extension, as Renovate uses the tools installed by your administrator's deployment.
Both gh and the gh-actions-lock extension must already be available, and specifying ghActionsLock and gh in your repository's constraints will be ignored.
Pin the extension when you provision your image:
gh extension install github/gh-actions-lock --pin v0.1.6
!!! note
gh actions-lock resolves refs and repository IDs through the GitHub API, so it needs a token.
Renovate takes the token from the github host rule matching your platform endpoint, and passes it as GH_TOKEN.
On GitHub Enterprise Server Renovate passes that token using GH_ENTERPRISE_TOKEN and GH_HOST, and additionally passes the token from your github.com host rule as GH_TOKEN, because public actions are still resolved against github.com.
Non-semver refs (branches and feature tags)
Renovate supports GitHub Actions that reference non-semver refs like branch names (main, master) or feature-oriented tags (cargo-llvm-cov).
When the action reference doesn't look like a version number (i.e., doesn't match /^v?\d+/), Renovate routes to the github-digest datasource which fetches both tags and branches.
Since these refs have no version ordering, only digest pinning updates are supported.
Routing logic:
actions/checkout@v4.2.0→github-tagsdatasource (version updates)actions/checkout@v4→github-tagsdatasource (version updates)taiki-e/install-action@cargo-llvm-cov→github-digestdatasource (digest pinning only)actions/checkout@main→github-digestdatasource (digest pinning only)
When pinning, Renovate adds a comment to preserve the original ref:
- uses: taiki-e/install-action@d8c10dae823f48238abff23fee4146b448aed2f1 # cargo-llvm-cov
Non-semver ref support is currently limited to GitHub-hosted actions. Gitea and Forgejo support the same ref types, but Renovate does not yet handle them for these platforms.
Steps nested in parallel: blocks
Renovate extracts dependencies from steps nested inside a parallel: block, just as it does for regular sequential steps.
This includes both the action reference itself and any supported with: version inputs.
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- parallel:
- uses: actions/setup-node@v5
with:
node-version: '20.0.0'
- uses: actions/setup-go@v5
with:
go-version: '1.23'
Non-support of Variables
Renovate ignores any GitHub runners which are configured in variables.
For example, Renovate ignores the runner configured in the RUNNER variable:
name: build
on: [push]
env:
RUNNER: ubuntu-22.04
jobs:
build:
runs-on: ${{ env.RUNNER }}
Ratchet support
The github-action manager understands ratchet comments, like # ratchet:actions/checkout@v2.1.0.
This means that Renovate will:
- update the version of a pinned Ratchet version if needed
- not delete Ratchet comments after parsing them
- keep
# ratchet:excludecomments
Updating with: values in GitHub Actions
Both GitHub's own first-party Actions and Actions maintained by the wider community will commonly specify a version of a given tool using a with: block, such as:
steps:
- uses: actions/setup-node@v5
with:
node-version: '22.0.0'
- uses: astral-sh/setup-uv@v10.1.0
with:
version: '0.4.x'
Renovate supports extracting some of these input(s) from the following Actions, and performing automagic dependency updates accordingly.
A single step can yield more than one dependency.
For example, pnpm/setup declares both the pnpm version and the JavaScript runtime to install:
steps:
- uses: pnpm/setup@v1
with:
version: '12.0.0'
runtime: 'node@24.1.0'
The following Actions have support for their with: blocks:
1 Default for the datasource used.
Depending on your use case, you may need to change versioning manually.
If you find a use case which you think Renovate could/should automatically detect and support without manual configuration, please raise Suggest an Idea Discussion.