Re: pipeline: it seems pipeline-build-step (build job) ignores node assignment

[Robert Hales]

Enclosing a 'build' step in a node can be roughly equivalent to enclosing 
an ssh command in the node. That ssh command is kicking off some external 
process. The build step is kicking off an external process. This seems like 
completely normal behavior to me. The jobs are not related to each other in 
any way, and they have their own configuration about which nodes they want 
to run on. It doesn't make sense to expect to independent jobs to have some 
kind of coupling like that. 

Can you give some examples of how the node block does not define the node 
properly for any internally executed steps? I have never seen any steps run 
on the wrong node.

On Monday, October 23, 2017 at 10:33:35 AM UTC-6, Steve Turner wrote:
>
> I wouldn't call that behavior "normal".  I'm new to Jenkins pipelines and 
> Groovy scripting, and this has been the single most maddening thing to 
> overcome in my attempts to learn the environment.  On what planet does it 
> make sense that enclosing something in a node block, where the only 
> argument is a node label, and where the block is enclosed in {} braces 
> (which defines an isolated "scope" in every other language I can think of) 
> does not cause the label to become used as the default for everything 
> defined therein?  The backflips you have to go through to overcome this are 
> ridiculous.  I find both the "node" and "agent" constructs as implemented 
> by the Jenkins pipeline mechanism to be completely useless.
>
> On Wednesday, December 14, 2016 at 6:42:09 AM UTC-6, 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. 
>>
>>

-- 
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/b3e2f1e7-1e28-4d63-a7c9-b225b8d154a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: pipeline: it seems pipeline-build-step (build job) ignores node assignment

[Robert Hales]

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, alexand...@gmail.com 
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 () {  }'
> ).
>
> 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 :
>>
>>> 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 

Re: pipeline: it seems pipeline-build-step (build job) ignores node assignment

[Steve Turner]

I wouldn't call that behavior "normal".  I'm new to Jenkins pipelines and 
Groovy scripting, and this has been the single most maddening thing to 
overcome in my attempts to learn the environment.  On what planet does it 
make sense that enclosing something in a node block, where the only 
argument is a node label, and where the block is enclosed in {} braces 
(which defines an isolated "scope" in every other language I can think of) 
does not cause the label to become used as the default for everything 
defined therein?  The backflips you have to go through to overcome this are 
ridiculous.  I find both the "node" and "agent" constructs as implemented 
by the Jenkins pipeline mechanism to be completely useless.

On Wednesday, December 14, 2016 at 6:42:09 AM UTC-6, 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. 
>
>

-- 
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/2424b270-68d1-48b7-aac1-4a8298a36c89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: pipeline: it seems pipeline-build-step (build job) ignores node assignment

[alexander . ites]

Eventually I managed to trigger a job with a specific label at the 
pipeline-build-step via NodeLabel Parameter Plugin you mentioned.

So thanks again, Michael. The way you proposed works fine.

Maybe the actual way I did this can be useful for someone.
The correct way is presented at the Pipeline DSL code snippet:

build job: 'job2',
parameters: [
[
 $class: 'LabelParameterValue',
   name: 'NODE_NAME',
  label: 'label1'
]
]

The difference with my previous try is at the name of the 3rd Groovy 
map-entry at the Pipeline DSL code snippet above. The actual key for this 
map-entry when using the NodeLabel Parameter Plugin should be 'label' and 
not 'value'. This is due the constructors of LabelParameterValue:
https://github.com/jenkinsci/nodelabelparameter-plugin/blob/nodelabelparameter-1.7.2/src/main/java/org/jvnet/jenkins/plugins/nodelabelparameter/LabelParameterValue.java
 the 2nd parameter at the constructors where the 2nd parameter is 
presented has name 'label' and not 'value'. And the logic of constructor 
parameter passing when ParameterValue objects are created is a comparison 
of a map-entry key with a Java-code constructor parameter name:
https://github.com/jenkinsci/structs-plugin/blob/structs-parent-1.5/plugin/src/main/java/org/jenkinsci/plugins/structs/describable/DescribableModel.java
 see methods
instantiate(Map arguments)
and
buildArguments(Map bag, Type[] types, String[] names, boolean 
callEvenIfNoArgs)

Thus it seems quite obscure how to compose a map corresponding to a 
parameter of plugin (especially due lack of documentation) until one will 
look into the actual code of a corresponding ParamValue subclass.
For instance for StringParameterValue (for any simple parameterized job) 
the 2nd parameter is 'value' (and not 'label').

Hope it will help someone.
This helped me to workaround the inability to build job via 
pipeline-build-step with node assigned by a pipeline through 'node (..) 
{..}'-clause.

Best regards,
Alexander.


On Wednesday, December 14, 2016 at 3:42:09 PM UTC+3, mpapo - Michael 
Pailloncy wrote:
>
>
> 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.
>
>

-- 
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/b18a5c53-05f4-4e94-809f-f340d254fcfb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: pipeline: it seems pipeline-build-step (build job) ignores node assignment

[alexander . ites]

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 () {  }'
).

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 :
>
>> 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 jenkinsci-use...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/77c72577-5898-4ccb-b0eb-cb9d1dab1d7e%40googlegroups.com
>>  
>> 
>> .
>> 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/a47aa434-e328-4a39-b95c-a6bb13f00a6a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: pipeline: it seems pipeline-build-step (build job) ignores node assignment

[Michael Pailloncy]

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 :

> 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 jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-users/77c72577-5898-4ccb-b0eb-cb9d1dab1d7e%40googlegroups.
> com
> 
> .
> 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/CAPO77c1_KFF_amMi-QCzj3Ab7sshHtZ4GuVs9c1hsrh%2Bw7PoAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

pipeline: it seems pipeline-build-step (build job) ignores node assignment

[alexander . ites]

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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/77c72577-5898-4ccb-b0eb-cb9d1dab1d7e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.