I indeed think a JEP would make sense for jenkinsfile-runner, to describe how it interacts with other projects. This is the next step imho. This thread is more about brainstorming about some use-cases and check for interest about this.
2018-04-28 11:05 GMT+02:00 Ewelina Wilkosz <[email protected]>: > 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]> 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/ms >>> gid/jenkinsci-dev/CANfRfr37wA%3DQUC5GTSBy4AgSFocM%3DD7NFFjsY >>> yvYqgF9WNB71w%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 > <https://groups.google.com/d/msgid/jenkinsci-dev/5aedacdb-0c9d-4d3b-9085-a605abae7a75%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > 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/CANMVJzm5DFrz7iabzqTkD_fG0sD95%3Dp2nnRHTuZiq_JmvMQ09A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
