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
