Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable caching for quarkus:build and declare dependencies as inputs #37622

Merged
merged 10 commits into from
Feb 16, 2024

Conversation

aloubyansky
Copy link
Member

@gsmet here are two commits:

  1. enhances the track-config-changes impl to also dump dependency checksums in target/quarkus-<profile-name>-dependency-checksums.txt, typically the profile name would be prod;
  2. enables dependency checksums dump for all the IT modules.

fyi @jprinet

@quarkus-bot quarkus-bot bot added area/devtools Issues/PR related to maven, gradle, platform and cli tooling/plugins area/documentation area/maven labels Dec 8, 2023
Copy link

github-actions bot commented Dec 8, 2023

🙈 The PR is closed and the preview is expired.

This comment has been minimized.

@gsmet gsmet force-pushed the dump-deps-from-track-config-changes branch from 11df920 to 217d8b4 Compare February 1, 2024 18:04
@quarkus-bot quarkus-bot bot added the area/infra-automation anything related to CI, bots, etc. that are used to automated our infrastructure label Feb 1, 2024
@gsmet gsmet changed the title Dump deps from track config changes Enable caching for quarkus:build and declare dependencies as inputs Feb 1, 2024
@gsmet gsmet force-pushed the dump-deps-from-track-config-changes branch 2 times, most recently from 0ecc4f8 to bc32f18 Compare February 1, 2024 18:12
Copy link
Member

@gsmet gsmet left a comment

Choose a reason for hiding this comment

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

Things seem to work with the changes I made.

Could you clarify again why it only works the third time? I somehow forgot about it.

return;
}

CuratedApplication curatedApplication = null;
QuarkusClassLoader deploymentClassLoader = null;
final ClassLoader originalCl = Thread.currentThread().getContextClassLoader();
Properties actualProps;
final boolean clearPackageTypeSystemProperty = setPackageTypeSystemPropertyIfNativeProfileEnabled();
try {
curatedApplication = bootstrapApplication(launchMode);
Copy link
Member

Choose a reason for hiding this comment

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

FWIW, I benchmarked things a bit and resolving the dependencies is quite slow. Even for a relatively simple IT as the Hibernate Validator one, it takes ~ 0.8 s.

Copy link
Member Author

Choose a reason for hiding this comment

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

It is, this is something i've been looking into for the last few weeks. But there is not much we can do especially for relatively simple projects, since most of the time is spent in the Maven artifact resolver itself.

However, the app model resolution will typically be necessary either way. It's about at which point it's performed. Here, we are moving this step to an earlier phase and it's cached for later phases if they get executed.

final List<String> deps = new ArrayList<>();
for (var d : curatedApplication.getApplicationModel().getDependencies(DependencyFlags.DEPLOYMENT_CP)) {
StringBuilder entry = new StringBuilder(d.toGACTVString());
if (d.isSnapshot()) {
Copy link
Member

Choose a reason for hiding this comment

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

I decided to avoid computing the checksum if the dependency is not a snapshot one. They should be immutable in this case.

Copy link
Member Author

Choose a reason for hiding this comment

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

Final versions could still be built locally. For example before releasing but not necessarily then.

@@ -22,6 +22,9 @@
<quarkus.build.skip>${skipTests}</quarkus.build.skip>
<native.surefire.skip>${skipTests}</native.surefire.skip>
<enforce-test-deps-scope.skip>true</enforce-test-deps-scope.skip>

<quarkus.config-tracking.enabled>true</quarkus.config-tracking.enabled>
<quarkus.native.container-build>true</quarkus.native.container-build>
Copy link
Member

Choose a reason for hiding this comment

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

Can you clarify why you added <quarkus.native.container-build>true</quarkus.native.container-build>?

Copy link
Contributor

Choose a reason for hiding this comment

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

This is required by the Quarkus caching extension to ensure native builds are as reproducible as possible and make caching consistent.

@gsmet
Copy link
Member

gsmet commented Feb 1, 2024

BTW, it wasn't terribly clear but I added a bunch of commits.

This comment has been minimized.

@jprinet
Copy link
Contributor

jprinet commented Feb 2, 2024

Things seem to work with the changes I made.

Could you clarify again why it only works the third time? I somehow forgot about it.

This is not true anymore, with the config dump cached/restored on the CI runner, the cache hit would occur on first run if inputs are identical.

You can check the initial explanation here

@@ -75,7 +75,7 @@ public class TrackConfigChangesMojo extends QuarkusBootstrapMojo {
/**
* Dependency dump file
*/
@Parameter(property = "quarkus.track-config-changes.dependenciesFile")
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 suppose to be completely consistent, it would have to be quarkus.trackConfigChanges.dependenciesFile

aloubyansky and others added 10 commits February 15, 2024 15:18
Non snapshot dependencies are supposed to be immutable so we can skip
computing the checksum.
When we don't have any previous recorded config properties, we should
push an empty Properties. At least, that's what
CodeGenerator.dumpCurrentConfigValues expects.
Add the dumped dependencies as an input for Surefire, Failsafe and the
Quarkus Maven plugin.
This reverts commit b3eeb7c.

In the end, it is not a very good idea to enable this for all of them.
@gsmet gsmet force-pushed the dump-deps-from-track-config-changes branch from bc32f18 to a171754 Compare February 15, 2024 14:18
Copy link

quarkus-bot bot commented Feb 15, 2024

Status for workflow Quarkus Documentation CI

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

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

⚠️ There are other check runs running, make sure you don't need to wait for their status before merging.

Copy link

quarkus-bot bot commented Feb 15, 2024

Status for workflow Quarkus CI

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

Failing Jobs

Status Name Step Failures Logs Raw logs Build scan
✔️ JVM Tests - JDK 17 Logs Raw logs 🚧
JVM Tests - JDK 21 Build ⚠️ Check → Logs Raw logs 🚧

Flaky tests - Develocity

⚙️ Maven Tests - JDK 17

📦 integration-tests/maven

io.quarkus.maven.it.DevMojoIT.testThatNewResourcesAreServed - History

  • io.quarkus.maven.it.DevMojoIT expected "60396444-67ee-4272-9ca7-ab592064c3fe" but was "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua." within 2 minutes. - org.awaitility.core.ConditionTimeoutException
org.awaitility.core.ConditionTimeoutException: io.quarkus.maven.it.DevMojoIT expected "60396444-67ee-4272-9ca7-ab592064c3fe" but was "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua." within 2 minutes.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.AbstractHamcrestCondition.await(AbstractHamcrestCondition.java:86)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:691)
	at io.quarkus.maven.it.DevMojoIT.testThatNewResourcesAreServed(DevMojoIT.java:967)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)

io.quarkus.maven.it.DevMojoIT.testThatNewResourcesAreServed - History

  • io.quarkus.maven.it.DevMojoIT expected "60396444-67ee-4272-9ca7-ab592064c3fe" but was "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua." within 2 minutes. - org.awaitility.core.ConditionTimeoutException
org.awaitility.core.ConditionTimeoutException: io.quarkus.maven.it.DevMojoIT expected "60396444-67ee-4272-9ca7-ab592064c3fe" but was "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua." within 2 minutes.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.AbstractHamcrestCondition.await(AbstractHamcrestCondition.java:86)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:691)
	at io.quarkus.maven.it.DevMojoIT.testThatNewResourcesAreServed(DevMojoIT.java:967)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)

zakkak added a commit to zakkak/mandrel that referenced this pull request Apr 4, 2024
Since quarkusio/quarkus#37622,
integration-tests/main sets quarkus.native.container-build to true
resulting in our CI building and testing it with the default builder
image instead of our Mandrel build.

It's yet not clear to me why this change was necessary (expecting an
answer in [1], but either way enforcing non-container-builds seems the
right thing to do in the CI when testing builds from source.

[1] https://github.com/quarkusio/quarkus/pull/37622/files#r1551481449),
zakkak added a commit to graalvm/mandrel that referenced this pull request Apr 4, 2024
Since quarkusio/quarkus#37622,
integration-tests/main sets quarkus.native.container-build to true
resulting in our CI building and testing it with the default builder
image instead of our Mandrel build.

It's yet not clear to me why this change was necessary (expecting an
answer in [1], but either way enforcing non-container-builds seems the
right thing to do in the CI when testing builds from source.

[1] https://github.com/quarkusio/quarkus/pull/37622/files#r1551481449),
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/devtools Issues/PR related to maven, gradle, platform and cli tooling/plugins area/documentation area/infra-automation anything related to CI, bots, etc. that are used to automated our infrastructure area/maven triage/flaky-test
Projects
Development

Successfully merging this pull request may close these issues.

4 participants