feat(lint): add `types-location` rule and enable it for `lib/modules`
Reviewers consistently ask for exported types to be moved into a
colocated `types.ts`. Add a `renovate/types-location` oxlint rule that
reports `export interface` / `export type` declarations outside such a
file, and turn it on across `lib/modules`.
Re-exports (`export type { X }`, `export type *`), file-local types, and
values (enums, classes, functions) are left alone. `schema.ts` files and
`schema/` directories are excluded via config, matching how
`zod-schema-location` is configured — inferred types belong next to the
schema they are derived from.
Relocating the 87 existing violations means:
- new `types.ts` files for the modules that had none
- `terragrunt/common.ts` folded into its `types.ts`, as it held nothing
else
- `RangeBound` in `versioning/gradle/compare.ts` un-exported, since only
a file-local interface referenced it
- `bazel-module/parser/fragments.ts` split from its inferred types, which
now live in `parser/types.ts` and infer through a namespace import so
each schema keeps its merged name
* 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>
The `ratchet:` alternative in the pin-comment regex only allowed
`owner/repo`, so a ratchet marker for an action in a subdirectory
(`owner/repo/path@ref`) never matched. Such comments fell through to the
bare-token branch, which made `currentValue` the entire marker string,
e.g. `ratchet:actions/cache/restore@v4`. That is not version-like, so
the dep was switched to the `github-digest` datasource, which cannot
resolve the marker as a tag or branch and logs "Could not determine new
digest for update". The dep then gets no updates at all.
Allow further path segments after `owner/repo` so that nested actions
are extracted the same way as their top-level counterparts, with
`currentValue: v4` and the `github-tags` datasource.
Assisted-by: Claude:claude-opus-5
* 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>
* refactor(manager/github-actions): return dependency arrays from community `with:` schemas
A `withSchema` now yields `PackageDependency[]` directly, instead of a
`{ val, ...meta }` object whose extra fields were merged in through an untyped
`Record<string, unknown>`. Schemas describe the dependency they find, and a
single step may yield more than one.
`isInvalid` moves out of `CommunityActionConfig` into `valSchema`, its only
caller. The config fields are now applied to every dependency a schema yields.
No behavior change.
* feat(manager/github-actions): support `pnpm/setup`
`pnpm/setup` replaces `pnpm/action-setup` for pnpm 11+. Its `version:` input
resolves as the `pnpm` package, and its `runtime:` input as the JavaScript
runtime to install - `node`, `bun` or `deno`, named as `<name>@<version>` to
match pnpm's `packageManager` field syntax.
An unknown runtime name is skipped as `invalid-name`, so a typo does not pass
silently.
* feat(lint): add renovate/zod-schema-location and renovate/prefer-json-pipe rules
Backlog item #23: reviewers repeatedly ask for consistent Zod schema
structure. Two new oxlint JS-plugin rules, both at "warn":
- renovate/zod-schema-location flags `export const X = <zod schema>` at
module scope in lib/modules/**/ files that aren't schema.ts (or a
colocated schema/ directory), reusing the leftmost-identifier schema
detection from zod-schema-naming.js / prefer-nullish-util.js. Only
exported top-level schemas are flagged — non-exported ones are treated
as intentionally local/trivial (e.g. tightly coupled to file-local
helpers), which keeps the rule's signal high.
- renovate/prefer-json-pipe flags `Schema.parse(JSON.parse(x))` /
`Schema.safeParse(JSON.parse(x))` and suggests `Json.pipe(Schema)` from
lib/util/schema-utils instead.
A third mined slice (require a matching `z.infer` type export for every
exported schema) was evaluated and skipped: ~275+ exported schema-like
consts in schema.ts files vs. 231 existing z.infer exports repo-wide is
too high a mismatch to flag mechanically without heavy per-site
judgment, so it would be mostly false positives.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor: fix a clean subset of renovate/zod-schema-location and renovate/prefer-json-pipe violations
renovate/prefer-json-pipe: fixed all 5 safe `.parse(JSON.parse(...))`
call sites (bazel datasource, generate-mise-registry script, a hook
spec) by switching to `Json.pipe(Schema).parse(...)`. Left the 2
`.safeParse(JSON.parse(...))` sites (pretooluse-check.ts,
github-query-items.ts) unfixed: JSON.parse throwing before safeParse is
reached today crashes the script, whereas Json.pipe folds the bad-JSON
case into a graceful `{ success: false }`, which is an observable
behavior change, not just a mechanical rewrite.
renovate/zod-schema-location: fixed the one clean, self-contained
violation (platform/github's GithubIssue schema, moved into the
already-existing platform/github/schema.ts) as a representative
example. Left the other 20: they require moving exported schemas out of
files where they're built from local helper functions/config tables
(manager/github-actions/community.ts) or restructuring an entire
directory into a new schema.ts with import-graph updates across many
files (manager/bazel/rules/*.ts, manager/bazel-module/parser/*.ts) —
real refactors needing per-site judgment, not mechanical fixes.
Both rules stay at "warn": renovate/prefer-json-pipe has 2 remaining
violations that shouldn't be auto-fixed, and renovate/zod-schema-location
has 20.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor: resolve remaining prefer-json-pipe and zod-schema-location findings
- github-actions: move the derived `CommunityActions` union into the
existing colocated `schema.ts`; the action config table and the
`actionSchema` builder stay in `community.ts` and are now exported.
- tools/docs: fold `JSON.parse` + `safeParse`/rethrow of the `gh` CLI
output into `Json.pipe(...)`. Invalid JSON now surfaces as a ZodError
instead of a SyntaxError; the only consumer catches generically, so
behavior is preserved.
- tools/agents/hooks: keep `JSON.parse` + `safeParse` with a reasoned
disable comment — hook scripts must stay dependency-light, and the
`Json` helper lives in lib/util/schema-utils, which drags in the full
lib import graph (logger, yaml, toml).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* feat(lint): enforce zod-schema-location and prefer-json-pipe as errors
Narrow `renovate/zod-schema-location` to files whose directory already
contains a colocated `schema.ts`. The mined reviewer feedback ("move
this to schema.ts") presumes the module follows that convention and the
schema leaked into a logic file. Modules that deliberately export
schemas from differently-named schema-only files — bazel `rules/*.ts`
Target schemas, bazel-module `parser/fragments.ts` — are a different,
accepted layout, not "schema mixed into logic", and are no longer
flagged.
With that narrowing and the preceding migrations, both rules are clean
repo-wide, so promote them from "warn" to "error".
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor: drop GithubIssue re-export from issue.ts
Consumers now import the schema directly from schema.ts.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(lint): register zod-schema-location rule
The rule registration was lost while merging main, so oxlint failed to
parse .oxlintrc.json with "Rule 'zod-schema-location' not found in plugin
'renovate'". Re-add the import and rules entry, and restore alphabetical
ordering for prefer-json-pipe.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* fix(lint): allow sync fs in zod-schema-location rule
ESLint rules execute synchronously, so the sibling `schema.ts` lookup
cannot use async fs. Silence `no-sync` with a justification.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Enable the unicorn/prefer-at rule as error in .oxlintrc.json and fix all
43 pre-existing violations (arr[arr.length - 1] -> arr.at(-1)) via oxlint
autofix. Where .at() widened the type to T | undefined, non-null
assertions were added at sites where surrounding logic guarantees the
element exists (length guards, split results), preserving the original
runtime behavior and typing.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Add test coverage for community actions that had no corresponding
tests: azure/setup-helm, docker/setup-buildx-action,
docker/setup-compose-action, helm/chart-testing-action, and
sigoden/install-binary.
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
* feat(manager/github-actions): support dtolnay/rust-toolchain `toolchain` input
Extract the `toolchain` input of `dtolnay/rust-toolchain` as a `rust` dependency via the `rust-version` datasource, mirroring the rust-toolchain manager. Sliding-window expressions like `stable 18 months ago` are extracted as-is and rejected by the `rust-release-channel` versioning during lookup.
* feat(manager/github-actions): add rust-version datasource to `supportedDatasources`
* feat(datasource/github-runners): add macOS Intel labels
Add `macos-15-intel` and `macos-26-intel` runner labels to the datasource.
* feat(datasource/github-runners): add tests
Add test for upgrading macos-*-intel runners.
* chore(datasource/github-runners): split tests
Split-up the tests into different operating system families.
* docs(manger/github-actions): reword "community actions" section
As some follow-ups to 27a3f5871f, we
can slightly reword the intro to add some more information about what
these target.
* docs(manager/github-actions): document why there may not be a `packageName`
* docs(manager/github-actions): generate a table for Actions and their `with`s
To provide further clarity on how each of the Actions' `with`s are used,
we can make this more explicit in our autogenerated docs, providing:
- which field(s) are extracted, taken from their Zod schema (with help
from Claude Opus to extract this)
- note the dependency updating, and where it may be determined from the
given `withSchema`
Co-authored-by: Claude Opus 4.7 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Opus 4.7 <jamie.tanna+claude-code@mend.io>
* chore: migrate from zod/v3 to zod/v4
This commit contains the logic changes
* chore: migrate imports from zod/v3 to zod/v4
This contains import updates and adds explicit record keys as zod/v4 requires these now
* ci: enforce usage of zod/v4
* feat(datasource/github-runners): stabilize arm64
Mark the Ubuntu ARM runners as stable.
* feat(datasource/github-runners): add test
Add test for upgrading ubuntu-22.04-arm runners.
* feat(datasource/github-runners): add windows-11-arm label
Add support for Windows 11 ARM runners in the GitHub Runners datasource.
* feat(datasource/github-runners): add test
Add test for extracting windows-11-arm runners.
* feat(datasource/github-runners): fix test
Update expected length.
* test(noNewURL): add new rule enforcing parseUrl() from 'lib/util/url.ts'
* replace newURL with parseUrl
* remove non-null assertions marks if appropiate
* test: add additional tests
* test: add additional tests and ignore where it makes sense
* implement suggestions
* test: further improve coverage
* apply suggestion
As noted in #42899, some Actions use a version such as `v2.2-rc.1` which
we weren't handling or updating.
Co-authored-by: Claude Sonnet 4.6 <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>
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`.
* 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>
* docs: explicitly document `depTypes` each manager supports
A long-standing question we receive is "what `depTypes` can I match
against in my project".
Although the best recommendation we usually have is "check the
`packageFiles with updates" log line (as a very key log line for users),
we can go one step further and try and create a stronger contract.
To do this, I've used Claude Sonnet 4.6 to work through the codebase,
determine areas that a `depType` is set in a manager (statically or
dynamically) and generate a structured, typed, means to document how
they're used.
Through a few iterations of the process, and attempts at human-written
documentation, we've settled on:
- prioritising autogenerated documentation (for humans to read) to note
what `depTypes` are known, and what they are
- `knownDepTypes`, to describe any known, static, `depType`s and their
human-readable meaning
- with the `prettyDepType`, if used
- `supportsDynamicDepTypesNote`, to add a Markdown note to the generated
documentation
While here, we also:
- make sure to note this in the "adding a new package manager"
documentation
- remove any hand-written references to `depTypes` in each manager's
documentation page
- correct the Gleam `depTypes`
- make sure to use the `knownDepTypes`'s `prettyDepType` definition if
we know it, for a given `depType`
The descriptions have been generated by Claude Sonnet, with some
human-written tweaks where appropriate.
[0]: https://github.com/renovatebot/renovate/discussions/15176
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fixup! docs: explicitly document `depTypes` each manager supports
* docs(manager): display `depTypes` documentation if none present
For consistency, and to make it more explicit.
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* feat(github-actions): Support non-semver refs (tags and branches)
* refactor(github-actions): drop ref= prefix, use bare token comments
Address review feedback: use bare `# cargo-llvm-cov` instead of
`# ref=cargo-llvm-cov` for non-semver pin comments, consistent with
how version comments work (`# v4.0.0`).
- Rename pinnedVersionRe -> pinTokenRe, add bareTokenRe fallback
- Add `ref` field to CommentData, separate from pinnedVersion
- Guard replaceString extension to only use ref for SHA-pinned actions
- Remove redundant autoReplaceStringTemplate override
- Deduplicate versionLikeRe (export from parse.ts)
- Add datasource assertions to non-semver tests
* refactor(github-actions): remove unreachable parseComment branch
* test(github-actions): add coverage for non-version ref fallback
Sebastian Poxhofer