Use of GitHub Actions, and enable dependabot

[jbonofre]

Keep a backup of Jenkinsfile for now

[jbonofre]

I also integrated GitHub Action in the PRs.

[mattrpav]

I don’t think we should remove the unit test retry. @cshannon pointed that out as a good solution to get past some flaky tests and tests that fail when concurrent builds are running

[jbonofre]

@mattrpav ok I readd it. I will also use a different strategy for tests to use different jdk.

[jbonofre]

FYI, I enabled again Jenkins on PR. I will disable it only when GitHub Action will be happy.

[jbonofre]

Resuming this one 😄

[jbonofre]

Regarding the size of the matrix (2 ubuntu, 4 macos, 2 windows, with 3 different JDK versions), I propose:

1. In automatic mode (for each PR), I propose to do only Ubuntu 24.04 with just JDK 17
2. In nightly and/or on demand, I propose to do all the matrix (all OS, all JDK)

The purpose is to speed up build/test on PRs, and keep the "full pass" on nightly (on demand). Imho, 80% of the matrix is useless (macos, all windows version, ...).

Thoughts ? @cshannon @mattrpav @jeanouii

[jeanouii]

Personnally, I think it's a great PR and it demonstrates what we can do and the benefits.
That being said, I can see 2 cases (similar to you)

• Dev/pr: I'd only go for Ubuntu (1 version only) and JDK 17 (or 24). That's it.
  If we need to work with JDK 24 or 25, we can manually trigger it.

• nightly: we can go wider and test the 3 JDK, and Ubuntu / Windows
  I'm fine adding MacOS, but 4 versions (for 3 JDK) sounds like a big cardinality for a very small coverage of the real life. I think probably less than 1% of production deployments are on MacOS.
  We can keep 1 or 2 versions of Windows, if we want, but multiplied by 3 JVM, that's already at least 5*3 = 15 builds+tests

So overall, fully inline with you.

[jeanouii]

Great PR JB!
Few comments, FYI

I'm looking forward to see how quickly we can get results when other PRs are merged and how stable it will be.

This is overall a great investment for the future and will help us work better on deep functionalities like new JMS versions or Java 25 support

[jeanouii]

So close 3h28 as far as the HTTP module.

[INFO] Running org.apache.activemq.transport.amqp.interop.AmqpReceiverTest
Error:  Tests run: 25, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.187 s <<< FAILURE! -- in org.apache.activemq.transport.amqp.interop.AmqpReceiverTest
Error:  org.apache.activemq.transport.amqp.interop.AmqpReceiverTest.testTwoQueueReceiversOnSameConnectionReadMessagesAcceptOnEach -- Time elapsed: 0.074 s <<< FAILURE!
java.lang.AssertionError: expected:<4> but was:<3>
	at org.junit.Assert.fail(Assert.java:89)
	at org.junit.Assert.failNotEquals(Assert.java:835)
	at org.junit.Assert.assertEquals(Assert.java:647)
	at org.junit.Assert.assertEquals(Assert.java:633)
	at org.apache.activemq.transport.amqp.interop.AmqpReceiverTest.testTwoQueueReceiversOnSameConnectionReadMessagesAcceptOnEach(AmqpReceiverTest.java:490)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:299)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:293)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.lang.Thread.run(Thread.java:840)