chore: Bump gitaly gem to 19.4.0

Hunter Stewartrequested to merge
gitaly-19-4-remove-migrate-reference-backend into master

What this MR does

Bumps the gitaly gem from ~> 19.2 to ~> 19.4.0, re-syncs Gemfile.lock and Gemfile.next.lock, and deletes the dead client method Gitlab::GitalyClient::RepositoryService#migrate_reference_backend along with its two specs.

This is the first of two stacked MRs split out from the closed !255972 (closed), which mixed a gem upgrade with a bug fix. The stacked feature MR is !256649 (merged).

Why bump to 19.4

gitaly 19.4 adds a follow field to the ListCommits RPC (gitaly!9086 (merged)), which the stacked feature MR !256649 (merged) needs.

Why delete migrate_reference_backend

gitaly 19.3.0 removed the MigrateReferenceBackend RPC and its request/response messages. The Rails method was the only reference to those constants in the whole repo and had no callers; left in place it raises NameError for the missing request constant as soon as its spec runs.

Background

gitaly 19.3.0 dropped MigrateReferenceBackend in gitaly!9075 (merged) ("refs: remove all reftable migration code") because the WAL-based reftable migration it served was scrapped and never shipped, so the RPC had no users. This was the source of the original rspec unit pg17 failure on the closed MR.

Multi-version compatibility

This MR changes the gitaly gem, so both compatibility assertions are made explicitly:

  1. No REMOVED gitaly definition is still used on the Rails side. The 7 RPCs dropped between 19.2.0 and 19.4.0 (MigrateReferenceBackend, FindAllCommits, GetPartitions, JoinCluster, GetClusterInfo, SendMessage, SendSnapshot) were grepped repo-wide and none are referenced outside the migrate_reference_backend method being deleted here. RepositoryInfoResponse::ReferencesInfo::ReferenceBackend is a different, still-present symbol, so Entities::RepositoryHealth#reference_backend is unaffected.
  2. No NEW gitaly definition becomes used without a feature flag. This MR adds no new Rails usage of any new definition. The ListCommits.follow consumer lives entirely in the stacked MR !256649 (merged), behind a default-off feature flag.

Verification

Verified in a sandbox VM:

  • spec/lib/gitlab/gitaly_client/repository_service_spec.rb: 41 examples, 0 failures
  • RuboCop clean on the two changed Ruby files
  • Lockfile sha256 matches rubygems.org

Changelog

No changelog entry: internal client-method removal plus gem bump, not user-facing.

Edited by Hunter Stewart

Merge request reports