GitHub Actions manager misses updates for component-prefixed version tags

[zeitlinger]

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

GitHub.com

Which version of Renovate are you using?

44.40.0

Please tell us more about your question or problem

The built-in github-actions manager does not propose version updates for a digest-pinned Action whose tag has a slash-separated component prefix.

Reproduction

The public repository is:

• Workflow: https://github.com/prometheus/client_java/blob/73fbd90fee7da1c39c9b9cf1631c22930c19b8e9/.github/workflows/pr-title.yml#L17
• Renovate config: https://github.com/prometheus/client_java/blob/73fbd90fee7da1c39c9b9cf1631c22930c19b8e9/.github/renovate.json5
• Dependency dashboard: Dependency Dashboard prometheus/client_java#1378

The relevant workflow entry is:

- uses: grafana/shared-workflows/actions/lint-pr-title@823ed150196915a86971ab4beb899b0c80d835fe # lint-pr-title/v1.2.3

The upstream repository has these tags:

• lint-pr-title/v1.2.3 -> 823ed150196915a86971ab4beb899b0c80d835fe
• lint-pr-title/v1.2.4 -> 70c40e5b6522c854a55334124545261cae3d4c73

Running the following against the repository reproduces the result:

LOG_LEVEL=debug renovate --dry-run=lookup prometheus/client_java

Expected behavior

Renovate proposes an update from lint-pr-title/v1.2.3 to lint-pr-title/v1.2.4, updating both the comment and pinned digest.

The GitHub Actions manager documentation lists prefix/v1.0.1 as a valid tag format:
https://docs.renovatebot.com/modules/manager/github-actions/#digest-pinning-and-updating

Actual behavior

Renovate detects the dependency but returns no updates:

{
  "depName": "grafana/shared-workflows",
  "versioning": "exact",
  "currentValue": "lint-pr-title/v1.2.3",
  "currentDigest": "823ed150196915a86971ab4beb899b0c80d835fe",
  "datasource": "github-digest",
  "updates": [],
  "packageName": "grafana/shared-workflows",
  "warnings": [],
  "currentVersion": "lint-pr-title/v1.2.3",
  "fixedVersion": "lint-pr-title/v1.2.3"
}

The parser accepts a component-prefixed pinned version, but versionLikeRe is currently /^v?\d+/. As a result, lint-pr-title/v1.2.3 is routed as a non-semver ref to github-digest with exact versioning, where only changes to the digest of the same ref are considered:

• renovate/lib/modules/manager/github-actions/parse.ts

  Lines 203 to 207 in ea8d11b

  	const pinTokenRe = regEx(
  	/^\s*(?:(?:renovate\s*:\s*)?(?:pin\s+|tag\s*=\s*)?|(?:ratchet:[\w-]+\/[.\w-]+(?:\/[.\w-]+)*))?@?(?<version>([\w-]*[-/])?v?\d+(?:\.\d+(?:\.\d+)?)?(?:-[a-zA-Z0-9.]+)?)/,
  	);
  	export const versionLikeRe = regEx(/^v?\d+/);

• renovate/lib/modules/manager/github-actions/extract.ts

  Lines 146 to 153 in ea8d11b

  	const isVersionLike =
  	dep.currentValue && versionLikeRe.test(dep.currentValue);
  	if (!dep.datasource && dep.currentValue && !isVersionLike) {
  	dep.datasource = GithubDigestDatasource.id;
  	dep.versioning = exactVersioning.id;
  	}
  	dep.datasource ??= GithubTagsDatasource.id;

A package rule with component-aware regex versioning makes Renovate find the expected update:

{
  matchManagers: ["github-actions"],
  matchPackageNames: ["grafana/shared-workflows"],
  matchCurrentValue: "/^.+[-/]v?\\d+\\.\\d+(?:\\.\\d+)?$/",
  overrideDatasource: "github-tags",
  versioning: "regex:^(?<compatibility>.*)[-/]v?(?<major>\\d+)\\.(?<minor>\\d+)(?:\\.(?<patch>\\d+))?$",
}

This seems related to, but distinct from:

• How to update github actions version with renovate, if tags in actions monorepo has format <action-name>-v<semver> #37024, which describes configuring unpinned monorepo Action tags.
• pinDigests with github-actions fails for suffixed version tags #35789, which concerns suffixed tags and digest pinning.

Is component-prefixed version ordering supposed to work automatically for digest-pinned Actions, as the documentation appears to indicate? If prefix handling is intentionally configuration-only, could the documentation clarify that these are valid only for same-ref digest updates?

Logs (if relevant)

Relevant packageFiles with updates entry

{
  "depName": "grafana/shared-workflows",
  "commitMessageTopic": "{{{depName}}} action",
  "versioning": "exact",
  "depType": "action",
  "replaceString": "grafana/shared-workflows/actions/lint-pr-title@823ed150196915a86971ab4beb899b0c80d835fe # lint-pr-title/v1.2.3",
  "currentValue": "lint-pr-title/v1.2.3",
  "currentDigest": "823ed150196915a86971ab4beb899b0c80d835fe",
  "datasource": "github-digest",
  "updates": [],
  "packageName": "grafana/shared-workflows",
  "warnings": [],
  "sourceUrl": "https://github.com/grafana/shared-workflows",
  "registryUrl": "https://github.com",
  "currentVersion": "lint-pr-title/v1.2.3",
  "currentVersionTimestamp": "2026-06-10T15:37:47.000Z",
  "fixedVersion": "lint-pr-title/v1.2.3"
}

[sambai-dev]

Confirmed: your source reading is correct, and the two documentation sections genuinely disagree about this tag shape. The "Digest pinning and updating" list accepts prefix/v1.2.3, but the extraction code routes any ref whose currentValue does not match versionLikeRe (/^v?\d+/, anchored at the start, so the lint-pr-title/ prefix fails it) to the github-digest datasource with exact versioning. That combination only re-resolves the digest of the ref you already have and never looks up lint-pr-title/v1.2.4, hence the empty updates array.

Checked today against main (9d0e535934) and the refs you cited:

• lib/modules/manager/github-actions/parse.ts exports exactly the regex you quoted; extract.ts contains the routing branch you linked, unchanged since the SHA you pinned.
• The pin-comment parser is broader than the routing gate: its token pattern (([\w-]*[-/])?v?\d+...) accepts component prefixes, which is why # lint-pr-title/v1.2.3 is captured as pinnedVersion while the value still ends up classified non-version-like. The asymmetry sits between those two regexes.
• This routing dates to feat(github-actions): Support digests for non-semver refs #40225 (digest support for non-semver refs). The "Non-semver refs" docs section (https://docs.renovatebot.com/modules/manager/github-actions/#non-semver-refs-branches-and-feature-tags) documents it as intentional: refs not matching ^v?\d+ get digest-pinning only.
• Tags on grafana/shared-workflows confirm your mapping: lint-pr-title/v1.2.3 -> 823ed150196915a86971ab4beb899b0c80d835fe, lint-pr-title/v1.2.4 -> 70c40e5b6522c854a55334124545261cae3d4c73.

So automatic version ordering for these tags currently exists only where the whole tag passes ^v?\d+ (bare semver). For component-prefixed tags it is configuration-only, and your package rule is the right workaround. I verified the mechanism it depends on rather than executing Renovate: regex versioning compares the named capture groups and never rebuilds the version string, so the regenerated comment should keep the full upstream tag (lint-pr-title/v1.2.4) rather than losing the prefix. Please treat the first produced branch as the confirmation point.

On intent I cannot settle it: #35789 (#35789, open since May 2025, labeled priority-3-medium, manager:github-actions) tracks the sibling case of suffixed tags failing digest pinning, which suggests the gap is known but unowned. It appears the "valid GitHub tags" list simply predates the #40225 routing change; whether to honor the documented formats or narrow the docs is a maintainer call, so your closing questions are the right ones to leave standing.

Disclosure: this is a scheduled community-help reply; research and drafting used AI assistance, with each claim above checked against the live sources listed.

[RahulGautamSingh]

Thanks for the detailed writeup @zeitlinger , the reproduction and the source links made this quick to confirm.

Your reading is correct, and the short answer is: component-prefixed tags have never been version-ordered. This is a documentation bug on our side, not a regression.

What's actually happening

versionLikeRe in parse.ts is /^v?\d+/, so lint-pr-title/v1.2.3 is classified non-version-like and routed in extract.ts to github-digest + exact versioning, which only re-resolves the digest of the ref you already have. Hence the empty updates.

The asymmetry you spotted is real: pinTokenRe accepts ([\w-]*[-/])?v?\d+, so the prefixed tag is captured as pinnedVersion. The comment parser is broader than the routing gate.

Also, #40225 is not the cause. Before that PR these deps went to github-tags with github-actions versioning, whose massageValue strips only a leading v .. isValid('lint-pr-title/v1.2.3') is false there too. #40225 only changed how this fails.

The docs list you quoted came from #35431, which only widened the pin-comment parsing regex i.e. which comment shapes Renovate can read back. It never touched versioning. That list documents comment syntax and shouldn't be read as a claim that version updates work for those tags.

Your workaround is the right one

Your package rule works for the right reason: regex: versioning compares the named capture groups and uses compatibility to keep lint-pr-title/* from being compared against tags of other components in the same monorepo. The prefix survives into the regenerated comment, so both the pin and the comment update correctly.

Next steps

Two things to fix:

1. Docs: clarify that the tag list describes comment syntax, and point component-prefixed tags at the package-rule recipe above. I'll pick this up.
2. Proper support: make github-actions versioning prefix-aware with the prefix as compatibility, then widen the routing gate. That's a larger change and needs maintainer approval on whether we want it built in versus configuration-only.

Related but distinct: #35789 covers the suffixed-tag case.

[zeitlinger]

I prototyped the built-in approach in a draft PR: #45441. It was fairly contained: widen the GitHub Actions routing gate, teach its versioning module to strip a component prefix while treating that prefix as compatibility, and add regression tests for digest-pinned tags plus cross-component filtering. The focused checks pass, and the upstream CI is running.

So proper support does not appear technically difficult from this reproduction. The remaining question is product/maintenance intent: whether the manager should own this convention or keep it as a package-rule recipe.

[zeitlinger]

@jamietanna what do you think?