OMG, after a crazy number of commits, I finally got the tests to pass inside the ubuntu:14.04 container!

First, I had to remove localhost from the ::1 address in /etc/hosts. No idea why, but if the test suite tried to bind to localhost with ::1 in there, it would result in a "Cannot assign requested address" error. Then, after that, multi_client_test.cc was still giving me a "libtest/client.cc:273: Connection refused" error. I had a hunch that libtest::get_free_port() wasn't working properly inside the container, so I changed these lines:

  test->push_port(libtest::get_free_port());
  test->push_port(libtest::get_free_port());

to use a fixed port number:

  test->push_port( 19298 );
  test->push_port( 19300 );

And that worked! All tests passed. (I just picked the port numbers 19298 and 19300 at random.)

If anyone has any ideas on how to get the original code to work inside the container without this hack, let me know. Otherwise, I'm happy with it as-is.

Now to get clang builds working!

Between 6 months ago and now, all the Ubuntu 18.04 configurations stopped working. :sigh: I posted a message about it in the GitHub Actions community. I'm hoping someone there can help me fix it.

https://github.com/orgs/community/discussions/38963

P.S. Don't worry. I'll squash all these commits at some point. 😄

Well, I added sudo apt-get update && before my sudo apt-get install command, and that seems to have fixed these Ubuntu 18.04 builds. Kind of obvious in retrospect.

Then I tried to add an Ubuntu 22.04 build, and the bootstrap failed. 😞

https://github.com/gearman/gearmand/actions/runs/3454365941/jobs/5765614111

I guess we don't need to bootstrap on 22.04. As long as the release tarball compiles on 22.04, we're good to go in the short-term. Should I save adding the Ubuntu 22.04 build for later?

Changed the gcc-11 build to run on Ubuntu 20.04, and that worked around the 22.04 bootstrap problem. But then the make stage failed. That would presumably be fixed by @SpamapS 's PR #350.

@SpamapS: Two options:

(1) I remove the gcc-11 build from this PR and we merge it. Then you rebase PR #350 on master and add the gcc-11 build to the CI workflow in your PR.

(2) You merge PR #350 and then I rebase this PR on top. Less work, but it assumes PR #350 won't break any builds.

Which option do you prefer?

Lets just drop the gcc-11 and merge this. It's really fantastic and will help us move faster with future maintenance.

Rebased on master to pick up the gcc-11 fixes in PR #350. Squashed commits. All builds pass. The make test stages still need to complete, but I'm pretty confident they will. This PR is now ready for merge.

All make test stages completed and passed. Please merge.

Awesome and agreed on pushing 22.04 to later.