Repository navigation
Build Quarkus from source in quarkus-next workflow - #47892
Conversation
| if: steps.quarkus-cache.outputs.cache-hit != 'true' | ||
| run: | | ||
| ./mvnw -B -e --no-transfer-progress \ | ||
| -Dquickly -Prelocations \ |
There was a problem hiding this comment.
| -Dquickly -Prelocations \ | |
| -Dquickly -Prelocations -Dno-test-modules \ |
|
Preliminary results here: https://github.com/Pepo48/keycloak/actions/runs/24165687191/job/70526677770 The failure is expected, see: #47895 |
Unreported flaky test detectedIf the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR. org.keycloak.testsuite.model.session.UserSessionProviderOfflineModelTest#testOfflineSessionLazyLoadingKeycloak CI - Store Model Tests |
4f6240b to
39f4568
Compare
Unreported flaky test detectedIf the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR. org.keycloak.testsuite.model.session.AuthenticationSessionTest#testConcurrentAuthenticationSessionsCreationKeycloak CI - Store Model Tests |
39f4568 to
9cd7c13
Compare
|
I added just a one small adjustment to make sure that cache is properly restored for PRs targeting |
Unreported flaky test detectedIf the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR. org.keycloak.testsuite.model.session.UserSessionProviderModelTest#testCreateUserSessionsParallelKeycloak CI - Store Model Tests org.keycloak.testsuite.model.singleUseObject.SingleUseObjectModelTest#testClusterKeycloak CI - Store Model Tests org.keycloak.testsuite.model.session.UserSessionInitializerTest#testUserSessionPropagationBetweenSitesKeycloak CI - Store Model Tests |
Closes: keycloak#47500 Signed-off-by: Peter Zaoral <pzaoral@redhat.com>
9cd7c13 to
78ec81b
Compare
| add_repository "pom.xml" "repository" | ||
| add_repository "quarkus/pom.xml" "pluginRepository" | ||
| add_repository "operator/pom.xml" "pluginRepository" | 8BD0||
| # Use io.quarkus:quarkus-bom built from source |
There was a problem hiding this comment.
AFAIU, the plain Quarkus BOM is different from the Quarkus Platform BOM, specifically it includes lower number of transitive dependencies. This might give us inaccurate results. Should we be building Platform too, not just the core Quarkus artifacts?
There was a problem hiding this comment.
We must use the core BOM. If it doesn't manage some deps, we would need to manage them for the snapshot scenarios manually. I don't think we should build the platform, because you can't be certain it gives you any advantage (e.g. you will probably want the latest released versions anyway). And you can never enforce that every platform dependency already adapted their main branch to the breaking changes in the core anyway (which is super edge case I guess).
There was a problem hiding this comment.
I don't remember for sure how is it, but I think if you have multiple BOMs it is order dependent, so if we still had platform bom there, it would use the platform versions. anyway, @Pepo48 will give the right answer.
There was a problem hiding this comment.
I didn't realize the fact there are other platform participants like Operator SDK, so good point at any rate.
There was a problem hiding this comment.
I guess you see why I did the switch at first place - the platform is built in a separate repo, so I didn't want to add any more complexity. I thought that the platform BOM doesn't actually override any core dependency versions - it just re-exports them and adds community extension deps on top. So for our purposes, based on my experience, testing against the core BOM vs the platform one shouldn't make a practical difference for catching breakages.
Actually, our historical data proves it as well. When it makes sense, I add "quarkus-next" label to the commit name - every single one of the issues I could filter out based on that were caused by a core Quarkus change (build step API, config, TLS, OTel, Micrometer, datasources, JOSDK version bump...). None were triggered by a platform-only dependency.
There was a problem hiding this comment.
I believe we depend on the Platform BOM with some dependencies in Keycloak (we omit explicitly defining their versions and just rely on the BOM), so I wonder how the quarkus-next build even works with the Core BOM that is missing those dependencies. Moreover, this might be a problem for the Operator, as stated correctly by Michal.
There was a problem hiding this comment.
I see. I guess the issue is that with the sed command in prepare-quarkus-next.sh I was targeting only the parent pom.xml and not operator/pom.xml too (+ the fact that the platform bom is still to this day published to Sonatype, see my earlier investigation at #47501 (comment) - https://central.sonatype.com/repository/maven-snapshots/io/quarkus/platform/quarkus-operator-sdk-bom/999-SNAPSHOT/maven-metadata.xml, but we don't know for how long).
So at this point you're right and our only viable is to build the platform from source too. Or wdyt?
There was a problem hiding this comment.
FWIW I agree (or think if that is not how @Pepo48 meant it) that only building Quarkus 999-SNAPSHOT core BOM and the operator sdk bom (or downloading it from the sonatype, but then we should postpone it to after it is deployed by their nightly) should cover 99 % of scenarios. It should be good-enough only for nightly tests as platform participants shouldn't override deps managed by core. Unless we know about some other dependency managed by other platform participant.
But I don't mind either way, and building platform, apart of raising the execution time will cover all scenarios. So I'll leave it to you to decide. Thanks for your investigation.
There was a problem hiding this comment.
LGTM.
To summarize an offline discussion, Platform BOM is apparently not strictly needed for quarkus-next (otherwise the build would fail) but we'll need to handle Operator differently. This will be handled as a follow-up.
Closes: keycloak#47500 Signed-off-by: Peter Zaoral <pzaoral@redhat.com>
Closes: #47500
Surpasses: #47501
This PR is following a recommendation from the Quarkus team - build the snapshot artiffacts on your own.
So for the needs of the
quarkus-next branchthe artifacts (~160 MB) are built directly from source and shared via cache. I introduced a prefix-based cache so thatci.ymlandoperator-ci.ymlcan pick up the999-SNAPSHOTartifacts when they run on the quarkus-next branch. Without an external repository like Sonatype before, we needed some way to pass them to the downstream jobs that quarkus-next triggers.Then I added a second, date-based cache in the build job itself after I realized a fresh Quarkus build takes about 30 minutes (based on the tests performed in my own fork). That's fine for the nightly scheduled run, but gets obnoxious fast when you're need to test something repeatedly on your own fork. With the date-based key, Quarkus is only rebuilt once per day and subsequent manual triggers just reuse the cache. If you need a fresh build sooner, you can force it by deleting the cache manually, e.g.
gh cache delete --repo Pepo48/keycloak quarkus-snapshot-2026-04-09.