Hi all, I would like to quote: "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".
There is a similar thread where we have been asked to approve a given proposal without having defined the overall strategy for code-base management. The lack of a clear architecture goal, IMO, affected a lot of our decisions, that at a given point became "unavoidable" while, actually, they were not. So, to further the previous remarks, before going on with this discussion, there are two topics to tackle once and for all 1. multiple repo vs mono-repo (global concern) 2. What is exactly the scope of our examples ? (specific to this thread) About the latter, we also had a longish thread last summer, about "standalone" or similar, that basically ended up on nothing because, if the scope of something is not commonly clear and agreed upon, then it is impossible to get to a commonly shared solution. Best Gabriele Il giorno gio 9 gen 2025 alle ore 08:43 Jan Šťastný <jstastn...@apache.org> ha scritto: > 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 <pibi...@gmail.com> 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 <a...@porcelli.me> 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 > > > <ftira...@redhat.com> 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 <a...@porcelli.me> > 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 > > > > > <ftira...@redhat.com> 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 <a...@porcelli.me> > > > 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 > > > > > > > <ftira...@redhat.com> 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 > > > <jpor...@ibm.com.invalid > > > > > > > > > > > > > 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 <porce...@apache.org> > > > > > > > > > Date: Monday, January 6, 2025 at 03:01 > > > > > > > > > To: dev@kie.apache.org <dev@kie.apache.org> > > > > > > > > > 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: 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 > > > > > > > > >
