Add linting job in Rails pipeline to prevent Rails developers from using a too new Gitaly API version

Summary

To support independent deployment of Gitaly and Rails (as outlined in epic &20030), we need to prevent Rails developers from accidentally updating the Gitaly gem to a version that is too new, which would break the ability to deploy Rails before Gitaly.

Problem

When Rails and Gitaly can be deployed independently, Rails must not depend on Gitaly APIs that don't exist in the currently deployed Gitaly version. If the Gitaly gem in Rails is updated to a version newer than the deployed Gitaly servers, it could introduce calls to RPCs that don't exist yet, causing failures.

Proposal

Add a linting job to the Rails CI/CD pipeline that:

1. Monitors changes to the Gitaly gem in the Gemfile
2. When the Gitaly gem version is updated, compares:
   • Current Rails version
   • New Gitaly gem version
3. Enforces the policy: Gitaly gem must be one version behind Rails
4. Fails the pipeline if this constraint is violated

This would provide early feedback to developers during code review, preventing incompatible Gemfile changes from being merged.

Implementation Considerations

• Detect Gemfile changes in CI (e.g., using git diff on Gemfile or Gemfile.lock)
• Parse and compare semantic versions of Rails and Gitaly gem
• Define clear version comparison logic (e.g., Rails 17.7.0 should use Gitaly gem 17.6.x)
• Provide clear error messages when the lint check fails, explaining the version policy
• Consider edge cases (pre-release versions, patch updates, etc.)

Related Work

• Epic &20030 - Allow Gitaly Clients and Gitaly to be deployed independently
• &20030 (comment 2955060618)
• Related issues in the epic cover version handling and retry logic