Fix some additional build reproducibility issues in ArC#53088
Fix some additional build reproducibility issues in ArC#53088gsmet wants to merge 1 commit intoquarkusio:mainfrom
Conversation
|
Thanks for your pull request! Your pull request does not follow our editorial rules. Could you have a look?
This message is automatically generated by a bot. |
Status for workflow
|
|
🎊 PR Preview 77f4dbb has been successfully built and deployed to https://quarkus-pr-main-53088-preview.surge.sh/version/main/guides/
|
Status for workflow
|
| 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)) |
There was a problem hiding this comment.
@gsmet Are you sure this helps? Because Collectors.toSet() is an unordered collector...
There was a problem hiding this comment.
+1, this itself is useless AFAICT
There was a problem hiding this comment.
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<>(); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
The List<SyntheticBeanBuildItem> syntheticBeans is not ordered.
And when calling the recorders in random order, I had sometimes some changes in the ordering.
There was a problem hiding this comment.
I can probably find the diff back to help showing what I was trying to fix but it will require some archeology :)
There was a problem hiding this comment.
The List syntheticBeans is not ordered.
Isn't it? I thought that build steps are guaranteed to be executed in the same order 🤔.
There was a problem hiding this comment.
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 :).
There was a problem hiding this comment.
which happens, and then your order is not guaranteed.
Ah, I see. Basically, a build step can produce the SyntheticBeanBuildItems in random order.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Looking at
MultiBuildItemjavadoc, it says it gets injected in a sorted order if theMultiBuildItemimplementsComparable. 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?



No description provided.