workflows/vendor-gems: fail PRs with out-of-sync vendored gems

[p-linnane]

---

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them? Performance claims (e.g. "this is faster") must include Hyperfine benchmarks.
• Have you written new tests (excluding integration tests) for your changes? Here's an example.
• Have you successfully run brew lgtm (style, typechecking and tests) with your changes locally?

---

• AI was used to generate or assist with generating this PR. Please specify below how you used AI to help you, and what steps you have taken to manually verify the changes. Non-maintainers may only have one AI-assisted/generated PR open at a time.

---

Follow-up to #22065: #22059 merged with its Gemfile.lock ahead of the vendored tree because the vendor-gems.yml workflow silently no-oped. Root cause: github.event.pull_request.user.login is dependabot[bot], not dependabot, so the "Check out pull request", "Commit RBI changes" and "Push to pull request" steps added in aaefb35 have been skipped on every dependabot PR since. Fix the conditional so the workflow again pushes the regenerated vendor tree back, and add a final git diff --exit-code step that fails the check when the vendored tree / RBIs drift from Gemfile.lock — so a repeat of #22059 can't merge even if the auto-push ever fails.

Workflow-only change: ran actionlint .github/workflows/vendor-gems.yml and brew style --changed (both clean); skipped the full brew lgtm since there's no Ruby touched. AI (Claude Code) drafted the workflow diff from my description of the bug; I verified dependabot[bot] was the actual user.login against the GitHub API for PR #22059 before accepting the fix.

[Copilot]

Pull request overview

Updates the vendor-gems GitHub Actions workflow to (1) correctly treat Dependabot PRs as auto-updateable and (2) fail CI when the vendored gems/RBIs are not in sync with Gemfile.lock, preventing silent merges with mismatched vendor output.

Changes:

• Fix Dependabot detection by matching dependabot[bot] in if: conditions and the vendoring script.
• Add a final “vendored gems are in sync” check that fails PRs when the working tree differs after running vendoring/typecheck.

Comments suppressed due to low confidence (1)

.github/workflows/vendor-gems.yml:75

• The Vendor Gems step uses ${GITHUB_ACTOR} to decide whether to run with --no-commit. On Dependabot PRs that are re-run by a maintainer, github.event.pull_request.user.login is still dependabot[bot] (so the later commit/push steps will run) but GITHUB_ACTOR will be the maintainer, so this step will run with --no-commit and leave vendor changes uncommitted—causing the new sync check to fail and preventing the intended auto-push back to the PR. Consider basing this condition on the PR author/login (or github.actor in expressions) rather than GITHUB_ACTOR inside the script, e.g. pass a boolean via env: and branch on that.

        run: |
          if [[ "${GITHUB_EVENT_NAME}" == "workflow_dispatch" || ("${GITHUB_EVENT_NAME}" == "pull_request" && "${GITHUB_ACTOR}" == "dependabot[bot]") ]]
          then
            brew vendor-gems --non-bundler-gems
          else
            brew vendor-gems --non-bundler-gems --no-commit
          fi

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Bo98]

I suspect these auto-pushes won't trigger CI but worth a try.

Not sure about permissions. Might need to do is separate it into an isolated job based on an artifact uploaded here.

[p-linnane]

Will see what happens next time and iterate from there.

[MikeMcQuaid]

Thanks, makes sense!