Hello, Regarding the PR check workflow - you could as part of your PR temporarily change/override the respective values and they should take effect for the particular PR only, shouldn't they? Regards Jan
Dne pá 4. 4. 2025 11:15 uživatel Fabrizio Antonangeli < fantonang...@apache.org> napsal: > Thank you Tiago for you suggestions and the env vars. > Yesterday, I created the CI on a personal fork: > > https://github.com/fantonangeli/kie-tools-fantonangeli-ghas/actions/runs/14247565814 > Unfortunately I had to stop the running when GH emailed me that I > consumed 100% of my personal Actions usage for the current month, so I > don't have a result to show ATM. > I will check if I can run this in a different account. > > > On Thu, 2025-04-03 at 09:20 -0400, Tiago Bento wrote: > > No need to worry about freezing the `main` branch because of the > > release process, as releases are done from a "minor stream" branch, > > like `10.0.x`, or `10.1.x`. > > > > To not stop the build/test process when a test breaks, you can use > > these env vars: > > - KIE_TOOLS_BUILD__ignoreTestFailures="true" > > - KIE_TOOLS_BUILD__ignoreEndToEndTestFailures="true" > > > > These env vars are already configured like this for checking commits > > on `main`, but on PRs we left it configured as `false` to fail > > faster. > > I agree, however, that for an effort like this it would be > > interesting > > to have the PR checks behave in the same way as well. Doing that in > > your personal fork is a great idea, though. > > > > As for your suggestions, unfortunately I think having everyone open > > "cherry-picks" to the PF5 upgrade branch would result in even more > > chaos, since conflicts only happen after a PR is merged on `main`, > > and > > it wouldn't be clear who would be solving conflicts when multiple PRs > > were merged together. Splitting the work between "partitions" is not > > a > > bad idea, we just need to find an easy way to split the repository > > into disjoint sets so that we can move the upgrade independently in > > each one of them. > > > > From my experience, the most efficient way is to have one person > > driving the upgrade effort with regular broadcast updates on > > completion state, combined with requesting authors of big PRs to hold > > merging them until the upgrade is done, if possible, and frequent > > merges of course. > > > > Regards, > > > > Tiago Bento > > > > > > On Wed, Apr 2, 2025 at 5:24 PM Fabrizio Antonangeli > > <fantonang...@apache.org> wrote: > > > > > > Hi Tiago, > > > > > > Thanks for your advice! We've been continuously merging from the > > > main > > > branch to keep the "delta" as small as possible. > > > > > > Please see my answers below. > > > > > > > > > On Wed, 2025-04-02 at 13:51 -0400, Tiago Bento wrote: > > > > Hi Fabrizio, > > > > > > > > Thanks for raising awareness of the issue! This upgrade is indeed > > > > very > > > > important since PatternFly is already on version 6! > > > > > > > > Having done some complicated upgrades myself in the past, I know > > > > how > > > > frustrating it can be to keep the upgrade branch up-to-date with > > > > other > > > > things being developed simultaneously. If it helps, my strategy > > > > was > > > > doing frequent merges to not let work accumulate. It's more or > > > > less > > > > fighting the clock, as the more time you take to make it stable, > > > > the > > > > less stable it gets due to other changes being merged in the > > > > `main` > > > > branch. You'll know if you're winning the race if you're ever > > > > able to > > > > get a green build, even if for a couple of hours without getting > > > > more > > > > conflicting code merged on `main`. > > > > > > > > My suggestion for you is to do frequent merges and keep regularly > > > > updating everyone else to know where you're being most impacted > > > > (package names, for example), so that people contributing to that > > > > package are aware that they can end up making this migration take > > > > longer, and if they can hold their PRs a little longer, they can > > > > help > > > > you indirectly. At the same, it helps everyone else if you're > > > > able to > > > > tell how close to completeness the PR is, so we can eventually do > > > > a > > > > 1-week stabilization period, for example, without merging > > > > anything > > > > else on `main` to make sure this upgrade is finally finished. > > > > > > Aditya has already upgraded all components using PF4. At this > > > stage, we > > > are focused on syncing and fixing issues. > > > Many packages have already passed the tests, while others were > > > successfully tested in an earlier stage. > > > > > > For future upgrades like this, I believe it would be useful to have > > > a > > > Build CI that can be triggered only manually on a specific branch > > > without stopping execution if a package fails. This way, we can get > > > the > > > test results for all packages. > > > As an alternative, I can also set up a CI job in a personal > > > repository > > > to gather the test results and share them with you. > > > > > > > > > > > > > Right now, if you're confident that the PR is very close to being > > > > ready and you were already able to get a green build (meaning > > > > that > > > > for > > > > a short period of time you had "everything working"), we can > > > > issue a > > > > freeze proposal here in the mailing list and have everyone > > > > contributing to `kie-tools` to hold their PRs until this upgrade > > > > is > > > > reviewed and merged. WDYT? > > > > > > > > > > I would avoid to freeze `main` branch (and maybe impact a release > > > process) and then have a blocker like for the Serverless Workflow > > > Chrome Extension, which is something that can happens in these > > > activities. > > > > > > > > > I would prefer to avoid freezing the `main` branch (which might > > > impact > > > the release process) and then potentially encountering blockers, > > > such > > > as the issue with the Serverless Workflow Chrome Extension, which > > > can > > > happens in these types of upgrades. > > > > > > Please, let me know what you think! > > > Regards > > > > > > > > > > > Regards, > > > > > > > > Tiago Bento > > > > > > > > On Wed, Apr 2, 2025 at 12:03 PM Fabrizio Antonangeli > > > > <fantonang...@apache.org> wrote: > > > > > > > > > > I totally agree freezing PF4 work is not really an option. > > > > > But it also quite difficult to forecast the closing time for > > > > > this > > > > > PR as > > > > > many "variables" are involved and there can be blockers not > > > > > related > > > > > to > > > > > our changes. > > > > > > > > > > For instance the ubuntu-1 GHA is currently failing because GH > > > > > web > > > > > UI > > > > > changed something and the Serverless Workflow Chrome Extension > > > > > is > > > > > not > > > > > passing the tests in this PR but also in this one, which is not > > > > > related > > > > > to our work: > > > > > https://github.com/apache/incubator-kie-tools/pull/3041 > > > > > I'm working on this fix. > > > > > > > > > > In addition to this, I think establishing a good way to handle > > > > > this > > > > > core activities will help us on the next ones as we still have > > > > > to > > > > > update React, Patternfly v6. > > > > > > > > > > On Wed, 2025-04-02 at 13:42 +0000, Jozef Marko wrote: > > > > > > Hi Fabrizio, as this is very crucial PR, I can imagine also > > > > > > we > > > > > > 'block' PRs that contain patternfly changes until the big PF4 > > > > > > -> > > > > > > PF5 > > > > > > PR is merged. I can imagine this only if we are confident > > > > > > enough > > > > > > PF4 > > > > > > -> PF5 PR will be merged in a week? or two weeks? Not sure > > > > > > what > > > > > > should be such 'blocking window' size. > > > > > > > > > > > > Personally, I can not imagine we do similar 'blocking > > > > > > window' > > > > > > longer > > > > > > than two weeks. Ideal 'blocking window' size doesn't exist > > > > > > for > > > > > > sure. > > > > > > We would probably agree - the shorter the better. > > > > > > > > > > > > > > > > > > Jozef Marko > > > > > > > > > > > > Software Developer > > > > > > > > > > > > jozef.ma...@ibm.com > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > From: Fabrizio Antonangeli <fantonang...@apache.org> > > > > > > Sent: Tuesday, April 1, 2025 4:00 PM > > > > > > To: dev@kie.apache.org <dev@kie.apache.org> > > > > > > Subject: [EXTERNAL] [PROPOSAL] Coordinating PatternFly 5 > > > > > > Upgrade > > > > > > Effort > > > > > > > > > > > > Hello all, > > > > > > > > > > > > Aditya and I are very close to finishing a PR for updating > > > > > > PatternFly > > > > > > to v5 [1]. The main problem we have is that while we update, > > > > > > fix > > > > > > issues, and run the CI, the work on the main branch using PF4 > > > > > > continues. This means we have to continuously sync our PR, > > > > > > update > > > > > > the > > > > > > new code to PF5, re-test, and check the CI. > > > > > > > > > > > > The CI also takes time to run, as all frontend packages use > > > > > > PatternFly, > > > > > > and the CI tests all of them. Once everything is green, > > > > > > reviewers > > > > > > may > > > > > > also need time to go through the PR (which includes 530 > > > > > > files), > > > > > > while > > > > > > in the meantime, PF4 development on `main` continues. > > > > > > > > > > > > Since I don't think we can freeze PF4 work until the PF5 > > > > > > update > > > > > > is > > > > > > completed, my suggestion is to establish a temporary "rule": > > > > > > > > > > > > Anyone developing PF4 code on main should also open a PR > > > > > > on > > > > > > Aditya's `allpackagesp4top5` branch with the corresponding > > > > > > PF5 > > > > > > update. > > > > > > > > > > > > This would be required only until the PR is reviewed and > > > > > > merged. > > > > > > > > > > > > Alternatively, can we "split" our work into SWF-related > > > > > > updates > > > > > > and > > > > > > Online Editor-related work? > > > > > > > > > > > > As always, I'm open to other ideas. > > > > > > > > > > > > [1] https://github.com/apache/incubator-kie-tools/pull/2853 > > > > > > > > > > > > > > > > > > ------------------------------------------------------------- > > > > > > ---- > > > > > > ---- > > > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------- > > > > > ---- > > > > > -- > > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > > > > ----------------------------------------------------------------- > > > > ---- > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > > > > ------------------------------------------------------------------- > > > -- > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > For additional commands, e-mail: dev-h...@kie.apache.org > >
