Gentoo CI: initial implementation

[tsunamaru]

This PR implements CI based on official Gentoo docker distribution.
Gentoo project already have internal CI, but AFAIK it's not running against pull requests in this repo. So I thought you may find it useful :)

Basically, this CI uses emerge sys-apps/openrc-9999 and overrides 2 variables pointing to repository and branch (EGIT_OVERRIDE_REPO_OPENRC_OPENRC, EGIT_OVERRIDE_BRANCH_OPENRC_OPENRC)

Currently, it builds against the following targets using GCC:

• glibc
• musl
• hardened-glibc
• hardened-musl
• nomultilib-glibc
• hardened-nomultilib-glibc

Building against clang also can be implemented, but of course it'll increase CI time drastically (now it builds just in 5-7 minutes).
Building with SELinux can't be implemented due to incompatibility in containers.

[vapier]

sorry, but i'm struggling to see the value this adds. it makes sure the 9999 Gentoo ebuild is always working with the latest OpenRC git tree ? but nothing else ?

it just seems like a pretty expensive set of operations to run just to validate the ebuild can compile the git repo. how long does each job take to complete ? i'm guessing it's many minutes.

what would be interesting is if we could verify things still boot correctly ...

[tsunamaru]

Hi @vapier! Thanks for raising concerns. I'll try to explain it.

it makes sure the 9999 Gentoo ebuild is always working with the latest OpenRC git tree ? but nothing else ?

Well, in short, the main idea behind this PR is to test it against different Gentoo setups. Yes, I picked 9999 ebuild for simplicity, because it's enforces Git clone, but in other ways there shouldn't be a real difference which ebuild is chosed. Now this is failing because I didn't properly check Git repo address for pull requests, but I'll fix it shortly tomorrow.

how long does each job take to complete ?

Just about 5-7 minutes. You can verify it on my fork actions: https://github.com/tsunamaru/openrc/actions

what would be interesting is if we could verify things still boot correctly ...

Technically no problem, we can use --init feature in docker to test if it starting properly.

Let me know if there any other questions or concerns from your side, thanks.

[williamh]

@tsunamaru Why do you need the following section:

        env:
          EGIT_OVERRIDE_REPO_OPENRC_OPENRC: ${{ github.server_url }}/${{ github.repository }}.git
          EGIT_OVERRIDE_BRANCH_OPENRC_OPENRC: ${{ github.head_ref

Do the default settings not6 work?

I'm also fine with testing the 9999 ebuild, that is what ci is supposed to test. I think testing whether openrc can "boot" is a bit out of scope.

[williamh]

@tsunamaru I just looked at the failures, and you should remove the env: section of your jobs. If you do that, it should work.

[vapier]

i know we're not paying for the resources, but it still doesn't feel like these are useful builders, and adding lots of them is just noise for people to ignore. at the very least, do we need 6 configs for a single ebuild when the USE flags don't change ?

up to WIlliam if he really wants to merge it.

I think testing whether openrc can "boot" is a bit out of scope.

strongly disagree. the only reason openrc exists is to boot systems. if we don't have test coverage that we can boot & run correctly, then it means our releases are never fully tested before being shipped to users. this is the entire point of a CI system.

[williamh]

@vapier I'm not opposed to boot testing or unit testing, I'm just not sure how to do boot testing. I think the tesst directory can be expanded to handle unit testing after I set up a way to point /run/openrc somewhere else for tests. That's a separate discussion from this pr.

[williamh]

@tsunamaru I think we only need the gentoo/glibc and gentoo/musl jobs, please remove the other 4 and I'll merge this.

[vapier]

i didn't say this PR had to do boot testing. i just mentioned that it would make things more interesting since this PR is about testing Gentoo specifically. building and running openrc unittests as a non-root user only goes so far.