In reference to this: >>it seems strange to me that the pipeline "build" step triggers jobs without node context. This implies web-interface driven configuration of a job to be made and the cumbersome parameterized "build" step syntax to be used to run the job at the proper node. As far as I know, Pipeline plugin is meant to get rid of such inconveniences.
I think maybe you are missing the point of a pipeline. The OLD way was to link a bunch of jobs together in a sudo pipeline. The pipeline scripts are meant to bring all those individual jobs together into a single pipeline script, now divided into stages (instead of independent jobs). If you want to join a bunch of jobs in and upstream and downstream configuration, you can do that with freestyle jobs and a couple plugins. If you want to build a pipeline, put it all in one job with advanced logic and greater control of how to combine those pieces together (including things like controlling the node). One big question is why do you want to keep it on the same node? If you are trying to access files in build B that were created in build A using a pipeline, then keeping them on the same node is prone to failures. There is no guarantee where those files will end up or that they will always exist. Usually Stash and Unstash is the right way to handle this rather than forcing a node. On Wednesday, December 14, 2016 at 6:18:24 AM UTC-7, [email protected] wrote: > > Thank you for fast reply, Michael. > I got the point. > > I've already tried NodeLabel Parameter plugin with parameterized pipeline > build job step. But it haven't worked for me. > Soon I'll publish appropriate topic about this way you proposed that > doesn't work for me for unknown reason. > The pipeline script I've tried is: > > build job: 'job2', > parameters: [ > [ > $class: 'LabelParameterValue', > name: 'NODE_NAME', > value: 'label1' > ] > ] > > At this case 'job2' is configured with NodeLabel Parameter plugin to > accept 'NODE_NAME' named parameter as Label Parameter. > The job 'job2' is triggered successfully at the certain node if I use a > job with appropriate Parameterized Trigger post-build action with > NodeLabel-parameter NODE_NAME and label 'label1' as upstream one. > > > And at the 1st case without NodeLabel Parameter plugin but with pipeline > 'node'-construct > it seems strange to me that the pipeline "build" step triggers jobs > without node context. This implies web-interface driven configuration of a > job to be made and the cumbersome parameterized "build" step syntax to be > used to run the job at the proper node. > As far as I know, Pipeline plugin is meant to get rid of such > inconveniences. > So as for me it would be pretty natural and convenient if > pipeline-build-step triggered jobs with pipeline node context (nodes > assigned through pipeline 'node'-construct like: > 'node (<label expression>) { <build-job steps> }' > ). > > Kind regards, > Alexander. > > > On Wednesday, December 14, 2016 at 3:42:09 PM UTC+3, mpapo - Michael > Pailloncy wrote: >> >> IIUC, it's a normal behaviour. >> >> The "build" pipeline step triggers the job job1 without any node >> "context" (a bit like if you trigger it manually), so the default label of >> job1 is used in this case. >> >> If you want to trigger job1 with a specific label, you should have a look >> to this plugin : >> https://wiki.jenkins-ci.org/display/JENKINS/NodeLabel+Parameter+Plugin >> However, I never used it inside a Jenkins Pipeline. >> >> Michaël >> >> 2016-12-14 13:23 GMT+01:00 <[email protected]>: >> >>> Hi, >>> >>> I'm trying to run a job at the node assigned (not the master node), but >>> the job runs at any free node available (often it is the master node >>> actually). >>> >>> Here's my pipeline script: >>> >>> node('label1') { >>> echo "Actual node name: $env.NODE_NAME ." >>> build job: 'job1' >>> } >>> node('master') { >>> echo "Actual node name: $env.NODE_NAME ." >>> } >>> >>> My master node is not labeled with label 'label1'. >>> Only one of my slave nodes is labeled with label 'label1'. >>> >>> I see at a build's Console Output that the 1st echo is executed at the >>> slave node with label 'label1'. And the 2nd echo is executed at the master >>> node. >>> But 'job1' is executed at the master node also. >>> I think that for my pipeline script 'job1' should be executed at the >>> slave node labeled with 'label1'. >>> 'job1' is allowed to run at any node (this is configured at the job's >>> configuration). >>> >>> Is this behavior is correct? Or is it a bug when build-job-step ignores >>> pipeline node assignment? >>> >>> For now I use Jenkins 2.8 and Pipeline Plugin 2.4 . >>> I've tried both Windows and Linux slaves node with this case (got the >>> same result). My master node is on Linux. >>> >>> Best regards, >>> Alexander. >>> >>> -- >>> 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/77c72577-5898-4ccb-b0eb-cb9d1dab1d7e%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/jenkinsci-users/77c72577-5898-4ccb-b0eb-cb9d1dab1d7e%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/4a1db574-97a5-4567-a285-30258fd3cacb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
