Arvados

• source:services/api/Gemfile declares a dependency on the arvados gem, aka sdk/ruby.
• Ideally that dependency should mean each version of the API server depends on the same version of the arvados gem, because that's how all our interdependencies usually work.
• But the arvados-api-server package build wants to download all the gems it depends on.
• So to have a same-version interdependency, we would need to publish the arvados gem before building the arvados-api-server package.
• And right now our entire release process is ordered the other way around: distro packages, then gems.

The proper way to fix this would be: declare a code freeze on sdk/ruby, publish that gem, update services/api/Gemfile to depend on that version, then continue with a release as normal. While this does require some process shuffling, I think that's basically all it is. The Ruby SDK doesn't get much development these days and there's no reason to expect that to change in the foreseeable future. Never say never but I think the risk that we publish an arvados gem and then suddenly realize we want to push a last-minute fix before the rest of the release is pretty low.

The easiest thing to do is nothing, and just let this exception linger. By the same token, because the Ruby SDK gets so little development, the API server doesn't really need a lockstep version, just a recent-enough one, and this works okay. It's just a little awkward and a bad look.

The solution that would require the least process disruption but the most code would be to extend the arvados-api-server package build so it builds a development version of the arvados gem from source and bundles that with the package. Note this would require fussing with the packaged Gemfile.lock too.

We have had related deployment bugs caused by failure to keep our own Gemfile dependencies in step with our release process. See #22364.