On Thu, Mar 28, 2024 at 11:16 PM Pierrick Bouvier <[email protected]> wrote: > Thanks for your help, I'll take a look at this.
And thanks for your interest! Unfortunately I think https://github.com/jenkinsci/winp/pull/112 is premature, as the repository is not currently in a state where _any_ outside contributions to the native C++ code can be accepted, as the Jenkins CI build uses precompiled binaries rather than building the C++ code from scratch. In order for us to be able to accept contributions to the native code like yours, we first need to set up a proper build environment with no pre-compiled binaries, a CI build (ideally Jenkins CI) that compiles both the Java code and the native code and runs the tests, and (ideally) a CD process on GitHub Actions that compiles both the Java code and the native code and performs the release. Our existing CI/CD infrastructure is heavily Maven-centric, so it would be preferred to use Maven as the entrypoint into the process and then to vector into the native code compilation from within Maven. My strong preference is for the above work to be done as a prerequisite to adding ARM support. The status quo is already untenable, even without taking into consideration the changes needed to add ARM support. I am a -1 on using GitHub Actions for CI, and I am a -1 on adding ARM support using the existing status quo of prebuilt binaries before solving the existing technical debt of the incomplete CI/CD process. The reason for this is that I believe there will not be a strong incentive to work on the long-term CI/CD process once the ARM support is added. Therefore I am against adding any new features, including ARM support, before the existing technical debt is addressed. Since commit access is required to test Jenkinsfile changes on ci.jenkins.io, I would propose to first add you as a winp committer alongside the Jenkins core team (but not a committer on any other repositories). This would allow you to test Jenkinsfile changes on ci.jenkins.io. The next steps after that, in this proposal, would be for you to develop two PRs, the first PR updating the Jenkinsfile to compile the native code as part of the Maven build rather than using pre-built binaries, and the second PR implementing CD with GitHub Actions. The first of these will require collaboration with the Jenkins infrastructure team to provide an appropriate stateless build environment. Once this is working, your commit access can be removed, and the core maintainers can click the CD button to perform a release from the sources without any prebuilt binaries. Since this release will have been compiled entirely on Jenkins infrastructure with no prebuilt binaries, it can be trusted and adopted by Jenkins core. At this point, the technical debt would be solved and the repository would become open to new features again. Unfortunately there is no existing maintainer to complete this prerequisite work. But after this is all said and done, you can proceed with your original PR to add ARM support, which should be easy for any core maintainer to approve and release (with CD) once the repository has no more prebuilt binaries and a working CI/CD process. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjpc_seOUNK9wKtkz7g3wkWcOwzBJWAxsjr62EaVjsobmg%40mail.gmail.com.
