:thumbsup:

@bookwar Does this run on all architectures?

@ngompa No, currently it is x86-only.

Our infra backend is Openshift on x86, on which we run qemu-kvm to setup vm with the test environment.

There is a work in progress to build additional backend to support multiarch. There is a team working on it, but the timeline is unclear yet.

[citest]

[citest]

@ngompa https://pagure.io/fedora-ci/general/issue/16

@bookwar Just curious, why do you choose to use dnf install over required_packages? What is the impact on side tag upgrades, will dnf install install from the side tag?

Consider also adding gating.yaml

Suggestion: require redhat-rpm-config and use gcc -x c $(rpm --eval %build_cflags) here to make sure the flag set is up to date and complete.

why do you choose to use dnf install over required_packages?

The difference is that when we use "required packages" and it fails, it does it on the preparation step of the pipeline in the internal ansible role. If it fails at run_tests.sh, it becomes part of the test.

So it mainly affects the way the failure is classified (as infra failure or test failure)

I somehow got the impression from ngompa's scripts, that installation of the annobin package is itself a test, rather then a preparation step.

But looks like i've just got confused, i'll move it to required_packages.

We also handle yum/dnf compatibility in that role, so it really makes more sense to not use dnf directly.

What is the impact on side tag upgrades, will dnf install install from the side tag?

When we test sidetag, the entire sidetag is added as an enabled repo to the test environment, so dnf will see packages from the sidetag.

When we test sidetag, the entire sidetag is added as an enabled repo to the test environment, so dnf will see packages from the sidetag.

Thanks for clarifying.

Please add a comment to the test itself describing its intent e.g. your comment earlier:

Build hello world program as a gating test for gcc

or maybe:

Gating test for gcc: ensure that we can build, link, and run a trivial "hello world"
C program.

This also serves as an integration smoke test for other parts of the toolchain (the assembler, linker, and annobin).

or somesuch.

Hope this is constructive (tests that don't document their intent are a pet peeve of mine)

I updated the patch with rpm macro and name for the test.

@dmalcolm I submitted this patch as an example, how one can transform test from CentOS variant to Fedora gating.

I expect it to be reworked as maintainers see fitting, renaming or reorganizing in the process.

If you name the test script runtest.sh, then you don't need the dir or run parameters. e.g. https://src.fedoraproject.org/tests/clang/blob/master/f/tests-clang.yml

If it will be only run on x86_64, then I don't see how it would help, the latest issues were aarch64 only.
As annobin seems to be installed during gcc build (but gcc intentionally doesn't use it during build), I've been wondering about performing those tests against annobin during %check and print the test status into the build.log.
I have scripts to download the build.log files and extract their testing result portion and compare against previous builds which I'm using as human decided gating test, so if such test is done in there, I'd see it for all arches. I guess I'd need to build with --skip-tag for rawhide then and tag manually (can package owner do that these days?) if it looks ok.

@nickc any suggestion on what would be appropriate tests?

If it will be only run on x86_64, then I don't see how it would help, the latest issues were aarch64 only.

I've seen this broken on x86_64 a few times, so I suppose even that would be very helpful. Many times a new gcc version-release is in the buildroot and until annobin is built, nothing else can be built. This gating test would prevent gcc from getting there if it doesn't work. A side tag would need to be used to ship and update that requires annobin rebuild, which brings me to...

I guess I'd need to build with --skip-tag for rawhide then and tag manually (can package owner do that these days?) if it looks ok.

I suggest building in a side tag and creating an update from that side tag if it looks OK.

side tag is very expensive way of doing it. I believe Nick has changed annobin to be much less dependent on the exact gcc version, so it is definitely not every build that is problematic, it should be fairly rare (and annobin should be improved to make it even rarer).
And I don't know upfront before the 1-2 days long gcc build if annobin will need to be bumped or not.

side tag is very expensive way of doing it

Expensive in what way?

And I don't know upfront before the 1-2 days long gcc build if annobin will need to be bumped or not.

Exactly, that's why I propose to do it in side tag.