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 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 against whatever user error we feasibly
> can. Messing up jenkins files seems like a really easy thing to do.
>
> It sounds like this ability might not exist. I'll open a JIRA for it.
>
> On Monday, June 13, 2016 at 11:29:40 PM UTC-7, Sverre Moe wrote:
>>
>> I don't think you are supposed to do any real work in a flyweight
>> executor.
>> Steps need to be within a node{} which will allocate a heavyweight
>> executor. I use the flyweight executors only to trigger downstream builds.
>>
>> tirsdag 14. juni 2016 02.47.40 UTC+2 skrev Eli White følgende:
>>>
>>> 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 our company goes down. The need for us to protect and make behavior
>>> guarantees of the master node, we want it to do only what is absolutely
>>> necessary and keep user code from running on it.
>>>
>>> On Monday, June 13, 2016 at 2:19:56 PM UTC-7, Thomas Zoratto wrote:
>>>>
>>>> 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 <e...@wealthfront.com> a écrit :
>>>>
>>>> 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?
>>>>
>>>> - Every Pipeline build itself runs on the master, using a flyweight
>>>> executor — an uncounted slot that is assumed to not take any
>>>> significant computational power.
>>>> - This executor represents the actual Groovy script, which is
>>>> almost always idle, waiting for a step to complete.
>>>> - Flyweight executors are always available.
>>>>
>>>>
>>>> On Monday, June 13, 2016 at 2:11:19 PM UTC-7, Craig Rodrigues wrote:
>>>>>
>>>>> 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 (
>>>>> https://wiki.jenkins-ci.org/display/JENKINS/NodeLabel+Parameter+Plugin
>>>>> ).
>>>>>
>>>>> --
>>>>> Craig
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jun 13, 2016 at 2:03 PM, Eli White <e...@wealthfront.com>
>>>>> wrote:
>>>>>
>>>>>> 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 run on a designated machine
>>>>>> *other* than master?
>>>>>>
>>>>>> How do other people handle this?
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "Jenkins Users" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to jenkinsci-use...@googlegroups.com.
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/d/msgid/jenkinsci-users/d4ee67f4-ab75-4a1e-9883-69453bdd656b%40googlegroups.com
>>>>>>
>>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/d4ee67f4-ab75-4a1e-9883-69453bdd656b%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 Users" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to jenkinsci-use...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/jenkinsci-users/a41c28a9-fc93-459f-b990-87cb1210cb64%40googlegroups.com
>>>>
>>>> <https://groups.google.com/d/msgid/jenkinsci-users/a41c28a9-fc93-459f-b990-87cb1210cb64%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 Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/d4d3e045-e7dd-4b60-9baa-bcdbbf8ea529%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
