Use dependabot to manage github action versions in generated projects

[holly-cummins]

It's a bit tedious for quarkiverse extension owners to deal with warnings about deprecated versions of github actions and manually update them in my quarkiverse project. Since we generate a workflow file as part of the template, and also a dependabot file, I don't see a downside to having dependabot manage the actions versions.

What do others think?

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 79b3bc4.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

---

Flaky tests - Develocity

⚙️ JVM Tests - JDK 21

📦 extensions/micrometer/deployment

✖ io.quarkus.micrometer.deployment.binder.VertxConnectionMetricsTest.testConnectionMetrics - History

• event executor terminated - java.util.concurrent.RejectedExecutionException

java.util.concurrent.RejectedExecutionException: event executor terminated
	at io.netty.util.concurrent.SingleThreadEventExecutor.reject(SingleThreadEventExecutor.java:931)
	at io.netty.util.concurrent.SingleThreadEventExecutor.offerTask(SingleThreadEventExecutor.java:350)
	at io.netty.util.concurrent.SingleThreadEventExecutor.addTask(SingleThreadEventExecutor.java:343)
	at io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:833)
	at io.netty.util.concurrent.SingleThreadEventExecutor.execute0(SingleThreadEventExecutor.java:824)
	at io.netty.util.concurrent.SingleThreadEventExecutor.execute(SingleThreadEventExecutor.java:814)
	at io.vertx.core.impl.EventLoopExecutor.execute(EventLoopExecutor.java:35)

📦 extensions/smallrye-reactive-messaging-kafka/deployment

✖ io.quarkus.smallrye.reactivemessaging.kafka.deployment.dev.KafkaDevServicesDevModeTestCase.sseStream - History

• Assertion condition defined as a Lambda expression in io.quarkus.smallrye.reactivemessaging.kafka.deployment.dev.KafkaDevServicesDevModeTestCase Expecting size of: [] to be greater than or equal to 2 but was 0 within 10 seconds. - org.awaitility.core.ConditionTimeoutException

org.awaitility.core.ConditionTimeoutException: 
Assertion condition defined as a Lambda expression in io.quarkus.smallrye.reactivemessaging.kafka.deployment.dev.KafkaDevServicesDevModeTestCase 
Expecting size of:
  []
to be greater than or equal to 2 but was 0 within 10 seconds.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
	at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)

[gsmet]

So +1 but it's weird CI didn't fail as I would have expected some codestarts to fail? Or maybe this file is not included in the files we test?

[holly-cummins]

So +1 but it's weird CI didn't fail as I would have expected some codestarts to fail? Or maybe this file is not included in the files we test?

I just did a search in independent-projects/tools/ and there's no mention of dependabot except in dependabot.yml, and no mention of the content of the file, except, again, in the file. Actually, there's no tests at all in independent-projects/tools/base-codestarts. I guess independent-projects/tools/codestarts/src/test/java/io/quarkus/devtools/codestarts/CodestartProjectGenerationTest.java is where the content checking happens, but it doesn't check this file:

        assertThat(targetDirectory.resolve("README.md")).hasContent("Base readme world y");
        assertThat(targetDirectory.resolve("config.properties")).hasContent("foo.bar=baz\nfoo.foo=bar\n");
        assertThat(targetDirectory.resolve(".gitignore")).hasContent("base-ignore1\nbase-ignore2\n");
        assertThat(targetDirectory.resolve("a/.tooling-t")).hasContent("a/.tooling-t");
        assertThat(targetDirectory.resolve(".tooling-t")).hasContent(".tooling-t");
        assertThat(targetDirectory.resolve("ybuild.build")).hasContent("fooa\n\nbara\n\nappend test");

(which is probably fine, IMO, otherwise we'd just be writing things down in two places and the overwhelming cause of test failures would be intentional changes.)