Bump ruby version to ruby 3

[sethboyles]

[#2619]

Co-authored-by: Seth Boyles sboyles@pivotal.io
Co-authored-by: Alex Rocha alexr1@vmware.com

[sethboyles]

This supercedes #2623

[FloThinksPi]

Based on the unit test github actions workflow i guess the unittests did not actually run with neither ruby 3.0.3 nor 2.7.2 but with ruby 2.7.5 https://hub.docker.com/layers/capi/cloudfoundry/capi/ruby-units/images/sha256-42cb7efe67a2354d1456f54d218fdfe4e7185de69271a89d6511645444c2fbf3?context=explore

I would propose to use a more generic base image and install the used ruby version based on the .ruby-versions file dynamically in the action job (like its done with ruby gems already)

[sethboyles]

Yeah, we have a PR to update the dockerfiles: https://github.com/cloudfoundry/capi-dockerfiles/pull/18/files

Installing the ruby version based on the .ruby-version file is a good idea, but I wonder how much time that would add to our test runs.

[moleske]

The mysql8 checks ran with ruby3 per the ruby setup job

this is because the mysql8 github action does not use the docker image and instead runs directly on the github provided ubuntu machine. It also reads from ruby version file to determine the version of ruby to use. It probably wouldn't be too bad to switch the rest of the github actions to run like the mysql8 one, but does open the question that it would be different than how concourse runs the tests

[FloThinksPi]

Yea that uses the setup-ruby action which likely just downloads a binary as it just adds 4s. Would love to see that and then also no additional image may be required since https://github.com/cloudfoundry/capi-dockerfiles/blob/b8b3a8702f645a96861fac4ab8a72d7c1b0d0f15/capi-runtime-ci/Dockerfile#L10-L32 should also just add a few seconds to the job. Would make the CI setup a lot easier and flexible.

One question to the ruby update itself, why is the large amount of adoptions to brackets and double splatter operators of the WIP PR not needed anymore here ?
https://github.com/cloudfoundry/cloud_controller_ng/pull/2623/files#diff-8c147d0121d57d3714f83453ae1f79b5e943700ae6825b7912659750729d15adL126

[sethboyles]

but does open the question that it would be different than how concourse runs the tests

The original idea was to use the OCI image that we use in concourse, so we aren't surprised by failures occurring upon merging PRs. It's probably enough just to run units for now, but it would also be nice to figure out how to get a similar change in the concourse pipeline

One question to the ruby update itself, why is the large amount of adoptions to brackets and double splatter operators of the WIP PR not needed anymore here ?

Those were merged into main ahead of time: #2651. There were a few other PRs breaking out other changes, too.

[MMisoch]

Hi, I run the CATs with the changes introduced in this PR on our Azure dev-landscape and they ran through just fine. I run the version v7.3.0 of the CATs which is the latest release. I patched the changes into capi-release 1.127.0. I run the test twice as the first one got some flakey errors which where gone the second run. Tests took about 2 hours and I basically used the example-CATs-config. We could not find any anomalies in blobstore operations in particular as this seems to be the most interesting part here.
We will now continue on our Alicloud dev-landscape as soon as possible and give feedback on those as well.

[MMisoch]

Hi all,
CATS on the Alicloud Dev-landscape are done. Once again I run v7.3.0 of the CATs. I patched the changes into capi-release 1.127.0 and still used the example-CATs-config basically. There were no noticeable problems introduced with Ruby 3.
We will now continue on our AWS and GCP dev-landscape and update the PR again soon.

Best Regards

[sethboyles]

@MMisoch thanks for the update. Should we just merge? We have GCP and AWS blobstores in the main CAPI pipeline, so those will get tested regardless. We can revert if there are particular issues.

[MMisoch]

Hi all,
CATS on the GCP Dev-landscape are done. This time I used v7.4.0 of the CATs. I patched the changes into capi-release 1.127.0 once again.
On GCP there were also no noticeable problems.
@sethboyles I think we should go ahead and merge as you suggested.

Best Regards

[MMisoch]

We had a short internal discussion and were wondering if it would be possible to cut a release that only contains the ruby 3 changes and not other changes as well.
What is your opinion about that?

Best regards

[sethboyles]

That sounds fine to us. Do you all mind orchestrating that?

[MMisoch]

We could do that no problem. We would just need to wait for the next release and do the ruby3 one on top of that.

[sethboyles]

@MMisoch just wondering, did you all test to see that similar issues to #2748 didn't arise when deploying?