Add MacOS M1 runs to incremental builds

[holly-cummins]

I have set up a self-hosted runner on a Mac Mini which can now start running builds. Before this PR is merged, we will need to adjust the quarkus repository settings to wire in the runner.

As a first pass, I've added the runner to the JVM matrix in the incremental build.

• We may also want to add it to the native matrix since that could be a place where we see lots of errors
• We only have a single machine, so if the load is too high, we may want to move M1 to a less widely used workflow, or a lighter set of tests within the incremental CI workflow, or put a condition on its execution. However, I saw that the ubuntu builds Java 17 took 3 hours and the M1 build took 1 hour (and got further), so we may find that having the fast M1 machine serving build requests is a good way for contributors to get fast feedback.

I disabled some linux-specific steps which are not currently run on windows, so skipping them on mac should also be safe. (Although I wonder about the mongodb one, and whether we should find a platform-agnostic way to stop it if it leaks).

https://github.com/holly-cummins/quarkus/actions/runs/2798189377 has build output for my PR, on a runner I attached to my fork. The M1 build did not succeed, which isn't totally surprising because we know we have a range of issues on that platform (which is why we want an M1 build!). However, it got about as far as the ubuntu Java 17 build. Both seemed to fail in the first extensions test suite they ran.

The M1 failure was in mongodb, which makes me a bit nervous that stopping mongo will be needed in some way, especially since self-hosted-runners don't run on a fresh machine each time. I think it might be helpful to iterate on that while the M1 facility is available, to start building up some coverage of how often we see failures and where else they are. For example, I'm surprised I didn't see #25230 in the Actions build.

[holly-cummins]

Merging of this is paused pending adding the M1 runner, which is paused pending quarkusio/quarkus-github-bot#256.

[holly-cummins]

I've added an extra set of rules which leverage quarkusio/quarkus-github-bot#256 to control what PRs are allowed to run on the runners. This helps secure both the new M1 runner and the existing hosted runners.

This should be ready to merge; if we get the sequencing wrong and merge too early, the worst consequence is that we start to build up a backlog of requests on the M1 runner.

[gsmet]

@holly-cummins have you seen the macOS build is pending?

[holly-cummins]

I wasn't planning to enable the M1 runner until the repo workflows were locked down and bot configuration was pushed. To allow the timing of the two things to be more separate, I'll pull the bot configuration changes out into another PR.

[holly-cummins]

See #27899 for the bot changes, which should be merged first.

[holly-cummins]

Another nearly clear run on M1: just this failure, which seems to me to be a brittle test. The output is the same as the expected, except for the order of parameters:

[Check failure on line 19 in integration-tests/smallrye-config/src/test/java/io/quarkus/it/smallrye/config/AppConfigTest.java](https://github.com/quarkusio/quarkus/commit/b06790ddd8dd7357595cb5b9785790a1277d1d3d#annotation_4644614958)

@quarkus-bot quarkus-bot / Build summary for b06790ddd8dd7357595cb5b9785790a1277d1d3d

JVM Tests - JDK 17 MacOS M1

java.lang.AssertionError: 
1 expectation failed.
Response body doesn't match expectation.

java.lang.AssertionError: 
1 expectation failed.
Response body doesn't match expectation.
Expected: is "AppConfig{name=app, info=Info{count=10, alias=alias}}"
  Actual: AppConfig{name=app, info=Info{alias=alias, count=10}}

	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)

[holly-cummins]

(I'll re-run to confirm the smallrye-config failure is intermittent/unrelated-to-m1, and to incorporate the latest changes.)

[holly-cummins]

Same smallrye config failure on the next run, so I have disabled and raised #28057.

[holly-cummins]

The main action run, https://github.com/quarkusio/quarkus/actions/runs/3083733398 is clean, and ran M1. In the run on my fork, https://github.com/holly-cummins/quarkus/actions/runs/3083733139, there's a test failure on windows, but the important thing is that M1 was not run. (We want to run M1 on PRs, but we do not want to run M1 on forks, since forks are very unlikely to have a self-hosted M1 runner attached to them.)

The changes include

• Enabling the M1 workflow
• Adjustments to preprocess the job matrix to exclude M1 on forks
• Disabling some tests which failed on Mac(see comments above). Several of these tests have fixes merged, which we can validate once this changeset has merged.