Le ven. 27 avr. 2018 à 15:46, Jesse Glick <[email protected]> a écrit :
> On Fri, Apr 27, 2018 at 3:52 AM, nicolas de loof > <[email protected]> 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]. > 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/CANMVJznHiw%3DGsF-2DPb6PmaDxBybH%3DXoSzqZMZpgDQZxvspGbw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
