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 <[email protected]> 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 <[email protected]>
>>>>> 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 [email protected].
>>>>>> 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 [email protected].
>>>> 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 [email protected].
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.
