On Thu, Apr 4, 2024 at 12:24 AM Pierrick Bouvier <[email protected]> wrote: > > Thanks for taking the time to answer and give a direction Basil, it's > definitely more constructive than saying "do not ping me".
"Do not ping me" definitely still stands from my side regarding questions about the current code, even if I did last touch some of the files in question, trying to keep this component on life support. I didn't write the current code, I didn't check in the pre-built binaries, I can't explain the reasoning behind past decisions, and I can't help you understand the current implementation. The expectation is that the contributor will have to figure all this out, as I did when working on a different abandoned repository (PCT) several months back. Of course we are willing to guide anyone to the desired end state, and that desired end state includes running CI builds on Jenkins. > I'm fine doing this work, it it's allowed on my side. I'll come back to you > once I have an answer. Great! We'd love to see this finally fixed. As you saw in the previous contributor's PR, this has been an issue for a long time. > 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). Aren't these the same problems as with GitHub Actions? In both cases, the user does not have access to the server while the CI job is running. In both cases, the images should have a reasonable amount of build software installed in order to facilitate efficient development. In both cases, the software installed needs to be documented to facilitate efficient development (in our case, https://github.com/jenkins-infra/documentation/blob/main/ci.adoc#container-agents describes the setup on our agents). And in both cases, there needs to be a way to install or enable software dynamically (e.g. using GitHub Actions' setup-java, or Jenkins' tool installation subsystem). I am aware of deficiencies on the Jenkins side with regard to Docker, documented in https://github.com/jenkins-infra/helpdesk/issues/3587, but that doesn't apply here. In short, this is essentially the same process, certainly not "a pretty huge ask and unfair" or "essentially saying no" as Gavin Mogan claimed. And as proof of this, I have done exactly the same thing myself in the past, resurrecting the Packaging repository from an abandoned state and developing a CI job there against a VM agent where I install Puppet and run a custom non-Maven build. -- 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/CAFwNDjpi0J63a%2B%3D2gjOd_Wn8zmk9OvPqVppCT0EfNMFoBE4vAg%40mail.gmail.com.
