[cchacs]

Fork-specific maintenance: configure monthly Dependabot version checks for github-actions at /. Minor/patch groups apply where versions can be classified; majors remain outside those groups. No auto-merge workflow is added.

Activation: GitHub requires Dependabot version updates to be explicitly enabled on forks under Settings → Advanced Security → Dependabot version updates. The setting has not been verified; merging this configuration alone is not proof that updates are active.

Coverage limits: mutable branch references such as reusable-ci.yml@main have no version for Dependabot to bump. Action groups can be forward-looking for floating major tags. Dependencies embedded in workflow commands are outside package-manifest coverage.

Validation: parsed YAML, checked unique targets and manifest locations, and ran git diff --check.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[pullfrog]

ℹ️ No critical issues — the config is valid and correctly scoped for this repo. One comment to reword, and two notes on what the grouping will and won't actually do in practice.

Reviewed changes

Single-commit PR adding .github/dependabot.yml (16 lines, new file) — the fork's first Dependabot configuration.

• github-actions target at /, monthly — the only ecosystem with anything to cover. Verified there are no manifests anywhere in the tree (package.json, requirements.txt, pyproject.toml, Cargo.toml, etc. all absent), so the PR body's "configured only where dependency manifests declare packages" is accurate.
• minor-and-patch group with patterns: ['*'] — folds all minor/patch bumps into a single PR. update-types is the load-bearing key here: a group defaults to all SemVer levels, so omitting it would have grouped majors too.
• PR cap of 5 open version-update PRs — correct as written, though it restates the Dependabot default (see nitpick).
• Header comment — the second line claims it preserves prior state that does not exist (inline comment).

Validation I ran: parsed the YAML and asserted the schema, confirmed no tabs / trailing whitespace / missing final newline, enumerated every uses: ref the ecosystem can see, checked for a pre-existing config to inherit from, and traced each ref through dependabot-core's github_actions package.

ℹ️ The minor-and-patch group has no members in this repo

Every uses: here is either a floating major tag (actions/checkout@v4, actions/checkout@v6, pullfrog/pullfrog@v0) or a branch ref (reusable-ci.yml@main), and Dependabot cannot produce a minor or patch PR from either shape. So the grouping cannot fire against the current dependency set — the config is correct, but the PR-noise reduction it buys is not yet real.

Technical details

# Group has no eligible members

## Affected sites
- `.github/dependabot.yml:11-16` — the `minor-and-patch` group; valid config, but unreachable for this repo's current refs.
- `.github/workflows/compliance.yml:35`, `:77`, `:120` — `actions/checkout@v4`
- `.github/workflows/pullfrog.yml:25` — `actions/checkout@v6`
- `.github/workflows/pullfrog.yml:29` — `pullfrog/pullfrog@v0`
- `.github/workflows/ci.yml:10` — `got-feedback/.github/.github/workflows/reusable-ci.yml@main`

## Required outcome
Nothing to change here. Recorded so the author knows the group is inert today and can decide whether real minor/patch coverage is the goal.

## Why, against dependabot-core `main`
- **Floating major tag** — `github_actions/package/package_details_fetcher.rb:80-86` returns `current_version` when `shortened_semver_eq?(dependency.version, latest_version.to_s)` holds. For `v4` against latest `v4.3.0`, `["4","3","0"][0..0] == ["4"]` is true, so no update is proposed while latest stays 4.x. The first proposal is `v4` -> `v5`, classified `SEMVER_MAJOR` by `updater/lib/dependabot/updater/update_type_helper.rb#classify_semver_update` (`curr_parts.major > prev_parts.major`; `GithubActions::Version#remove_leading_v` normalises `v4` to `4`). A `major` is excluded by this group's `update-types`.
- **Branch ref** — `github_actions/file_parser.rb:93` (`return unless git_checker.pinned?`) drops the dependency at parse time. `common/lib/dependabot/git_commit_checker.rb#pinned?` returns `false` for a real branch: `return true unless local_upload_pack&.match?(%r{ refs/heads/#{ref}$})` short-circuits, then `@consider_version_branches_pinned && version_tag?("main")` is `false`. Independently, `github_actions/update_checker.rb#updated_ref` has only a version-tag exit and a commit-SHA exit and returns `nil` otherwise. Maintainer-confirmed in dependabot-core#15578: "The behavior is unchanged for: branch refs like `@main`".
- Net: `reusable-ci.yml@main` — the workflow that actually runs the test suite — is permanently outside this coverage.

## Open question for the human
Do you want real minor/patch coverage? That requires pinning refs to a specific tag or a commit SHA (e.g. `actions/checkout@v4.3.0`, or `@<sha> # v4.3.0`), which trades the floating-tag convenience for a PR per release. Separate change, out of scope here.

ℹ️ Major bumps may not surface as individual PRs

The stated intent is that major updates stay separate for review, and that is the documented contract. But dependabot-core has an open bug report and an unmerged fix for exactly this config shape, where a patterns: ['*'] group limited to minor/patch can mark its pattern matches handled and suppress the major PR entirely. There is no config workaround, so the failure mode to watch for is silence when actions/checkout v5 lands.

Technical details

# Group-pattern suppression can silence the major PRs

## Affected sites
- `.github/dependabot.yml:11-16` — `patterns: ['*']` with `update-types: [minor, patch]` is the exact triggering shape.

## Evidence
- dependabot-core#14202 (open, 2026-02-17) — "Dependencies matched by group patterns are marked as 'handled' regardless of update-types, suppressing major version PRs". Analysis in-thread: `DependencySnapshot#mark_group_handled` marks `group.dependencies.map(&:name)`, i.e. every pattern match, and `ungrouped_dependencies` is `allowed_dependencies - handled_dependencies`, so updates the group's `update-types` rejects get a PR from neither path. The thread also records that this was fixed for NuGet (#14475) but not for the Ruby updater, and that "There is no configuration workaround."
- dependabot-core#16113 (open PR, 2026-08-31, "Fixes #14202", unmerged) — `GroupUpdateAllVersions` defers a group that already has an open PR, and the issue bites "as soon as the group has an open pull request — which is the steady state for a `patterns: ["*"]` minor/patch group".
- The picture is contested; #13154 reports similar symptoms attributed to a different root cause. Treat the mechanism as reported-and-unfixed rather than established.

## Mitigating factor for this repo
The trigger condition is an *open grouped PR*. Per the previous section, this repo's group should never open one, so the bug most likely will not fire here. This is a "don't be surprised by silence" note, not a claim that the config is broken.

## Open question for the human
None — no action is available from this repo. If `actions/checkout` v5 ships and no PR appears, dependabot-core#14202 is the first place to look.

ℹ️ Nitpicks

• open-pull-requests-limit: 5 is already Dependabot's default for version updates ("If five pull requests with version updates are open, no further pull requests are raised"). Spelling the default out is fine, but the PR body's "cap open version-update PRs at five per target" reads as a decision rather than a restatement.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Big Pickle (free) ｜ 𝕏}

[pullfrog]

Review #5361606117 threads checked. The only actionable comment (line 2 header nitpick in .github/dependabot.yml) was already addressed in commit a4685ff (updated the comment to describe the choice instead of claiming preserved prior state). All threads are resolved and the working tree is clean - no code changes needed.

  ^{｜ View workflow run ｜ via Pullfrog ｜ Using Big Pickle (free) ｜ 𝕏}