Skip to content

chore: add a workflow that keeps google-apis-generator Gemfile.lock in sync - #28304

Open
zhumin8 wants to merge 4 commits into
mainfrom
sync-generator-lockfile
Open

zhumin8 wants to merge 4 commits into
mainfrom
sync-generator-lockfile

Conversation

@zhumin8

@zhumin8 zhumin8 commented Oct 28, 2026 •

Copy link
Copy Markdown
Contributor

The weekly API regeneration fails with "Git checkout is not clean" whenever google-apis-generator/Gemfile.lock is stale. That happens after a google-apis-core or google-apis-generator release, or a dependency change in their gemspecs, and needed manual fixes twice (#28168, #28303).

This adds a workflow that keeps the lockfile in sync:

  • Trigger: a push to main that changes the core or generator version.rb, their gemspecs, google-apis-generator/Gemfile, or the lockfile itself (to re-check after a sync PR merges). Also manual dispatch. Runs are queued, not run in parallel.
  • Action: toys sync-generator-lockfile runs bundle lock (without --update) in google-apis-generator/. If the lockfile changed, it opens a PR from yoshi-code-bot titled chore(generator): sync Gemfile.lock, unless one is already open.

Until auto-approve covers these PRs (follow-up), someone needs to review and merge them.

Tested locally: from the stale lockfile (google-apis-core 1.3.2), the tool produces exactly the lockfile from #28303; with an up-to-date lockfile it makes no change.

@zhumin8 zhumin8 changed the title chore: sync google-apis-generator Gemfile.lock after core and generator changes chore: add a workflow that keeps google-apis-generator Gemfile.lock in sync Oct 28, 2026
@zhumin8
zhumin8 marked this pull request as ready for review October 28, 2026 19:21
@zhumin8
zhumin8 requested a review from a team as a code owner October 28, 2026 19:21

@quartzmo quartzmo left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Min! I ran the tool locally from the lockfile before #28303 and got #28303's lockfile byte for byte, and a bundle install afterwards leaves it unchanged, so the Sunday regen should stay clean.

def open_pr_exists?
return false unless git_remote
require "json"
result = exec ["gh", "pr", "list", "--search", "\"#{COMMIT_MESSAGE}\" in:title",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I am reading this right, this search matches any open PR with this title, whoever opened it. The repo is public, so anyone could open a PR titled "chore(generator): sync Gemfile.lock" from a fork, and the sync would then skip until it's closed, bringing back the regen failure. Would adding --author @me work here? gh resolves @me to the token's user (yoshi-code-bot in the workflow), and --author combines with --search.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants