Great idea! Part of this use-case is the ability to dry-run a pipeline > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fkohsuke%2Fjenkinsfile-runner%2Fissues%2F16&sa=D&sntz=1&usg=AFQjCNFe3yDnNGVWjALk8wLA2YpVAtRdqQ>, > > which is a larger topic than just jenkinsfile-runner, but the later could > be part of this story. Typically, it could offer simple ways to switch > environment / credentials so that pipeline runs with test resources, and > not production ones. Typically, I would expect we can run something like > this :
jenkinsfile-runner --config jenkins-dev.yaml > Doing so would setup the headless jenkins master with development-only > credentials, and environment variables to rely on test resources (a local > web server as deployment target for sample), while the actual CI/CD master > would run the same on production infrastructure. I do this today by running Jenkins master container without mounting the jenkins_home directory. This of course has all the drawbacks that Jesse listed. An officially thought out and supported method would be most welcome. Right. Let's now consider this fronted is _not_ Jenkins but some UI which > can expose build status ? Or maybe even no UI but just a GitHub commit > status update ? This is very interesting. How about a middle ground of splitting Jenkins master into multiple smaller (yet connected) Jenkins masters using namespaces? One of the pros of a monolithic Jenkins instance is the ease of inter-project operability (think Parameterized Trigger Plugin). A major con is of course the heavy UI. It would be awesome to split projects with namespaces and have master render only a specific namespace in UI, all the while keeping the logical access to the rest of the Jenkins projects intact. Views achieves this for the most part but an accidental click to the Jenkins logo results in an unnecessary load of all the Jenkins projects. Supporting a partial render as a core Jenkins master concept will help us scale the monolithic Jenkins instance across larger orgs. We can extend the namespace concept even further and consider a partial plugin availability. Why expose all the plugin options to all projects when each namespace has different minimal requirements? Why enforce the same plugin configurations across all the namespaces? I can imagine a system similar to Windows Group Policy where the corporate IT sets guidelines and namespace owners override within the IT's boundary. This will help reduce the # of rogue Jenkins masters that are configured insecurely. I can't be the first person to think of this. Does anyone know an effort towards this direction that I can participate in? On Friday, April 27, 2018 at 11:46:18 PM UTC-7, nicolas de loof wrote: > > > > Le ven. 27 avr. 2018 à 15:46, Jesse Glick <[email protected] > <javascript:>> a écrit : > >> On Fri, Apr 27, 2018 at 3:52 AM, nicolas de loof >> <[email protected] <javascript:>> wrote: >> > jenkinsfile-runner --config jenkins-dev.yaml >> >> This sounds useful. >> >> > I also have in mind another possible usage : one-shot jenkins masters - >> > let's call this "serverless jenkins" for the buzzword. >> > >> > To avoid huge jenkins masters running thousand pipelines, we could rely >> on >> > jenkinsfile-runner for pipeline execution, a front-end master being >> used for >> > job configuration and web UI only. As a git event comes to jenkins >> > infrastructure, a new serverless payload would be triggered (think : >> docker >> > container running somewhere) to execute jenkinsfile-runner with adequate >> > jenkins.yaml, so pipeline can run the same as if the front-end master >> had >> > ran it by itself. >> > […] >> > On pipeline completion, jenkinsfile-runner would then publish the build >> > status on front-end master (something comparable to >> buildpublisher-plugin). >> >> This makes little sense to me. You still have the huge Jenkins master >> rendering a web UI for thousands of pipelines, > > > Right. Let's now consider this fronted is _not_ Jenkins but some UI which > can expose build status ? Or maybe even no UI but just a GitHub commit > status update ? > > > and you still have all >> the drawbacks of a build expressed in a weird DSL, > > > Not my fault. Use of groovy for build-flow was a mistake. We should have > learned from this initial "draft". > > plus you have the >> serious functional limitations of tools like Build Publisher, > > > Which in future I expect not to be required as build status, artifacts, > logs... would be stored on some cloud-native storage and directly > accessible without Jenkins in the middle to serve them. > > plus you >> have to set up a bunch of infrastructure to make the “one-shot” master >> be able to provision or link to build agents > > > Right. Let's say we only support docker agents, and a descent plugin able > to create such nodes (an idea I'd like to investigate is to have labels == > docker image) > > —unless it requires only >> one node and no real interaction with anything else in the system, in >> which case your Pipeline would better have been expressed as >> >> node { >> sh '. /thisjob/run.sh' >> } >> > > Isn't this the sole reasonable Jenkinsfile one should write ? Kidding > appart, 'stages' still make some sense for those interested in > visualization or to spilt a huge build log into more focused sections. For > anything else I agree a shell script is the best tool we have. (I wonder we > named this "Jenkinsfile" and not "makefile" ;-) ) > > > >> with the script and credentials coming from Kubernetes and there is no >> need for any special runner. >> >> As to avoiding Groovy sandboxing, this is best done in a different >> way: by not using `workflow-cps`, and rather running the script in a >> separate plain-Groovy process (yes, “serverless”) connecting to the >> master for step implementations. Simpler, and far easier to migrate to >> from existing configurations. >> > > This sounds what I expected Jenkinsfile-runner to be, but probably not > such a trivial think to implement and alternative workflow executor to > replace CPS with a plain groovy runtime, is it ? > > >> -- >> 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] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr37wA%3DQUC5GTSBy4AgSFocM%3DD7NFFjsYyvYqgF9WNB71w%40mail.gmail.com >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- 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/fdb5cc2d-ebe0-433a-a744-792929d3d06a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
