In some instance this checkout can be helped/removed by doing a lightweight
checkout, but it don't work on our builds since we have ${TAGNAME}
parameters on the checkouts. And parameters in the SCM URL are not
compatible with lightweight checkout.
--
You received this message because you are
I have a similar issue. Among running pipelines we have also some matrix
jobs. And allowing pipelines to even trigger requires allowing matrix
parents on master. Matrix parents happen to clone SCM first and then they
run sub-jobs. This can easily end up consuming all space on jenkins master.
i would have to agree, this is definitely an issue. I'm currently using
Amazon EFS as the storage backend for my Jenkins master, who doesn't have
any executors. The flyweight executors checking out repositories is
definitely a concern of mine. EFS will automatically scale so storage isn't
a
In my opinion, even more problematic than possibly running unsafe code in a
flyweight executor on the master is the fact that these flyweight pipeline
threads perform a full checkout of the target repository - at least when
using Git as the SCM. So if one has a relatively large code repository
Jenkins already does some of that for you by running the pipeline script in
a sandbox. Certain methods/functions in the Jenkinsfile must be approved by
a Jenkins administrator.
tirsdag 14. juni 2016 08.43.00 UTC+2 skrev Eli White følgende:
>
> Agreed, you are not supposed to do any real work in
Agreed, you are not supposed to do any real work in a flyweight node.
However, in an organization where teams' repos contain Jenkinsfiles that
they wrote, we can't guarantee the safety and correctness of those files
and their following of best practices.
We want to protect the master node
By not running anything on master we don't have to worry about any sort of
failure related to misconfiguration of jobs, or job related failures. For
example, OOM, out of disk space, pausing when 'input' is run, etc.
If a slave goes down you have 1 machine down. If master goes down, all CI
for
Hello,
I’m not sure one can do what you want.
Out of curiosity, what’s the use case for this ?
> Le 13 juin 2016 à 23:16, Eli White a écrit :
>
> My understanding is that Jenkinsfile execution runs as a flyweight node on
> master, but then uses heavyweight nodes on
My understanding is that Jenkinsfile execution runs as a flyweight node on
master, but then uses heavyweight nodes on the given node label to execute.
Per this
file: https://github.com/jenkinsci/pipeline-plugin/blob/master/TUTORIAL.md
Why are there two executors consumed by one Pipeline build?
In your pipeline, the *node* parameter can take an argument of which node
to run on.
See this example:
https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/build-test.groovy#L100
In my job, I defined BUILD_NODE with the NodeLabel Parameter Plugin (
We follow the Jenkins configuration best practices and have no executors on
our master node and force everything to run on our agents.
We are starting to work with pipeline jobs and are worried that bad
Jenkinsfiles could cause problems on our master.
How can we force the flyweight jobs to
11 matches
Mail list logo