chore(deps): automate Gemfile.lock maintenance (phase 1)#34666
chore(deps): automate Gemfile.lock maintenance (phase 1)#34666torreypayne wants to merge 8 commits into
Conversation
Automate Gemfile.lock generation and periodic maintenance for compliance mandate https://b.corp.google.com/issues/509981628.
suztomo
left a comment
suztomo
left a comment
There was a problem hiding this comment.
Would you familiarize yourself with this zizmor tool? go/github-zizmor-help?polyglot=github-com#local-scans-run-zizmor-on-your-cloudtop It tells fixes for GitHub actions.
…s per zizmor audit
Installed, ran, and fixes applied! Thanks for introducing me to the tool 👍🏿 |
…get list Remove Gemfile.lock from root and Phase 1 gem .gitignore files so lockfiles can be tracked. Remove google-cloud-spanner from Phase 1 target matrix in generate-lockfiles.yml and renovate.json as it is hosted in ruby-spanner.
Restore Gemfile.lock in root .gitignore and use explicit !Gemfile.lock negation rules in Phase 1 libraries per reviewer recommendation. Remove third-party write action (generate-lockfiles.yml) to eliminate software supply chain risk in GitHub Actions runners. Check in initial Gemfile.lock files directly for Phase 1 libraries (google-cloud-core, google-cloud-storage, google-cloud-pubsub, google-cloud-bigquery, google-cloud-errors).
Update renovate.json syntax to use modern config:recommended and managerFilePatterns to restrict file scanning to the 5 Phase 1 libraries.
…raries Add negation matching rules (!google-cloud-core/**, etc.) with enabled: false to packageRules in renovate.json. This ensures that while Renovate discovers all Gemfiles during initial repository extraction, all 881 non-Phase 1 libraries are completely disabled and dropped from update evaluation.
torreypayne
added
the
do not merge
|
Will merge after holidays |
There was a problem hiding this comment.
Executed the Renovate CLI against the local filesystem in lookup mode (which parses configuration files and simulates dep lookup without repository writes):
npx -y renovate --platform=local --dry-run=lookupThe only generated diff was the standard Bundler metadata lines updating from 4.0.14 (the version @torreypayne used to commit the lockfiles) to 4.0.10 (the active Bundler version on my local environment):
diff BUNDLED WITH - 4.0.14 + 4.0.10
This confirms that the Gemfile.lock files in this PR are in sync with current dependency releases.
4 participants
Overview
This PR implements Phase 1 of the organization-wide compliance initiative to generate and maintain deterministic
Gemfile.lockfiles across Ruby client libraries (resolving b/509981628).For the full architectural strategy, throughput analysis, and multi-phase rollout cadence, please see the proposal document in Google Drive:
📄 Scale & Automate Dependency Security across Ruby Repositories (P1 Compliance)
Phase 1 Scope & Changes
Rather than attempting to generate and maintain ~880 lockfiles across
google-cloud-rubyin a single unmanageable PR, this PR establishes a hybrid automation architecture rolling out in manageable weekly batches:Renovate Lockfile Maintenance (
.github/renovate.json):bundle lock --updateruns (before 5am on monday).chore(deps): maintain Gemfile.lock files) in compliance with Ruby Cloud SDK team versioning rules.google-cloud-coregoogle-cloud-storagegoogle-cloud-pubsubgoogle-cloud-spannergoogle-cloud-bigquerygoogle-cloud-errorsBatch Generation Workflow (
.github/workflows/generate-lockfiles.yml):Gemfile.lockfiles in parallel batches without exceeding hosted runner container timeout limits.Rollout Cadence
google-cloud-[a-d]*)google-cloud-[e-o]*)google-cloud-[p-z]*)Reviewed and coordinated with @andreassa as part of the multi-phase compliance rollout.