Bump underlying `ubuntu` to `22.04` LTS

[jeffwidman]

Depends on https://github.com/dependabot/dependabot-core/pull/5447

22.04 LTS dropped yesterday: https://ubuntu.com/blog/ubuntu-22-04-lts-released

I'm not sure of the GitHub internal infra, there may be security/infra reasons blocking this upgrade that are not visible to external contributors, but thought I'd at least open this PR to see what CI thinks.

[mattt]

@jeffwidman I just merged #5356, which should unblock us from upgrading to LTS. Can you rebase and try again with this PR?

[jeffwidman]

Thanks @mattt, just saw your comment.

Rebased!

[jeffwidman]

CI failures are because Ubuntu 22.04 uses OpenSSL 3.0, which requires Ruby >= 3.1... see https://github.com/ruby/setup-ruby/issues/333#issuecomment-1138406377.

The workaround is to manually compile openssl lib before installing Ruby... but that turns into quite the implementation rabbit-hole: https://github.com/rbenv/ruby-build/pull/1974

[jeffwidman]

So at this point, due to the problems with Ruby < 3.1 requiring an older OpenSSL than Ubuntu 22.04 ships, we have several options:

1. manually compile the relevant OpenSSL lib, and then somehow tell our downloaded Ruby how to use it... example: https://github.com/rvm/rvm/issues/5209#issuecomment-1192650802
2. Manually add a PPA with a pre-compiled OpenSSL (example), downgrade libSSL, then use that... feels very brittle though... esp given https://bugs.ruby-lang.org/issues/18658#note-2.
3. bump to Ruby 3.1, we need to do this anyway at some point, not sure how much work it is, or if we'd run into problems with GitHub internal infra... but we might be okay on the infra part since we're silo'd into our own docker image, IDK.
4. switch to using rbenv/ruby-build since at first glance it will "just work" due to https://github.com/rbenv/ruby-build/pull/1974. However, we originally went with ruby-install instead of ruby-build for some good reasons.
5. Wait a while, and see what shakes out further in the Ruby ecosystem... most of the open source discussions I've seen are within the past month, so I have a hunch waiting another 3-6 months will result in a bit more clarity/standardization on how others are dealing with this problem. Since I doubt most folks jumping to 22.04 will be willing/able to drop Ruby < 3.1...

Everything I've read so far makes it seem very brittle/painful to manage old OpenSSL versions, so I vote for working towards option 3 which will implicitly result in also picking option 5.

Thoughts?

[jurre]

I'm all for bumping the ruby version, @mattt's work on using ruby-install unblocks us, I think that's the main reason that we haven't done it yet, it should be a doable upgrade from my experience.

[jeffwidman]

Sounds good to me, I opened https://github.com/dependabot/dependabot-core/pull/5447 to bump to 3.1.

I think my main concern was that something internal within GitHub tooling that we may use now or in the near future may not be ready to support Ruby 3.1... but I suppose we can always try it and if we run into problems we can revert or push those teams to start providing support for 3.1... Anyway, we'll see how that PR goes.

[jurre]

GitHub tooling that we may use now or in the near future may not be ready to support Ruby 3.

Most internal things are on the latest or even pre-release versions of ruby and rails, dependabot, a bot that updates your dependencies, being on older versions is a cruel paradox

[jeffwidman]

Current CI failure:

The repository 'http://binaries.erlang-solutions.com/debian jammy Release' does not have a Release file.

Found this relevant issue, but no obvious easy solution.

[deivid-rodriguez]

I'm going to tentatively reopen this because I think it was closed automatically by mistake!

[jeffwidman]

I requested an update on the upstream issue: https://github.com/esl/packages/issues/15#issuecomment-1296378191

[jeffwidman]

Python failure is because 3.6.9 is specified in a test, and installing that breaks... it appears to be caused by openssl incompatibility, but I'm not 100% sure. The stackoverflow / mailing list threads I read were slightly inconclusive and it might be a byte alignment issue... apparently re-compiling manually with clang tended to solve it, but that's not really worth the trouble for us given that we plan to EOL Python 3.6 in April when Ubuntu 18.04 is EOL'd.

I'm trying 3.6.15 to see if a recent commit fixed it, otherwise will just have to put this on ice until April.

The cargo failure I'm not quite sure on... complaining about "create pull request was unexpected"... I'll sync with Jake when he is back from vacation.

[jeffwidman]

I requested an update on the upstream issue: esl/packages#15 (comment)

We may be able to continue using the Erlang PPA after all:

• https://github.com/esl/packages/issues/15#issuecomment-1446612343

[jakecoffman]

Should we update the Swift Dockerfile to install the 22.04 version?

[abdulapopoola]

Would this need to be updated too?

[abdulapopoola]

And this spec file too?

[jeffwidman]

Would this need to be updated too?

No, this is just testing a docker tag. In fact better if it test for a tag that isn't our image just to ensure there's no coupling.

And this spec file too?

Same as above, this is just a spec of a user's manifest... so their Ubuntu version shouldn't matter relative to our Ubuntu version.

That said, I really appreciate you and Jake for grep'ing for other references and double-checking this. I completely forgot to look for any others that crept in over the past year.

[jeffwidman]

And a year and a half later I can finally hit the 🟢 button! 😁