[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]

Important

Merging this is necessary but not sufficient: the repo is a fork, and Dependabot version updates are not enabled on a fork by the presence of dependabot.yml alone. A settings toggle is still required before any PRs appear.

Reviewed changes

Reviewed the one new file in this PR, .github/dependabot.yml (16 lines, commit 6011606), against the actual dependency surface of this repo's three workflow files.

• New .github/dependabot.yml — version: 2 with a single github-actions entry at directory: /, interval: monthly, open-pull-requests-limit: 5, and a minor-and-patch group covering every dependency by minor/patch update type. No pull-request/auto-merge block, so majors stay ungrouped and nothing merges itself.
• Ecosystem coverage is complete for this repo — there is no package.json, requirements.txt, or other manifest (tests run via node tests/screen.test.js), so github-actions is the only ecosystem that can be configured. The cross-org reusable workflow at ci.yml:10 is a supported target, so nothing in .github/workflows/ is missed. The file parses cleanly and matches GitHub's documented minimal form for this ecosystem.
• Two observations, neither blocking a code change — the fork enablement prerequisite below, and the comment wording flagged inline.

⚠️ Merging this will not, by itself, start Dependabot

This repository is a fork, and GitHub deliberately does not turn on version updates when a dependabot.yml lands on a fork's default branch. The practical consequence is that this PR merges, the config looks correct, and no Dependabot PRs are ever opened — so the stated goal of "enable Dependabot coverage" is silently unmet and compliance.yml's stale actions/checkout@v4 stays stale. Worth closing that gap in the PR description at minimum, so nobody later reads "config merged" as "coverage live".

Technical details

# Fork enablement is a settings toggle, not a config-file effect

## Affected sites
- `.github/dependabot.yml` — the whole file is inert on a fork until version updates are explicitly enabled
- repo setting: *Settings → Code security and analysis → Dependabot → Version updates → Enable*

## Evidence
- Repo is a fork: `GET /repos/get-flashbacks/feedBack-plugin-sectionmap` returns `"fork": true`
- GitHub Docs, *Configuring Dependabot version updates* → "Enabling version updates on forks":
  > "Version updates are not automatically enabled on forks when a dependabot.yml configuration file is present. ... On a fork, you also need to explicitly enable Dependabot."
  https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates
- GitHub Changelog, 2022-11-07, *Dependabot pull requests off by default for forks*:
  > "Starting today, if you fork a repository with an existing dependabot.yml, Version updates will be disabled by default. To enable Dependabot pull requests based on this configuration, you can click 'enable' from your forked repository's 'Code security and analysis' settings page."
  https://github.blog/changelog/2022-11-07-dependabot-pull-requests-off-by-default-for-forks

## Required outcome
Either the setting is enabled after merge, or the PR description states explicitly that a manual enable step is still pending. No code change is required in `.github/dependabot.yml` itself.

## Open questions for the human
- Was the setting already flipped on this fork? If so, this section is moot and the PR description should say so.

ℹ️ Grouping covers less of this repo than the PR description implies

Not a defect, but the grouping here does less work than the framing suggests: the repo has three distinct action dependencies total, one of which is branch-pinned, and the pre-existing version drift in compliance.yml is a major bump that the group deliberately excludes. If the point of this PR is Dependabot coverage, the manual actions/checkout@v4 → @v6 bump in compliance.yml:35,77,120 is the one gap worth closing today; the group will not surface it as a grouped minor/patch update.

Technical details

# The existing checkout drift is a major bump, outside the group

## Affected sites
- `.github/workflows/compliance.yml:35`, `:77`, `:120` — `actions/checkout@v4`
- `.github/workflows/pullfrog.yml:25` — `actions/checkout@v6`
- `.github/workflows/ci.yml:10` — `got-feedback/.github/.github/workflows/reusable-ci.yml@main` (branch ref, no SemVer for `update-types` to match)
- `.github/workflows/pullfrog.yml:29` — `pullfrog/pullfrog@v0`

## Required outcome
Decide whether the two-major gap between `compliance.yml` and `pullfrog.yml` is intentional. If not, a manual bump to `@v6` is a one-line change per job and does not need to wait for Dependabot.

## Notes on group reachability (verified, do not re-raise the refuted claim)
- A major-tag-pinned action ref is NOT limited to next-major bumps. Refuted by inspection: `guardian/gha-scala-library-release-workflow#130` is a real Dependabot PR bumping `actions/checkout@v6` → `@v6.0.2`. Whether that counts as `patch` for `update-types` filtering is **undocumented** — treat as inference only.
- `patterns: ['*']` alongside `update-types` is a documented, supported combination; no doc states AND vs OR, and there is no evidence it neuters `update-types`. Do not report it as a bug.

ℹ️ Nitpicks

• patterns: ['*'] adds nothing next to update-types: [minor, patch] — with a single group rule, update-types alone already says "every dependency, minor and patch only". Harmless, just redundant.
• open-pull-requests-limit: 5 is the schema default, so stating it is documentation rather than configuration. Fine to keep if the intent is to make the cap explicit.
• interval: monthly is a deliberate and sensible choice for a low-activity fork, but note it is slower than the weekly GitHub uses in its own examples.

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

[pullfrog]

✅ No new issues found.

Reviewed changes

Reviewed the delta since the prior pullfrog review (commit 8dc2d77, comment-only changes to .github/dependabot.yml plus the revised PR description).

• Rewrote the header comments — the old second line claimed the config "preserve[s] existing schedules and major-version restrictions", which was misleading given no dependabot.yml existed on main (confirmed: git ls-tree -r origin/main -- .github/ lists only ISSUE_TEMPLATE/ and workflows/). The new wording states what the file actually sets — monthly checks, majors outside the minor/patch group.
• Added a third header line scoping groups to version updates rather than security updates or merging, which matches the schema: applies-to is omitted, and GitHub documents the default as version updates only.
• PR description now carries the activation prerequisite and coverage limits — the fork settings toggle and the branch-pinned reusable-ci.yml@main reference are called out explicitly rather than left implicit.

I re-parsed the config and re-verified both new comment lines against the current schema (applies-to defaults to version updates; update-types: [minor, patch] excludes majors), and both are accurate. The header-thread concern from the previous review is resolved. The prior ⚠️ section is answered by the description's activation and coverage-limit paragraphs rather than by a code change, which is the outcome that section asked for.

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