Skip to content

Bump dependabot/fetch-metadata from 2.5.0 to 3.1.0 - #89

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/github_actions/dependabot/fetch-metadata-3.1.0
Open

dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/github_actions/dependabot/fetch-metadata-3.1.0

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Apr 20, 2026

Copy link
Copy Markdown
Contributor

Bumps dependabot/fetch-metadata from 2.5.0 to 3.1.0.

Release notes

Sourced from dependabot/fetch-metadata's releases.

v3.1.0

What's Changed

New Contributors

Full Changelog: dependabot/fetch-metadata@v3...v3.1.0

v3.0.0

The breaking change is requiring Node.js version v24 as the Actions runtime.

What's Changed

... (truncated)

Commits
  • 25dd0e3 v3.1.0 (#692)
  • e073f50 Merge pull request #705 from dependabot/dependabot/npm_and_yarn/hono-4.12.14
  • 0670e16 build(deps-dev): bump hono from 4.12.12 to 4.12.14
  • 7a7fe10 Merge pull request #702 from dependabot/dependabot/npm_and_yarn/dependencies-...
  • 5168191 Updating dist build
  • 23882e1 build(deps): bump @​actions/github in the dependencies group
  • 1072469 Merge pull request #701 from dependabot/dependabot/github_actions/actions/cre...
  • 43f8a00 build(deps): bump actions/create-github-app-token from 3.0.0 to 3.1.1
  • b4d904a Merge pull request #703 from dependabot/dependabot/npm_and_yarn/globals-17.5.0
  • c8046bb build(deps-dev): bump globals from 17.4.0 to 17.5.0
  • Additional commits viewable in compare view

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Bumps [dependabot/fetch-metadata](https://github.com/dependabot/fetch-metadata) from 2.5.0 to 3.1.0.
- [Release notes](https://github.com/dependabot/fetch-metadata/releases)
- [Commits](dependabot/fetch-metadata@v2.5.0...v3.1.0)

---
updated-dependencies:
- dependency-name: dependabot/fetch-metadata
  dependency-version: 3.1.0
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot @github

dependabot Bot commented on behalf of github Apr 20, 2026

Copy link
Copy Markdown
Contributor Author

Labels

The following labels could not be found: dependencies. Please create it before Dependabot can add it to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.

@pr-ai-review-coderflex

Copy link
Copy Markdown

@dependabot[bot] 🤖 Automatic review of commit d0877d5

Summary

This change bumps the dependabot/fetch-metadata GitHub Action used by the Dependabot auto-merge workflow from v2.5.0 to v3.1.0 — a single-line, major-version upgrade. Risk is low in blast radius (CI only) but non-trivial in kind, because a major version bump of an action can silently change or remove the outputs consumed by later steps of the same job, and the rest of the workflow file is not visible in the diff. Verdict: acceptable in principle, but it should not be merged until the upstream v3 release notes and the downstream steps in this workflow have been checked against each other.

Findings : 0 Blocker · 1 Major · 1 Minor

Findings

1. [Major] Major-version bump of an action whose outputs are consumed downstream, with no evidence of breaking-change review

  • Where: .github/workflows/dependabot-auto-merge.yml:16
  • Problem: The reference moves from v2.5.0 to v3.1.0, crossing a major version boundary. dependabot/fetch-metadata exists solely to publish outputs (update-type, dependency-names, dependency-type, package-ecosystem, …) consumed by subsequent steps via steps.metadata.outputs.*; major releases of this action have historically changed runtime requirements and deprecated/renamed outputs. The diff shows only the uses: line, so the steps that read steps.metadata.outputs.* are outside the visible hunk and cannot be checked for compatibility here.
  • Failure scenario: If v3 renamed or dropped an output referenced later in this job, the expression steps.metadata.outputs.update-type resolves to an empty string instead of erroring. The auto-merge condition (typically == 'version-update:semver-patch') then evaluates to false for every Dependabot PR, and auto-merge silently stops working — or, in the inverse case of an inverted condition, PRs get merged that should not be. Either way the breakage is invisible until someone notices PRs piling up.
  • Proposed correction: Read the v3.0.0 release notes/CHANGELOG of dependabot/fetch-metadata, confirm every steps.metadata.outputs.* reference in this workflow still exists with the same semantics and value format, and validate on one real Dependabot PR (or a workflow_dispatch dry run) before merging. If the workflow is not covered by such a run, hold the PR.

2. [Minor] Third-party action referenced by mutable tag rather than commit SHA in a workflow that holds a write-capable token

  • Where: .github/workflows/dependabot-auto-merge.yml:16
  • Problem: The action is pinned to the tag v3.1.0, which is mutable: the upstream owner (or anyone who compromises that account) can repoint the tag to arbitrary code. This workflow passes secrets.GITHUB_TOKEN to the action and exists to merge pull requests, so the executing code is in a privileged position.
  • Failure scenario: An upstream account compromise repoints v3.1.0 to malicious code; on the next Dependabot PR this repository executes it with the provided GITHUB_TOKEN, which can be used to exfiltrate the token's permissions or push/merge content, with no change ever appearing in this repository's history.
  • Proposed correction: Pin to the full 40-character commit SHA with the version as a trailing comment, e.g. uses: dependabot/fetch-metadata@<sha> # v3.1.0. Dependabot supports and keeps SHA pins updated, so this does not cost future automation.

What I checked, and what I could not

Checked, by reading the diff:

  • The scope of the change: a single uses: line, no changes to inputs, secrets, permissions, triggers or job structure.
  • Syntactic validity of the modified line and preservation of surrounding indentation and the with:/github-token: block.
  • The nature of the version jump (v2 → v3, i.e. a major bump) and its implications for output compatibility.

Not performed, and why:

  • No project review rules were available in this repository, so this review is against general engineering and CI-security practice rather than a project-specific standard.
  • I could not verify that the tag v3.1.0 of dependabot/fetch-metadata exists or what it points to. I have no network or registry access from a diff. If the tag does not resolve, every run of this workflow fails immediately with an "Unable to resolve action" error; this must be confirmed by an actual workflow run.
  • I could not read the upstream v3 release notes / CHANGELOG, so the presence or absence of breaking changes in outputs is asserted as a risk, not as an established fact.
  • I could not see the rest of .github/workflows/dependabot-auto-merge.yml (only the changed hunk is in the diff), so I could not enumerate which steps.metadata.outputs.* values are actually consumed, nor check the job's permissions: block.
  • I did not run any workflow, test suite or linter; no CI result for this branch was available to me.

Out of scope (pre-existing, not touched by this diff): the workflow's overall auto-merge policy, its permissions: scoping, and the pinning style of any other actions in the same file were not modified here and are not reviewed as findings.


The next pass will start from the next commit pushed to this branch.

No rule files were found in this repository, so this review used general engineering practice.
Reviewed from the diff: no command was run and no test was executed.

@pr-ai-review-coderflex

Copy link
Copy Markdown

@dependabot[bot] 🤖 Automatic review of commit d0877d5

Summary

This PR bumps the dependabot/fetch-metadata GitHub Action used in .github/workflows/dependabot-auto-merge.yml from v2.5.0 to v3.1.0, a major-version jump. Risk is low for the library's runtime code (CI-only change) but non-trivial for the auto-merge automation, which gates merges on this action's outputs. Verdict: mergeable after confirming the major upgrade does not change the outputs consumed later in the same workflow.

Findings count : 0 Blocker · 1 Major · 1 Minor

Findings

1. [Major] Major-version bump of fetch-metadata applied without validating the outputs the auto-merge step depends on

  • Where: .github/workflows/dependabot-auto-merge.yml:16
  • Problem: The change moves across a major version boundary (2.x → 3.x), which by semver signals breaking changes. This step is id: metadata, and in this workflow pattern the subsequent steps gate on steps.metadata.outputs.update-type / dependency-names. The diff changes only the version pin and shows no corresponding adjustment to the consuming steps, and the diff context does not include them, so I cannot confirm they are still compatible.
  • Failure scenario: If v3 renames, removes, or changes the semantics of an output (for example the update-type value strings), the if: condition in the auto-merge step silently evaluates against an empty or unexpected value. Either every Dependabot PR stops auto-merging (silent automation breakage, noticed only weeks later), or worse, a condition that was intended to restrict merges to patch/minor updates evaluates in a way that lets a major update auto-merge.
  • Proposed correction: Read the v3.0.0 release notes / migration section of dependabot/fetch-metadata and confirm each output referenced elsewhere in this workflow still exists with the same semantics; adjust the if: conditions if needed. Validate by letting this very PR run through the workflow and checking the metadata step output in the Actions log before merging.

2. [Minor] Third-party action referenced by mutable tag instead of an immutable commit SHA

  • Where: .github/workflows/dependabot-auto-merge.yml:16
  • Problem: The step pins dependabot/fetch-metadata@v3.1.0, a Git tag, which the upstream repository can move at any time. This workflow runs with secrets.GITHUB_TOKEN and drives automatic merging, so it is a privileged automation surface. The diff rewrites exactly this line, so it is the natural moment to harden the pin.
  • Failure scenario: If the upstream repository or a maintainer account is compromised, the attacker re-points the v3.1.0 tag to malicious code; the next Dependabot PR runs that code with the repository token and can auto-merge arbitrary content into main without any change landing in this repository.
  • Proposed correction: Pin to the full commit SHA with the version as a trailing comment, e.g. uses: dependabot/fetch-metadata@<40-char-sha> # v3.1.0. Dependabot supports and will keep updating SHA pins written this way.

What I checked, and what I could not

Checked:

  • The single changed line and its effect on the workflow step that produces the metadata outputs.
  • Whether the change is confined to CI (it is: no library, composer, or test file is touched, so no runtime behaviour of the package changes).
  • Supply-chain pinning practice for the changed uses: reference.

Not checked, and why:

  • No project review rules were available in this repository, so this review is against general engineering practice rather than a project-specific standard.
  • I could not verify that the tag v3.1.0 actually exists in dependabot/fetch-metadata, nor read its release notes or changelog; I cannot fetch remote repositories. Dependabot normally only opens PRs for versions it resolved upstream, so this is likely fine, but it is unverified here.
  • I could not read the rest of .github/workflows/dependabot-auto-merge.yml; the diff provides only four lines of context, so the exact steps.metadata.outputs.* references in the auto-merge step are inferred from the standard pattern, not observed.
  • I did not run the workflow, the test suite, or any command; I have no execution environment. The compatibility claim in finding 1 therefore remains a risk to confirm, not a reproduced failure.

Out of scope (pre-existing, not introduced by this diff): the file contains trailing whitespace on the surrounding blank lines, visible in the diff context but untouched by this change.


The next pass will start from the next commit pushed to this branch.

No rule files were found in this repository, so this review used general engineering practice.
Reviewed from the diff: no command was run and no test was executed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant