Hello Toshiya, Regarding the failures, it's caused by 2 things: 1. PR is targeted against the quarkus3 branch. 2. incubator-kie-kogito-apps doesn't seem to have that branch.
As a result buildchain command fails both in Jenkins and GitHub Actions, you can check similar checkout summary: # Checking out apache/incubator-kie-kogito-runtimes and its dependencies (4 projects in total). It can take some time. [INFO] Checking if apache/incubator-kie-drools is forked to tkobayas/incubator-kie-drools [INFO] Fork tkobayas/incubator-kie-drools does not exist. Trying to find a fork with a different name in tkobayas [INFO] Fork tkobayas/drools found from apache/incubator-kie-drools [INFO] apache/incubator-kie-drools checked out [INFO] Checking if apache/incubator-kie-kogito-runtimes is forked to tkobayas/incubator-kie-kogito-runtimes [INFO] Fork tkobayas/incubator-kie-kogito-runtimes does not exist. Trying to find a fork with a different name in tkobayas [INFO] Fork tkobayas/kogito-runtimes found from apache/incubator-kie-kogito-runtimes [INFO] apache/incubator-kie-kogito-runtimes checked out [INFO] Checking if apache/incubator-kie-kogito-apps is forked to tkobayas/incubator-kie-kogito-apps [INFO] Fork tkobayas/incubator-kie-kogito-apps does not exist. Trying to find a fork with a different name in tkobayas [INFO] Fork tkobayas/kogito-apps found from apache/incubator-kie-kogito-apps [ERROR] [apache/incubator-kie-kogito-apps] Error cloning apache/incubator-kie-kogito-apps and switching to target branch quarkus3 Moreover we're gonna have more issues in Jenkins, because currently your quarkus3 branch targeted PR is being executed using PR checks for main. Which might not be a problem right now, but would become one in case quarkus3 and main diverge in terms of pipeline implementation. It would be best to agree on a branch name - if it's quarkus3 - and generate special pipelines for that branch. So that we have clear separation. It would require branching of whole groups of repositories (similarly as above - incubator-kie-kogito-apps and others). Regards Jan On Thu, 23 Nov 2023 at 06:39, Toshiya Kobayashi <[email protected]> wrote: > Hi, > > > Just one doubt, Is there going to be a runtimes PR that we are going to > > have time to review? I was guessing how we can help Toshiba on that. > > PR is https://github.com/apache/incubator-kie-kogito-runtimes/pull/3290 > > As written in the PR comment, there are still several test failures. I'm > not yet sure if they (or some of them) are caused by my local environment > (RHEL 8, JDK17). > > Any help and thoughts would be welcome! > > Cheers, > Toshiya > > On Thu, Nov 23, 2023 at 1:03 AM Francisco Javier Tirado Sarti < > [email protected]> wrote: > > > Hi Mario, > > Thanks for the hard work and the lengthy description. > > Just one doubt, Is there going to be a runtimes PR that we are going to > > have time to review? I was guessing how we can help Toshiba on that. > > Thanks again > > > > On Wed, Nov 22, 2023 at 11:28 AM Mario Fusco <[email protected]> > > wrote: > > > > > Hi all, > > > > > > Sorry if I try to rush this, but weeks and months are passing and we > > > really really need to finalize the migration to Quarkus 3 asap. > > > > > > Yesterday I created a branch of Drools that bumps it to the latest > > Quarkus > > > (3.5.2), see > > > https://github.com/apache/incubator-kie-drools/compare/quarkus3 > > > > > > We're also discuss this on zulip ( please join the conversation here > > > > > > https://kie.zulipchat.com/#narrow/stream/381961-drools-dev/topic/Quarkus.203.20migration > > > ) and Alex noted that it would be probably better to migrate to the > > Quarkus > > > LTS instead. Personally I'm not strongly opinionated about this, even > > > though I don't see any relevant reason for us to stay on the LTS. I'd > > > rather prefer to stay on the latest stable quarkus release, especially > > for > > > the community version, and if necessary having a branch for product > that > > is > > > on the LTS instead. Anyway please also provide your feedback about this > > and > > > let's take a definitive decision on it. > > > > > > As you can read in that zulip thread, Toshiya is now trying to do the > > same > > > migration for kogito-runtimes, but neither him nor me are completely > > > knowledgeable on some parts of that project, so please try to be > > proactive > > > and help him if necessary. > > > > > > Regarding the migration of the Drools project, that was not > > > straightforward as I hoped also because the existing script was made to > > run > > > against an alpha version of Quarkus 3.0 and however its nightly build > > > didn't run for the latest 2 months or a little more. For this reason, > and > > > also because I don't want to go through this painfully long migration > > > process again, from now on I will consider that quarkus3 branch the > > drools > > > "effective main" branch. I don't expect any change in the drools code > > base > > > in the next days, but if we will have any I will forward port any > changes > > > to that branch. > > > > > > For the remaining part of this email I will list the issues that I > found > > > in the Drools migration and how I fixed them, hoping that this will be > > > useful also for the migrations of other downstream projects: > > > > > > 1. The internal Quarkus migration recipes have been moved to a > different > > > package, see > > > > > > https://github.com/apache/incubator-kie-drools/commit/6986ef910b5ab444adc61252b19cbed8531f91c5#diff-23f379d4198b67e1c8c6f0f41711b5bc41264a47aeac55858959c220d60798cfL15-R17 > > > > > > 2. Also the URL of the yaml file used by the Quarkus migration script > is > > > different, see > > > > > > https://github.com/apache/incubator-kie-drools/commit/6986ef910b5ab444adc61252b19cbed8531f91c5#diff-23f379d4198b67e1c8c6f0f41711b5bc41264a47aeac55858959c220d60798cfL48-R48 > > > > > > 3. The Quarkus migration also implies a bump of the JavaParser version > in > > > use. The only relevant difference that I found in our code related to > > this > > > is that the ClassDeclaration constructor is changed to accommodate the > > > sealed classes introduced in Java 17, see > > > > > > https://github.com/apache/incubator-kie-drools/commit/6986ef910b5ab444adc61252b19cbed8531f91c5#diff-7d5b9cbee13948b86436fc081410cb6d1a75870617072a40d66c5a6546f612f6L1416-R1418 > > > > > > 4. The Quarkus classloading mechanism is a little different now. The > most > > > relevant change is that the deployment and augmentation phases are > > clearly > > > separated and use 2 independent classloaders. Due to this change I had > to > > > introduce this fix > > > > > > https://github.com/apache/incubator-kie-drools/commit/6986ef910b5ab444adc61252b19cbed8531f91c5#diff-e6b9a9449de05f2b1a3a76adc52b3691319f9243350d1776f9d262fcf10a881aR50-R58 > > > that basically performs a lookup of a type of a variable of a rule unit > > in > > > the same classloader where the DataSource class has been loaded. > Without > > > this fix the method checking if that type is actually a DataSource ( > > > > > > https://github.com/apache/incubator-kie-drools/commit/6986ef910b5ab444adc61252b19cbed8531f91c5#diff-e6b9a9449de05f2b1a3a76adc52b3691319f9243350d1776f9d262fcf10a881aR67 > > > ) wouldn't work anymore thus preventing the rule unit to be correctly > > > complied. I honestly don't know if this fix could have some implication > > > downstream in kogito or more likely if it will have to be propagated > > > somewhere also there. > > > > > > 5. The same Quarkus classloading changes also required a fix in the kie > > > services lookup mechanism, see > > > > > > https://github.com/apache/incubator-kie-drools/commit/6986ef910b5ab444adc61252b19cbed8531f91c5#diff-030652eeecd63a0d44385d02b3c362fdda79600785d5e817380daf62e29d3cffL50-R50 > > > Actually there I implemented a hack to make Quarkus 2 to work (it was > > > necessary to perform the service implementations lookup in the same > > > classloader of the service interface) and I'm happy that this is no > > longer > > > needed. > > > > > > My goal is to have also kogito-runtime migrated to Quarkus 3 before the > > > end of this week and make those quarkus3 branches our main branches at > > the > > > beginning of the next. I understand that this would eventually break > > other > > > downstream projects, but I believe that it will be easier to fix them > and > > > anyway I don't see any alternative to push this forward. Please let me > > know > > > if you have any feedback or question on this. > > > > > > Thanks, > > > Mario > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > >
