3 Commits

Author	SHA1	Message	Date
Sebastian Poxhofer	4b4d14ec00	feat(manager): pass extracted constraints to updateArtifacts (#45826) ... * 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.	2026-09-14 11:09:07 +00:00
Sebastian Poxhofer	69e05233e8	feat(manager/github-actions): add workflow depType for reusable workflow calls (#45443) ... * feat(manager/github-actions): add `workflow` depType for reusable workflow calls A job-level `uses:` pointing at `owner/repo/.github/workflows/<file>.yml@<ref>` calls a reusable workflow rather than running an action, but both got the `action` depType, so `matchDepTypes` could not tell them apart. Give a reference whose sub-path is exactly `.github/workflows/<file>.yml|.yaml` the new `workflow` depType. Every other sub-path, such as `github/codeql-action/init`, stays an action. The existing depType-keyed sites now accept both values, so nothing else changes behaviour: the `actions.lock` file records reusable workflow calls too, and `helpers:pinGitHubActionDigests` pinned them before this split. * Apply suggestions from code review Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>	2026-08-25 11:52:05 +00:00
Jamie Tanna	fba1a9de30	feat(manager/github-actions): add support for Actions Lockfiles (#45199) ... * 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>	2026-08-11 11:55:06 +00:00