Skip to content

Fix some additional build reproducibility issues in ArC#53088

Open
gsmet wants to merge 1 commit intoquarkusio:mainfrom
gsmet:arc-reproducibility
Open

Fix some additional build reproducibility issues in ArC#53088
gsmet wants to merge 1 commit intoquarkusio:mainfrom
gsmet:arc-reproducibility

Conversation

@gsmet
Copy link
Member

@gsmet gsmet commented Mar 16, 2026

No description provided.

@gsmet gsmet requested review from Ladicek and mkouba March 16, 2026 20:50
@quarkus-bot
Copy link

quarkus-bot bot commented Mar 16, 2026

Thanks for your pull request!

Your pull request does not follow our editorial rules. Could you have a look?

  • description should not be empty, describe your intent or provide links to the issues this PR is fixing (using Fixes #NNNNN) or changelogs

This message is automatically generated by a bot.

@quarkus-bot quarkus-bot bot added the area/arc Issue related to ARC (dependency injection) label Mar 16, 2026
@quarkus-bot
Copy link

quarkus-bot bot commented Mar 16, 2026

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit 2418c6e.

✅ 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.

Warning

There are other workflow runs running, you probably need to wait for their status before merging.

@github-actions
Copy link

🎊 PR Preview 77f4dbb has been successfully built and deployed to https://quarkus-pr-main-53088-preview.surge.sh/version/main/guides/

  • Images of blog posts older than 3 months are not available.
  • Newsletters older than 3 months are not available.

@quarkus-bot
Copy link

quarkus-bot bot commented Mar 17, 2026

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 2418c6e.

Failing Jobs

Status Name Step Failures Logs Raw logs Build scan
✔️ JVM Tests - JDK 17 Logs Raw logs 🔍
✔️ JVM Tests - JDK 21 Logs Raw logs 🔍
✔️ JVM Tests - JDK 25 Logs Raw logs 🔍
✔️ JVM Tests - JDK 25 Semeru Logs Raw logs 🔍
JVM Tests - JDK 17 Windows Build Failures Logs Raw logs 🔍
✔️ JVM Integration Tests - JDK 17 Logs Raw logs 🔍
✔️ JVM Integration Tests - JDK 17 Windows Logs Raw logs 🔍
JVM Integration Tests - JDK 21 Build Failures Logs Raw logs 🔍
✔️ JVM Integration Tests - JDK 25 Logs Raw logs 🔍
✔️ JVM Integration Tests - JDK 25 Semeru Logs Raw logs 🔍

You can consult the Develocity build scans.

Failures

⚙️ JVM Tests - JDK 17 Windows #

- Failing: extensions/panache/hibernate-orm-panache-kotlin/runtime extensions/panache/hibernate-reactive-panache-kotlin/runtime extensions/panache/mongodb-panache-kotlin/runtime and 2 more
! Skipped: extensions/panache/hibernate-orm-panache-kotlin/deployment extensions/panache/hibernate-reactive-panache-kotlin/deployment extensions/panache/mongodb-panache-kotlin/deployment and 5 more

📦 extensions/panache/hibernate-orm-panache-kotlin/runtime

Failed to execute goal org.jetbrains.kotlin:kotlin-maven-plugin:2.3.10:test-compile (test-compile) on project quarkus-hibernate-orm-panache-kotlin: Compilation failure Failed connecting to the daemon in 4 retries

📦 extensions/panache/hibernate-reactive-panache-kotlin/runtime

Failed to execute goal org.jetbrains.kotlin:kotlin-maven-plugin:2.3.10:kapt (kapt) on project quarkus-hibernate-reactive-panache-kotlin: Compilation failure Failed connecting to the daemon in 4 retries

📦 extensions/panache/mongodb-panache-kotlin/runtime

Failed to execute goal org.jetbrains.kotlin:kotlin-maven-plugin:2.3.10:compile (compile) on project quarkus-mongodb-panache-kotlin: Compilation failure Failed connecting to the daemon in 4 retries

📦 extensions/resteasy-reactive/rest-client-kotlin-serialization/tests

Failed to execute goal org.jetbrains.kotlin:kotlin-maven-plugin:2.3.10:test-compile (test-compile) on project quarkus-rest-client-kotlin-serialization-tests: Compilation failure Failed connecting to the daemon in 4 retries

📦 extensions/smallrye-reactive-messaging/deployment

Failed to execute goal org.jetbrains.kotlin:kotlin-maven-plugin:2.3.10:test-compile (test-compile) on project quarkus-messaging-deployment: Compilation failure Failed connecting to the daemon in 4 retries


⚙️ JVM Integration Tests - JDK 21 #

- Failing: integration-tests/elytron-security-jdbc 

📦 integration-tests/elytron-security-jdbc

Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.5.4:test (default-test) on project quarkus-elytron-security-jdbc-integration-test:

See /home/runner/work/quarkus/quarkus/integration-tests/elytron-security-jdbc/target/surefire-reports for the individual test results.
See dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream.
There was an error in the forked process

recorder.validateConfigProperties(
configProperties.stream()
.filter(ConfigPropertyBuildItem::isRuntimeInit)
.sorted(Comparator.comparing(ConfigPropertyBuildItem::getPropertyName))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gsmet Are you sure this helps? Because Collectors.toSet() is an unordered collector...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, this itself is useless AFAICT

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, it helped, I did numerous runs, but I agree it might have been by luck and I need to make the Set an ordered one.

Map<String, Function<SyntheticCreationalContext<?>, ?>> creationFunctions = new HashMap<>();
Map<String, Supplier<ActiveResult>> checkActiveSuppliers = new HashMap<>();

TreeMap<String, SyntheticBeanBuildItem> sortedBeans = new TreeMap<>();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH I don't understand this change. The ordering follows the ordering of List<SyntheticBeanBuildItem> syntheticBeans and the fact that we first store all beans in a sorted map would not make any difference, or?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The List<SyntheticBeanBuildItem> syntheticBeans is not ordered.

And when calling the recorders in random order, I had sometimes some changes in the ordering.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can probably find the diff back to help showing what I was trying to fix but it will require some archeology :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The List syntheticBeans is not ordered.

Isn't it? I thought that build steps are guaranteed to be executed in the same order 🤔.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, they are not guaranteed to run in the same order because of parallelism. But that's not the problem here.

What we guarantee is that their result will be contributed in the same order to the list of build steps. Which you would think would be enough in this case, except you can have the following in a build step:

for (element in my hashset/map) {
    create a synthetic bean build item
}

which happens, and then your order is not guaranteed.

I thought it would be better to enforce the order at this level rather than going through all the possible code paths creating synthetic beans and enforcing strong ordering there.

I'm not working on the simple project I was working until now, I'm iterating on all the quickstarts so you have all sorts of cases.

Also, I often have 3-4, sometimes 8 reproducible builds until I have one that is different.

Let me know if it makes more sense :).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

which happens, and then your order is not guaranteed.

Ah, I see. Basically, a build step can produce the SyntheticBeanBuildItems in random order.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is what I was trying to solve here:

Screenshot From 2026-03-17 18-17-14 Screenshot From 2026-03-17 18-18-27

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at MultiBuildItem javadoc, it says it gets injected in a sorted order if the MultiBuildItem implements Comparable. That sounds like a proper solution, instead of sorting on each use site?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at MultiBuildItem javadoc, it says it gets injected in a sorted order if the MultiBuildItem implements Comparable. That sounds like a proper solution, instead of sorting on each use site?

I have to admit that I completely missed this sentence in the javadoc of MultiBuildItem but it really looks like a proper solution. @gsmet WDYM?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/arc Issue related to ARC (dependency injection)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants