Jamie Tanna
2d239d2cc1
* 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>
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"]
}
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.
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
with:version support for built-in Actions
Renovate supports updating the "with" version for actions/setup-go, actions/setup-node, and actions/setup-python, although not all syntaxes are supported out of the box.
By default, Renovate will use npm-style semver versioning for go and python, and Renovate's built-in node versioning for updating node.
The goal of these defaults is to match as closely as possible to what these GitHub Actions support.
For example, normally the ^ syntax is not used in go or python, but it's supported in their respective actions.
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 a Discussion to suggest it.
commonly used community actions
Renovate also supports some commonly used community actions:
astral-sh/setup-uvpnpm/action-setuppdm-project/setup-pdmjaxxstorm/action-install-gh-releasesigoden/install-binaryprefix-dev/setup-pixipypa/hatch@installgolangci/golangci-lint-action