2018-05-01 14:59 GMT+02:00 Jesse Glick <[email protected]>: > On Sat, Apr 28, 2018 at 2:46 AM, nicolas de loof > <[email protected]> wrote: > >> you still have all > >> the drawbacks of a build expressed in a weird DSL, > > > > Not my fault. > > Obviously not; half mine. :-) My point is that the approach you are > describing does not do anything to help resolve that. Whereas we *do* > have some ideas for running the script out of process, which solves > the DSL/sandbox issues, and should not require drastic changes to the > overall user experience. > > >> 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. > > Definitely we plan for that. This is not what I was talking about. > There is a gigantic long tail of Jenkins features (mostly plugins) > which would not work in a Build Publisher-like environment; some of > that could be fixed with a lot of labor, some probably not at all > short of a total redesign. >
Not sure what you have in mind (if you have a concrete sample this could help). I can't imagine a plugin that couldn't work with a rsync-copy of a remote build dir. But I might miss something. Anyway what I'd like to achieve is to fully remove Jenkins Web UI and only rely on Github commit status for user interaction (read more on http://bit.ly/blind-jenkins). So plugins would only make sense during the build, and any UI contributing plugin would just be excluded. > > > 'stages' still make some sense for those interested in visualization > > or to spilt a huge build log into more focused sections. > > Yes; independently of all this discussion, I would love to see Blue > Ocean support something like the Collapsing Console Sections plugin, > so you would not be forced to “escape” from your native build process > into Pipeline script merely to demarcate (at least linear) stage > boundaries. For example, > > https://github.com/jenkinsci/docker-workflow-plugin/pull/105 > > could have collapsed four scripts into one, making the Pipeline script > considerably shorter (and the master load correspondingly a bit > lighter). > +1 I'd like pipeline stages to be controlled from shell scripts, something like : echo "entering stage foo" > /var/run/jenkins.sock so I could rename my pipeline scripts as "Jenkinsfile.sh" > > probably not such > > a trivial think to implement and alternative workflow executor to replace > > CPS with a plain groovy runtime, is it ? > > Not trivial at all, but I believe feasible. > ok, then when this becomes available we would be able to make jenkinsfile-runner way simpler :D > > -- > 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/CANfRfr1eqa2a-9dzBkCwGibVgqyPHsb% > 2BGwxY0rJ3BmZU4eLCmw%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/CANMVJzkEUkisKE8RH66ASDuJHe%3DOMdawS1cOQRJFJ9jSSFLHRg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
