I am pretty sure you'll make many people happy with it - are you planning to write/is there already a JEP for that? since you've mentioned JCasC couple of times I believe it would make sense to how exactly those two could work together (I'm assuming you have some ideas in mind, but we can try to have it somewhere else also :) )
On Saturday, April 28, 2018 at 8:46:18 AM UTC+2, 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/5aedacdb-0c9d-4d3b-9085-a605abae7a75%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
