Repository navigation
Conversation
There was a problem hiding this comment.
Changes I can see are fine and I think they will solve the issue. I cannot verify QUARKUS_PACKAGES_TOKEN usage as I don't have access or any knowledge about it (like its scopes), but that's what other reviewers are for.
Would be great if you got a test run (with your own token in your own fork) just to check if all works as expected.
Of course, I did that: https://github.com/Pepo48/keycloak/actions/runs/23622183737/job/68803640647 It's from my fork, so I created my own PAT with package:read scope. There is some failure still that I need to investigate (doesn't seem to be related to the scope of this PR though), but you can clearly see that the artiffacts are downloaded from maven.pkg.github.com - otherwise I would not even create this draft The question is though, how to proceed with this further and how we ended up in the situation, where we can't consume sonatype artiffacts anymore and yet we don't know whether and which alternative will be provided. I would leave it as a draft for now, until they make the final decision, but at the same time I think that cross-org consumption should be a big part of it. |
Ok, thanks. that failure: while I don't know why, it is strange that it uses
This PR basically follows the Quarkus contribution guide, it is fine as long as it works. If GH repo turns out to be slow, we can just build Quarkus locally, no biggie either way.
Right, I have no experience how big issue is to simply change it tomorrow if this turns out to be a bad solution, so I'll leave it to you to decide. I think you need to act to actually test Quarkus, but which steps you choose is your call. |
Closes: keycloak#47500 Signed-off-by: Peter Zaoral <pzaoral@redhat.com>
This actually happened because I have not realized that even though Before all Quarkus snapshots used to be n one place on Sonatype. I don't know whether this is intended or not, but for now I adapted the workflow to use both repositories. |
@gsmet @rsvoboda that's weird 😄 is that intentional?
Thanks, good catch at any rate. |
|
Hey there. So I pinged @rsvoboda about this change last week. For now, it's still experimental, I'm not sure if it's going to be better... Typically the deploy from tonight failed so it's unfortunately not fully reliable - but as all snapshot deployments to Sonatype were failing lately, it's not exactly hard to do better :). I will monitor the situation in the following weeks. |
|
Thank you @gsmet |
|
Just for the record, in order to verify is in your own fork, a PAT with When that is set, run the following: This will simulate the scheduled run. That's why Here's my re-run of Keycloak CI: https://github.com/Pepo48/keycloak/actions/runs/23683978268 (Quarkus UT failure corresponds to the one we already had with Sonatype, so in this context it is a good sign that confirms parity). The only thing that needs to be sorted out prior to merge is a project-level PAT - either we create a new one or I can reuse some existing one that already has |
|
hey @Pepo48 , thanks very much for your work so far. I think we need to skip to building Quarkus for now and go back when Quarkus snapshot deployment is stable. It is not a big issue as we said before - it is a nightly build after all. |
|
Surpassed by: #47892 |
|
Hey there, we have some news: @gastaldi worked on using GitHub releases to publish the snapshots and then we have an action that downloads them, and install them: https://github.com/quarkusio/install-quarkus-snapshots-action . On your side, you would use the action, and then make sure you use The README should contain all the information you need. Please test this approach and report back and that would reduce your testing time quite a lot. |
|
Thanks @gsmet ! |
Closes: #47500
Changes needed:
prepare-quarkus-next.shread:packagesscope)QUARKUS_PACKAGES_TOKENsecret in CI workflows