Hi Eder, thank you for your reply. I understand the concerns. It was expected that during the migration, there will not be possible to build community releases for an unknown amount of time. That is why I wrote my proposal - to start unblocking the releases in small iterations.
To migrate to Jenkins, I personally don't expect it to take a lot of time to do basic stuff. We wrote something similar from scratch in IBM, so it could be done similarly for the community. Especially if people knowledgeable of kie-tools build would participate in the implementation. Of course, my proposal is just a proposal. I welcome other proposals that could solve the current situation more efficiently. However we need to realize that the code is owned by Apache now and needs to be under Apache organization. I would also suggest trying to avoid doing any custom workarounds. We should do the migration properly, otherwise we will introduce a huge process and technical debt right from the start. Best regards, Tibor On Thu, Sep 21, 2023 at 1:49 PM Eder Ignatowicz <[email protected]> wrote: > Hi Tibor and others! > > Thanks for this proposal, but before we move forward, I would like to raise > a few concerns. > > For context, the kie-tools community has a sustained pace of release. Most > of the time, we launch a new release every month. Currently, this release > is coupled with GitHub Actions, and we release the following artifacts used > by tens of thousands of users: > > - bpmn_vscode_extension > <https://marketplace.visualstudio.com/publishers/kie-group>; > - bpmn and dmn chrome extension > < > https://chrome.google.com/webstore/detail/bpmn-dmn-test-scenario-ed/mgkfehibfkdpjkfjbikpchpcfimepckf > > > ; > - chrome_extension_serverless_workflow_editor > < > https://chrome.google.com/webstore/detail/serverless-workflow-edito/ijamhkegfogkfnmfnfkjdiadomlphfej > > > ;- > - dmn_vscode_extension > <https://marketplace.visualstudio.com/publishers/kie-group>; > - kie_sandbox_extended_services_linux > kie_sandbox_extended_services_macos > kie_sandbox_extended_services_windows: our pluggable backend services: > - kn-workflow-darwin-amd64 > kn-workflow-darwin-arm64 > kn-workflow-linux-amd64 > kn-workflow-windows-amd64: Knative CLI for serverless workflow > - pmml > < > https://marketplace.visualstudio.com/items?itemName=redhat.vscode-extension-pmml-editor > > > vscode extension; > - serverless_vscode_extension > <https://marketplace.visualstudio.com/publishers/kie-group>; > - vscode_extension_dashbuilder_editor > < > https://marketplace.visualstudio.com/items?itemName=redhat.vscode-extension-dashbuilder-editor > > > ; > - extension <https://marketplace.visualstudio.com/publishers/kie-group> > bundles: > - kubesmarts <https://start.kubesmarts.org/#/> > - kie sandbox <https://sandbox.kie.org/#/> > > Our community invested a lot to automate all those releases and remove the > burden of releasing several artifacts. In summary, we developed GH Actions > automation for a "one-click" release/deployment of such artifacts. > > I understand that in the long term, due to the capacity of GH Actions at > Apache, we should move all those automation to Jenkins, but we are > following your proposal: > > > Initial needs: > > > - Basic PR check - A build that will run the bootstrap and build of > > > kie-tools, runs all required tests. This will enable us to say a code > > > change is not breaking anything in the repository. > > > - Daily builds - A daily build done on the main branch of the > repository, > > > with deployment of artifacts to appropriate repositories. The main > focus > > of > > > this point will be about where we have to deploy the artifacts and how > to > > > deploy it there. We have e.g. the backing infrastructure for > > > sandbox.kie.org > > > etc. running, so things like this would need to be sorted as part of > this > > > task. > > > > > > I want to also define as part of this proposal, that anything else > apart > > > from these two initial goals is not a focus of the inicial CI migration > > > work. That means that it can be done only after we have the initial > goals > > > implemented. This is to make sure we have the core CI for kie-tools > > ready. > > > This will block us from doing any release for our community for an unknown > amount of time (until we get everything in Jenkins). So what needs to be > discussed is: > > [1] What do we do if a CVE appears for one of those artifacts, and we need > to do a release promptly? > [2] How do we communicate to the community that we will not release any > artifacts in the following weeks? How to don't look stale for the broad > community that doesn't follow us on our lists and just use our artifacts > via VS Code store, Chrome store etc.? > > I would like everybody to be on the same page on the following drawbacks of > moving forward on kie tools migration, just with basic PR checks and daily > builds working. > > Best > > Eder > -- Tibor Zimanyi
