Repository navigation
Build QOSDK from source in quarkus-next workflow - #48174
Conversation
Closes: keycloak#48129 Signed-off-by: Peter Zaoral <pzaoral@redhat.com>
We don't need them. |
We are testing Quarkus main branch, so you need matching QOSDK in case there are breaking changes where QOSDK was adapted to Quarkus. But I think you have a point, if there are (for us) breaking changes in JOSDK, we will see that, but we will only be able to fix the failures if there is backwards compatible solution. I think it is always going to be trade-off whatever way you decide to go. |
This is actually desired, and it was like that even before with the nightly snapshots built by the Quarkus team, no? We definitely want to test whatever comes in the next Quarkus release which includes QOSDK and transitively upgraded JOSDK.
This is unexpected, no? I would assume the platform will be using what's latest in the QOSDK main. |
|
@michalvavrik do you want to take one more look? |
Closes: keycloak#48129 Signed-off-by: Peter Zaoral <pzaoral@redhat.com>
Closes: #48129
@vmuzikar the build phase didn't fail previously because
quarkus.build.versionwasn't correctly changed to the SNAPSHOT. I fixed that by addingRestore Quarkus snapshot cacheto make it available and thus fully resolvable. Sinceset-quarkus-version.shsilently swallows the errors (afaik by design), I haven't realized/noticed it. Sorry for that.With that fixed, I got:
which is exactly what we discussed yesterday, even without evidence.
From what I see only 2 direct dependencies rely on
quarkus-operator-sdk-bomBOM -io.quarkiverse.operatorsdk:quarkus-operator-sdkandio.quarkiverse.operatorsdk:quarkus-operator-sdk-bundle-generator+ transitive JOSDK dependencies (operator-framework-core,micrometer-support).So as I mentioned yesterday, I wanted to try to build QOSDK instead of the full platform build. I did some digging - I compared
io.quarkus.platform:quarkus-operator-sdk-bom:3.33.1vs.io.quarkiverse.operatorsdk:quarkus-operator-sdk-bom:7.7.3:*-quarkus-platform-descriptorand*-quarkus-platform-properties- I assume this is not essential for our use case at all, most likely used by some Quarkus tooling, DEV UI maybe?) cc: @michalvavrikThis makes me believe that we could use it instead of full platform build. The PR builds QOSDK from its
mainbranch with-Dquarkus.version=999-SNAPSHOT. It producesio.quarkiverse.operatorsdk:quarkus-operator-sdk-bomwith the current QOSDK snapshot version (the version is dynamically parsed from the QOSDK pom.xml in order to inject it tooperator/pom.xml). Uses released JOSDK, which is handy, because we don't need to build JOSDK from source as we were afraid. And most importantly it takes ~20 seconds.The only difference I can see now is that
quarkus-nextbuilds QOSDK from main, so the actual versions tested will be newer than production, which probably isn't that big of a deal (!?). Alternatively we can try to build it from a release tag, but I haven't try that so far. The fact that the JOSDK version on QOSDK main is always equal to or newer than the JOSDK version in the platform BOM is probably more important, right?Anyway, this is the best I could come up with so far, so please give it a thorough look. 😊
Here are some preliminary results from my fork testing:
PRs that needs to be applied to get such results are:
(this actually proves that both are ready to be merged, without them in place the Keycloak build and Azure stage would fail pretty early)