Understand whether we can move all of CI to Github Actions

[flavorjones]

Context

Current CI configuration, and the advantages Concourse provides, are explained at https://github.com/sparklemotion/nokogiri/blob/25e7c49c87bda2cb1e2dd15677af11c74503dc04/CONTRIBUTING.md#how-continuous-integration-ci-is-configured

What problems would we solve by moving to GA?

• Appveyor is slow.
• The Concourse environment is relatively expensive to keep running.
• Knowledge of Concourse is low in the Ruby community.
• Easier integration of the Nokogumbo test suite (see Epic: merge Nokogumbo into Nokogiri #2204)

Goals of this issue

I simply want to build confidence that we can go all-in on GA, and remove either Appveyor or Concourse or both; so that I can accept PRs like #2011 without feeling like I'm spreading myself even-thinner.

Unknowns and risks

• How to use custom containers (e.g., rake-compiler-dock containers and the nokogiri-test containers)
• How to move large payloads between jobs (e.g., between gem-build and gem-install-and-test)
• How will GA perform on memory-intensive and CPU-intensive jobs like valgrind tests?
• Can we cover all the Windows use cases in GA? (MSVC, mingw, 32-bit, 64-bit ... ?)

I've started reading https://docs.github.com/en/actions/learn-github-actions/managing-complex-workflows

Related conversations / issues / PRs

• MSVC support #2015 (comment)
• Update Actions CI by MSP-Greg · Pull Request #2011 · sparklemotion/nokogiri

---

cc @MSP-Greg

[MSP-Greg]

@flavorjones

I sense your frustration here (and in past messages) with CI. GA is still missing features that exist in Travis & AppVeyor. Re the issues you've listed:

How to use custom containers (e.g., rake-compiler-dock containers and the nokogiri-test containers)

I haven't worked much with them. See https://github.com/ruby/ruby/blob/master/.github/workflows/compilers.yml for one example with a container.

How to move large payloads between jobs (e.g., between gem-build and gem-install-and-test)

I believe it can be done, but I haven't implemented it in GA. I have PowerShell scripts to build gems (and test the install) with AppVeyor, but those used one job. Being able to do so on GA and take advantage of parallel jobs would be useful.

How will GA perform on memory-intensive and CPU-intensive jobs like valgrind tests?

Without testing it, no idea. I've got some tests with Puma that generate 2k client connections, and they get processed in less than 2 sec. Not the best comparison, but...

Can we cover all the Windows use cases in GA? (MSVC, mingw, 32-bit, 64-bit ... ?)

Qualified maybe. Currently, MSVC is only available as a daily Ruby master build that is available on GA. 32-bit builds have been done by Lars (@larskanis), but they aren't included in the custom action (setup-ruby) normally used to setup Ruby on GA.

Summing up, I can't cite examples for everything you'd like to have in CI. Can most of it be done? I think so, given the OS limits of GA.

Moving whatever jobs can be done in GA might be a good start, and taking advantage of the high parallel job limit might speed up the CI. Once that's stable, start writing scripts for the more complex CI...

Lastly, some of the things you'd like to implement I'd also like to see done, possibly for use elsewhere. I'm interested in helping, but I've also got other obligations.

[flavorjones]

I'm experimenting with using custom images at flavorjones/calendar-assistant#186

[flavorjones]

OK, I've got a pretty good sense of how to use Github's Container Registry now; and I've got a calendar-assistant action to even build the container image consumed by the test suite action.

[flavorjones]

Note that #2226 shows valgrind is much faster on GA than it is in my concourse environment.

[flavorjones]

I'm confident that we can move everything to Github Actions except 32-bit windows. Closing this, will open a PR shortly.