Identify Dependabot commits by author name in PR name prefixer

[somaz94]

What are you trying to accomplish?

Fixes #6968.

The PR name prefixer identifies Dependabot's own commits in order to (1) reuse the prefix style of the last Dependabot commit and (2) exclude Dependabot commits when sampling the repository's commit convention. For GitLab, Azure, Bitbucket, and CodeCommit it did this by matching the hardcoded support@dependabot.com author email.

As noted in #6968, that address is a pre-acquisition leftover that is no longer used for commits, and on self-hosted setups the author email is operator-configurable — so the email match silently fails. When it does, the prefixer can no longer reuse the last Dependabot commit's style, and Dependabot's own commits leak into the sample used to detect the repository's convention.

This switches those four providers to identify Dependabot commits by the bot author name (dependabot[bot]), which sidesteps the "which email is correct?" question entirely and is robust to the configurable/changed email.

Anything you want to highlight for special attention from reviewers?

• GitHub already identifies Dependabot commits by author name / bot type (author.name.include?("dependabot")), so this aligns the other four providers with that existing behavior rather than introducing a new mechanism.
• The now-unused private helpers dependabot_email, azure_commit_author_email, and bitbucket_commit_author_email are removed / renamed to their author-name equivalents. They were only referenced within pr_name_prefixer.rb.

How will you know you've accomplished your goal?

Added a regression spec: given a GitLab history whose latest commit is authored by dependabot[bot] with a fix(deps): prefix (and the current …@users.noreply.github.com email, not support@dependabot.com), the prefixer now reuses fix(deps): . Against the previous email-based code the same spec fails — it misses the commit and falls back to a generic build(deps): .

• bundle exec rspec spec/dependabot/pull_request_creator/ → 476 examples, 0 failures
• bundle exec rubocop on the changed files → no offenses

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.

[somaz94]

Marking this ready for review.

The substantive change is verified green: the common job (which builds and tests pr_name_prefixer), along with integration, Updater, and Lint, all pass.

The red ecosystem legs (bazel, bun, composer, hex, gradle, helm, julia, pub, python, terraform, pre-commit) all fail at the shared Build ecosystem image step — not in any test — on the base-image apt layer:

RUN ... curl -fsSL 'https://packagecloud.io/github/git-lfs/gpgkey' | gpg --dearmor ...
curl: (22) The requested URL returned error: 403

packagecloud.io is intermittently returning HTTP 403 for the git-lfs gpg key, which fails the layer before any test runs. The failing set shifts between runs (only cache-miss legs hit the 403 window), so this is flaky infra unrelated to this change. A maintainer re-run of the failed legs should clear them.

[somaz94]

Rebased onto latest main — the packagecloud 403 image-build flake is fully resolved (all ecosystem legs now build and pass).

The two remaining red checks are flaky python tests, not related to this PR's common/pull_request_creator/pr_name_prefixer change:

• ci (python, python, pip) → metadata_finder_spec.rb:511 "parses the matching project URL only once" — a Dependabot::Source.from_url call-count assertion that fails (got 0) when source_url is already memoized by an earlier example, i.e. a test-isolation/ordering flake under parallel runs.
• ci (python, python_slow, pip) → poetry_version_resolver_spec.rb:304 "resolvable only if git references are preserved" — a network/subprocess-backed Poetry resolution test.

Both pass on main's latest scheduled Specs run, so a re-run of the python legs should clear them. Happy to rebase again if anything drifts.

[somaz94]

The red checks here are pre-existing CI instability, not from this change.

• The diff is common/ only (pr_name_prefixer.rb + spec + a GitLab fixture), and ci (common) — the job that runs the changed spec — is green on every run.
• ci (python) fails on spec/dependabot/python/metadata_finder_spec.rb:511 ("parses the matching project URL only once", expected 1, got 0). This PR touches zero Python code, and the failure reproduces identically across reruns, so it cannot originate here.
• The other reds vary run-to-run (this run: ci (hex) → Hex.Registry.Server ... {:error, :eaccess} on lockfile update, plus npm_and_yarn / go_modules / nuget e2e registry smoke tests) — the signature of registry/environment flakiness rather than a code regression.
• For reference, the scheduled Specs workflow on main itself is red 4 of the last 5 days on varying jobs, which confirms this is repo-wide CI flakiness.

I rebased onto the latest main to trigger a fresh run; the failing set changed but ci (common) stayed green throughout. Could a maintainer confirm these are not merge-blocking (or point me at a known-flaky tracking issue if one exists)? Happy to rebase again once the infra settles.

[somaz94]

Gentle nudge on this one — it identifies Dependabot commits by author name in the PR name prefixer. The two failing legs look like flaky infra unrelated to the change (the prefixer tests pass); happy to rebase to re-run if useful. Thanks!

[somaz94]

Could someone re-run the ci (pub, pub, pub) job on this PR?

It is the only red check out of 151 (150 passing), and it looks unrelated to this change:

• The failing example is spec/dependabot/pub/update_checker_spec.rb:794 — expected Dependabot::DependencyFileNotFound but nothing was raised (160 examples, 1 failure).
• This PR only touches PrNamePrefixer's private commit-author matching for GitLab / Azure / Bitbucket / CodeCommit. Nothing in it is reachable from Pub::UpdateChecker#latest_version.
• The three sibling examples in the same when there is an error while running a subshell command context — git error, lockfile parse, version solving — all passed in the same run, using the same before stub and the same checker.
• ci (pub) is green on main and on every other recent PR.

I rebased onto latest main earlier today, which cleared the four bundler / npm_and_yarn / vcpkg failures that were showing before. Happy to rebase again if that is easier than a re-run.