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, and you still have all
the drawbacks of a build expressed in a weird DSL, plus you have the
serious functional limitations of tools like Build Publisher, 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—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'
}
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.
--
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.
