Fix pre-commit dependency group update-types rules issue

[AbhishekBhaskar]

What are you trying to accomplish?

Fixes #15266.

When a pre-commit dependency group uses update-types rules (e.g. minor/patch), the grouped update path logged "Nothing to update for Dependency Group" and then fell back to opening separate ungrouped PRs — so the grouped and ungrouped paths disagreed about whether updates existed.

The root cause is in semver_rules_allow_grouping? in updater/lib/dependabot/updater/group_update_creation.rb. It compared the raw dependency.version, which for pre-commit is a pinned git SHA (e.g. c6755bb…). version_class.correct?(sha) returns false, so the method returned false and silently dropped every dependency from the group. The ungrouped path never applies that filter, so it still raised individual PRs.

The fix makes semver_rules_allow_grouping? fall back to the checker's resolved current_version (which pre-commit derives from the # frozen: version comment / tag, e.g. 26.3.1) when dependency.version is not a comparable semver. This also benefits any other SHA-pinned ecosystem (e.g. github_actions) using update-types groups.

Anything you want to highlight for special attention from reviewers?

• current_version was private on Dependabot::UpdateCheckers::Base. I moved it to the public section (mirroring the already-public latest_version) so the updater can call it, and moved pre-commit's current_version override above its private keyword.
• The fallback only triggers when dependency.version isn't valid semver, so behavior for normal numeric-versioned ecosystems is unchanged.

How will you know you've accomplished your goal?

If the above linked issue is fixed and all existing and newly added specs pass.

Checklist

• I have run the complete test suite to ensure all tests and linters pass.
• I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
• I have written clear and descriptive commit messages.
• I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
• I have ensured that the code is well-documented and easy to understand.

[Copilot]

Pull request overview

Fixes a mismatch between grouped and ungrouped update paths when update-types rules are used for ecosystems (notably pre-commit) where dependency.version can be a pinned git SHA, by falling back to the update checker’s resolved comparable current version.

Changes:

• Update semver_rules_allow_grouping? to use a comparable “current version” (fallback to checker.current_version) when dependency.version isn’t semver-comparable.
• Expose Dependabot::UpdateCheckers::Base#current_version publicly (and adjust pre-commit’s override visibility) so the updater can call it.
• Add specs covering the SHA-pinned fallback behavior.

Show a summary per file

File	Description
updater/lib/dependabot/updater/group_update_creation.rb	Uses a comparable “current version” (with fallback) for update-types semver grouping decisions.
common/lib/dependabot/update_checkers/base.rb	Makes current_version publicly available and explicitly overridable for updater usage.
pre_commit/lib/dependabot/pre_commit/update_checker.rb	Ensures current_version override remains public and accessible (moves it above private).
updater/spec/dependabot/updater/group_update_creation_spec.rb	Adds unit coverage for semver grouping behavior when dependency.version is a SHA.

Copilot's findings

• Files reviewed: 4/4 changed files
• Comments generated: 3

[thavaahariharangit]

How will you group the last

7.3.0 -> 7.3.0

only commit sha going to be changed.

Where this will be grouped?

[AbhishekBhaskar]

The 7.3.0 → 7.3.0 case (only the commit SHA changed, no semver bump) will not be included in the group — and this is correct behavior.

In semver_rules_allow_grouping?, when current and latest versions are both 7.3.0, none of the segment comparisons trigger (major, minor, patch are all equal), so the method returns false. This means the dependency doesn't match any update-types rule (major, minor, or patch).

However, the update isn't lost — the ungrouped fallback path still picks it up and creates an individual PR (exactly what we saw in the original issue logs: flake8, from 7.3.0 to 7.3.0). This behavior is unchanged by this PR.

If a user wanted to include such "same-version SHA refreshes" in the group, they'd need to use a patterns rule without update-types:

groups:
  pre-commit-all:
    patterns:
      - "*"

[thavaahariharangit]

@AbhishekBhaskar To call this expected behaviour, we need supporting documentation. The question is: where is that evidence?

[thavaahariharangit]

Is Dependabot grouping supported for the github-actions ecosystem?

Based on the documentation, there is no answer — especially for GitHub Actions.

GitHub Actions use tag or SHA pinning, not manifest/lockfile semantics, so it’s unclear how semver‑based grouping would even apply when updates are driven by commit SHAs.

We need to find explicit documentation evidence confirming whether grouping is supported or intentionally excluded.

[AbhishekBhaskar]

@thavaahariharangit grouping with update-types is supported for github_actions and already works — independently of this PR.

The key difference from pre-commit is when the SHA-to-semver resolution happens:

Ecosystem	dependency.version after parsing	How grouping works
pre-commit	Raw git SHA (e.g. c6755bb…)	This PR's fix: comparable_current_version falls back to checker.current_version, which resolves via the # frozen: comment
github_actions	Already semver (e.g. "2.1.0") — resolved during file parsing via git_checker.version_for_pinned_sha	No fallback needed; dependency.version is already a valid semver

Since the github_actions file parser resolves pinned SHAs to semver tags during parsing (file_parser.rb L75-90), by the time semver_rules_allow_grouping? runs, it already has a valid version string. The pre-existing code path (version_class.correct?(dependency.version) → true) handles it directly without needing the fallback introduced here.

This PR's fallback only activates when dependency.version isn't valid semver — which is the case for pre-commit but not github_actions. So GitHub Actions grouping behavior is completely unaffected by this change.

[thavaahariharangit]

@AbhishekBhaskar Is there any Dependabot documentation that explains how semver grouping is handled for commit‑SHA?

When we review a PR, we evaluate it on three fronts:
– Are we doing the right thing
– Are we doing that thing right
– Is there a better way to do it

For the first point, I need concrete documentation that proves this behaviour is actually expected.