[WIP] [DO NOT REVIEW] ci: replace Cirrus CI with GitHub Actions

[giuseppe]

Migrate all CI tasks from Cirrus CI (.cirrus.yml) to a new GitHub Actions workflow (.github/workflows/ci.yml). All tests run with the same conditions.

[mtrmac]

Cc: / FYI @timcoding1988

[Luap99]

Can we coordinate and discus such larger changes first please?

IMO container-libs should be moved under the podman CNCF org and then make use of the same "static VM images" approach we will design there.

Runtime installs like this proposing doing have been breaking us a lot historically and on a repo with such activity level like here I do not consider that useful nor is compiling several rust deps on each PR a useful for CI speed.

[giuseppe]

Can we coordinate and discus such larger changes first please?

IMO container-libs should be moved under the podman CNCF org and then make use of the same "static VM images" approach we will design there.

Runtime installs like this proposing doing have been breaking us a lot historically and on a repo with such activity level like here I do not consider that useful nor is compiling several rust deps on each PR a useful for CI speed.

sure, I close this one. Consider it only an experiment to see how far we could go using GHA.

[giuseppe]

IMO container-libs should be moved under the podman CNCF org and then make use of the same "static VM images" approach we will design there.

and if there is anything I can help with that effort, just let me know

[Luap99]

sure, I close this one. Consider it only an experiment to see how far we could go using GHA.

Ack, yeah I think in terms of test matrix and yaml template this is likely a good start and the path-filter thing looks really useful (what a shame that this is not a native feature...)

Overall I think we must be careful to not write to much scripts as part of github actions. Debugging this outside of CI will then always suck. My thinking is to have one general automation repo that creates "static" qcow2 images, fedora, debian like we have right now and then use the gh actions runner to run them as VMs.

Then we have a some generic test script/Makefile or whatever that starts the VM mounts the repo and runs the tests inside. Then all the general infra, create user, etc.. would be part of that script. So the GH action yaml should just call that with the right tests name/disto version...

And then a user could do the same locally to run tests in a proper env exactly like in CI.

and if there is anything I can help with that effort, just let me know

thanks will do

[Luap99]

@giuseppe Do you want to continue this with an appraoch like I have taken in podman podman-io/podman-sandbox#5

I think for the basic compile checks we can use the default ubuntu runners/go action to test compiles, but for the integration tests I think we should use the VMSs for a "clean env"

[Luap99]

Oh and as general rule I like to put as little into the github yaml in-line script as possible. I mean we always need to use some actions of course and install some deps there with is fine.
But like the pure test setup/start, and other things is best done in some scripts/Makefiles so users can resuse these locally to run the tests on their system if possible.

i.e. from my podman example any user who has lima installed can do ./contrib/ci/ci.sh int local root fedora-current to run the tests in the same way as CI easily if they want to debug things locally.