Thanks for taking the time to answer and give a direction Basil, it's definitely more constructive than saying "do not ping me".
I'm fine doing this work, it it's allowed on my side. I'll come back to you once I have an answer. @Gavin: I agree 100%. The problem for me is not to install or use my own jenkins server (I did a lot of this in the past), but to be able to understand what is inside your runner image exactly, and how to request new stuff (plus additional time to wait for someone to answer). In short, It will take 3 days to find information on something that take 1h for someone from the infra team to do. I hope I can get concrete help on this, instead of vague general direction. On Thursday 4 April 2024 at 09:42:45 UTC+4 ga...@gavinmogan.com wrote: > As much as I find the response verbose and a little aggressive, I'm going > to have to agree, especially after the big XZ backdoor found in linux this > week. No binary in source control, libs need to be built. > > As much as I agree, that a CI project shouldn't use a competitors CI > project, I think asking a new contributor to find someone who can help them > build a build pipeline on a server they don't have access to is pretty huge > ask and unfair. Thats essentially saying no. > > The options should be either create a build pipeline on your own install > of jenkins (what I usually did), or build a ci pipeline in github actions > in a fork, and then submitting it as a PR. > > On Wed, Apr 3, 2024 at 9:00 PM Basil Crow <m...@basilcrow.com> wrote: > >> On Thu, Mar 28, 2024 at 11:16 PM Pierrick Bouvier >> <pierrick...@linaro.org> 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 jenkinsci-de...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjpc_seOUNK9wKtkz7g3wkWcOwzBJWAxsjr62EaVjsobmg%40mail.gmail.com >> . >> >> -- 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/a9628519-5b1d-4845-8cde-3770ec67dfb6n%40googlegroups.com.
