Hello, I'd like to add some high-level details of "the CI changes".
>From CI standpoint, adding kie-tools build into build-chain configuration for drools/optaplanner/kogito-runtimes/kogito-apps is possible. There would be adjustments needed for the examples to reference a "local" image created during the same CI build, but that should be fine. The execution times would be extended by the time needed to build kie-tools images due to repository changes up the stream (drools,...), but that's closing a serious gap we have in the builds, so I don't worry too much. What implications this would have on kie-tools pr-check/nightly builds I don't know, it's a different CI solution from the rest. But as mentioned by others here - we need to clarify what is our ultimate goal, which hugely affects CI. I have mentioned build-chain which is by many people regarded as (un)necessary evil. I just want to highlight that when we keep many repositories, then a solution without build-chain would be a non-trivial effort comparable to the initial CI configuration after the repository transfer. Which I do not volunteer for. Regards Jan On Thu, 9 Jan 2025 at 07:20, Paolo Bizzarri <[email protected]> wrote: > Hi Alex, > > I do not think this is the correct approach. > > If we have a window with a broken glass, we can decide to use a newspaper > to close the hole because we do not have the money to purchase a new glass. > But this does not mean that using a newspaper is a good strategy to fix a > window. > > So, first and foremost we should decide which is the ideal situation where > we want to move our repos - one repo, two repo, many repos. With ideal > situation I mean "what we think is the best architecture". > > Then we decide which steps we want to take in which direction. > > WRT resources - i.e. time of people for fixing this or that. It is very > hard to commit to "something" when it is not clear what is this > "something". In our case, it is hard for me to commit to "investigate CI > options" when it is pretty unclear which is the situation we want to > achieve. > > As far as I remember, there have been multiple threads in the past months > where it is pretty clear that there is no agreement on the general > structure of repos and dependencies. > > Let's clarify first this, and then move forward. > > Regards. > > Paolo > > On Wed, Jan 8, 2025 at 9:53 PM Alex Porcelli <[email protected]> wrote: > > > I'd agree to remove the link with tools if we'd remove the tools > > dependencies from the examples.... otherwise it creates the cyclical > > dependency - which was the reason Examples was excluded from the > > release. > > > > I'm also happy if anyone here volunteers to explore the adjustments > > needed in the CI suggested by you... I'm also happy with that. > > > > But in the end I expect that we get into a solution, in a way or > > another. I'd like to propose to use the general 72 hours (as commonly > > used in Apache) to see if we get any volunteers to take on CI work. If > > we can't get it, I'd suggest narrowing the options to either adjust > > examples (remove dependencies to artifacts produced by tools repo) or > > move the examples somewhere else. > > > > On Wed, Jan 8, 2025 at 3:41 PM Francisco Javier Tirado Sarti > > <[email protected]> wrote: > > > > > > I would argue that examples depend more directly on runtimes, apps or > > > drools than in tools or images, basically because a regression in tools > > > code will hardly make any example IT to fail, but a regression in > > runtimes, > > > apps or drools will certainly cause almost all examples to malfunction. > > In > > > fact, in most cases, tool dependency is just an optional add-on to the > > > example, it's not part of the core functionality of the example. A > proof > > of > > > that is that if the tool dependency is removed, most examples will > still > > > work (without the fancy graphical tool, but will still work). So, from > > that > > > point of view, it is kind of strange that examples are moved precisely > to > > > the repo they have the weaker link to (I'm not arguing to remove the > > > dependency because I feel tools are a pivotal part of the platform that > > > makes a difference and we want to showcase that in our examples). We > also > > > have a couple of examples that, trying to illustrate k8s usage (which > is > > > also pivotal, but not strictly needed, because the platform also runs > on > > > baremetal), are really required to be executed after everything else > has > > > been compiled, tested and deployed. > > > With that in mind, I think that moving stuff to the last repository in > > the > > > chain (because I guess that's the reason Tools was the chosen one) > should > > > be a kind of last resort, we need to explore the CI issue first. Maybe > it > > > is not that hard (for a person with enough knowledge of the internals > of > > > the CI pipeline, I'm clearly not that person) to execute examples at > the > > > end of the CI pipeline. And definitely branching examples repo for > > release > > > at the same time than the other repos should not be a huge problem > either > > > and I think it can be done independently of the CI order question. > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 8, 2025 at 8:17 PM Alex Porcelli <[email protected]> wrote: > > > > > > > Francisco, I think some clarifications are needed. > > > > > > > > By “properly maintained,” I’m referring to examples that are fully > > > > integrated into our CI pipeline and constantly updated to track the > > > > project’s versions, including release versions. In my view, ensuring > > > > that examples work not just with 999-SNAPSHOT but also released > > > > versions is critical. > > > > > > > > Regarding Snapshot Usage, while having examples automatically point > to > > > > 999-SNAPSHOT is helpful for early testing, we need to be cautious. > > > > Apache guidelines discourage the promotion of snapshot artifacts as a > > > > primary means of distribution. Hence, it’s important to offer > examples > > > > that align with actual release versions as well. > > > > > > > > Current CI Limitations, although the examples repo is nominally > > > > integrated into CI for the runtimes and apps, the setup is not > > > > functioning as intended. Many examples require DevUI or container > > > > images built in the kie-tools repository, which aren’t fully captured > > > > in the current pipeline. This makes it difficult to trust CI results > > > > entirely. > > > > > > > > And finally, my last proposal includes relocating the examples to the > > > > kie-tools repo (under an /examples folder) so they can be developed, > > > > built, and tested alongside the assets they depend on (DevUI, > > > > container images, etc.). And part of this move, I commit myself to > > > > adjust the release CI to produce a dedicated “examples artifact”. > This > > > > should resolve the dependency and version-sync issues while still > > > > allowing us to release the examples separately. > > > > > > > > I hope these clarifications help. Please let me know if you have any > > > > questions or concerns. > > > > > > > > > > > > > > > > > > > > On Wed, Jan 8, 2025 at 4:55 AM Francisco Javier Tirado Sarti > > > > <[email protected]> wrote: > > > > > > > > > > Hi Alex, > > > > > We need to define "properly maintained" ;). Currently, examples > repo > > is > > > > > integrated into the CI pipeline for runtimes and apps. This means > > that if > > > > > some change in runtimes or apps repos breaks an example, the PR > will > > be > > > > red > > > > > and won't be merged. > > > > > That's another layer of "security" from a quality perspective and > > forces > > > > us > > > > > to keep examples working. > > > > > They are also a good way for community users to test the latest > > changes > > > > on > > > > > main before they are released. If they checkout main branch, since, > > by > > > > > default, examples on main point to 999-SNAPSHOT version, they will > be > > > > using > > > > > latest snapshot, which is a good alternative for users that do not > > want > > > > to > > > > > wait for a release to perform experiments. > > > > > Therefore, I think your latest proposal is great. We keep > everything > > as > > > > it > > > > > is and release examples separately. > > > > > Thanks a lot. > > > > > > > > > > > > > > > > > > > > On Wed, Jan 8, 2025 at 1:17 AM Alex Porcelli <[email protected]> > > wrote: > > > > > > > > > > > Thanks for sharing your perspective, Francisco. You raise a valid > > > > > > point about user experience; however having a dedicated examples > > repo > > > > > > doesn’t necessarily help if it isn’t properly maintained—what’s > the > > > > > > purpose of an examples repository if it doesn’t reference the > > current > > > > > > release? > > > > > > > > > > > > One idea to address this, which we could borrow from our IBM > > > > > > colleagues, is to create a separate release artifact for the > > examples. > > > > > > We could then publish the artifact content into a dedicated > > repository > > > > > > manually whenever we cut a release. This way: > > > > > > > > > > > > - Maintenance & Integration: We still integrate the examples in > our > > > > > > main build process (so they remain aligned with each release). > > > > > > - User-Friendly Browsing: At the same time, the standalone > examples > > > > > > repository remains easy to browse, avoiding the complexity of a > > large, > > > > > > all-in-one codebase. > > > > > > > > > > > > This approach keeps the examples maintained in sync with releases > > > > > > while offering a simpler path for users to find and explore them > > > > > > without wading through the entire repository structure—which can > be > > > > > > overwhelming. > > > > > > > > > > > > I volunteer myself to adjust the CI to produce this artifact in > the > > > > > > release pipeline. > > > > > > > > > > > > On Tue, Jan 7, 2025 at 6:51 AM Francisco Javier Tirado Sarti > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > Hi, > > > > > > > I can see why it is easier, from a technical point of view, > since > > > > some > > > > > > > examples rely on tooling, to move all examples to tooling repo. > > > > > > > However, I hardly see why this makes users' experience better. > > > > > > > Let me elaborate, With examples repo, we currently have a place > > where > > > > > > users > > > > > > > can browse all examples starting from the repo root. > > > > > > > With tooling repo, I guess they will start browsing under > > examples > > > > > > > directory? > > > > > > > If we are going for technical simplicity, I guess it is > probably > > > > time to > > > > > > be > > > > > > > coherent and move all KIE content under the same repo (I'm not > > for > > > > it, > > > > > > but > > > > > > > I have the feeling that there is a majority in favour of that, > so > > > > > > probably > > > > > > > time to vote?). > > > > > > > Which I feel is really awkward is to have different strategies > > under > > > > the > > > > > > > same label (some content in some separate repos and gradually > > moving > > > > > > > everything to a repo named "tools" which is not really just > > "tools" > > > > > > > anymore) > > > > > > > > > > > > > > > > > > > > > On Mon, Jan 6, 2025 at 5:26 PM Jason Porter > > <[email protected] > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > I know it makes for a larger repo, but I’m all for fewer > > > > repositories, > > > > > > and > > > > > > > > an easier setup for not only contributors, but all users. > > > > > > > > > > > > > > > > -- > > > > > > > > Jason Porter > > > > > > > > Software Engineer > > > > > > > > He/Him/His > > > > > > > > > > > > > > > > IBM > > > > > > > > > > > > > > > > > > > > > > > > From: Alex Porcelli <[email protected]> > > > > > > > > Date: Monday, January 6, 2025 at 03:01 > > > > > > > > To: [email protected] <[email protected]> > > > > > > > > Subject: [EXTERNAL] [DISCUSS] Missing kogito-examples update > > for > > > > the > > > > > > > > 10.0.0 release! > > > > > > > > Happy new 2025, everyone! > > > > > > > > > > > > > > > > As we discussed when we started the 10.0.0 release process, > the > > > > > > > > kogito-examples repository was neither included in the > release > > nor > > > > > > fully > > > > > > > > integrated into CI. Although some PR checks consider > > > > kogito-examples, > > > > > > this > > > > > > > > gap ultimately led to absent examples for the 10.0.0 release. > > > > > > > > > > > > > > > > Currently: > > > > > > > > > > > > > > > > - The stable branch remains on versions 1.44 and 8.44 > > > > > > > > - The main branch is on 999-SNAPSHOT > > > > > > > > > > > > > > > > Given that many of the kogito-examples rely on container > > images and > > > > > > Dev UI, > > > > > > > > we'd need to incorporate the repository into our CI system to > > > > improve > > > > > > the > > > > > > > > current situation, which might take some time and will likely > > > > impact > > > > > > the > > > > > > > > upcoming releases. > > > > > > > > > > > > > > > > Alternatively, we could move the examples to kie-tools (a > repo > > that > > > > > > already > > > > > > > > hosts all images and DevUI) so no CI changes would be > required. > > > > > > > > > > > > > > > > I would love to hear your thoughts, alternative ideas, or > > concerns > > > > so > > > > > > we > > > > > > > > can have an actionable plan to do better in the next release. > > > > > > > > > > > > > > > > Regards, > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
