Hi Sam,
Well, I couldn't see it documented anywhere that the originally allocated
node would be reused for subsequent node blocks with the same label, so I
assumed any specific behavior wasn't guaranteed. That's interesting what
you observed. I wonder if a Jenkins developer could comment on this?
On Monday, July 31, 2017 at 3:49:23 PM UTC-5, Sam K wrote:
>
> Hi
> yes, naming them specifically is very limiting. But my latest
> iterations of pipelines, I have to do that as I'm using one of the slaves
> as a apache host to serve logs on it as well.
>
> Anyways, before I did that, I had 2 slaves and had a common label on
> them called 'jenkins-slave' and in my pipeline when I used the label as
> 'jenkins-slave', it would pick the first or the second and use it
> throughout the pipeline. It would never mix and match. As long as you have
> quite a few executors on each of them, as far as I can remember, it will
> use the same slave throughout the job.
>
> Did you notice the pipeline using a different slave with the same label
> even with quite a few executors available?
>
> sam
>
>
> On Monday, July 31, 2017 at 1:26:09 PM UTC-7, Mark wrote:
>>
>> Thanks, Sam.
>>
>> First, I should have stated that I'm using a Groovy pipeline. I'm not
>> entirely certain whether I've stayed within the limits of a declarative
>> pipeline, or I've moved into a scripted pipeline at this point.
>>
>> I was hoping to avoid pegging jobs to particular nodes within the
>> pipeline code itself (i.e. "windows-1", "linux-1"). I'd like the master to
>> allocate any available windows node and linux node and use those throughout
>> the job. I was hoping there was some means of getting a handle to whatever
>> node was allocated for a given label, then reusing that node later in the
>> job.
>>
>> Maybe I can illustrate what I'm trying to achieve with some pseudocode:
>>
>> // The nodes initially allocated for each label should be reused for
>> later steps
>> // requiring those labels.
>> parallel {
>> windows {
>> parallel {
>> checkout repo1
>> checkout repo2
>> checkout repo3
>> }
>> build server
>> start server
>> }
>> linux {
>> parallel {
>> checkout repo1
>> checkout repo2
>> }
>> }
>> }
>> // synchronized here - tests shouldn't start until checkouts are complete
>> on both nodes
>> // and server is built and running
>> linux {
>> run tests against server
>> generate test report
>> }
>> windows {
>> stop server
>> }
>>
>>
>> Hopefully that clarifies what I'm going for. I kinda/sorta have this
>> working, but I'm cheating by using labels that apply only to a single
>> windows and linux node (i.e. what you suggested, Sam). That's pretty
>> limiting and not scalable, so I'm hoping there's a better way.
>>
>> Thanks again!
>>
>>
>> On Monday, July 31, 2017 at 1:49:16 PM UTC-5, Sam K wrote:
>>>
>>> I don't have all the answers, but most are embedded. Firstly are you
>>> using the freestyle jobs or declarative groovy pipeline jobs?
>>>
>>> On Monday, July 31, 2017 at 9:53:43 AM UTC-7, Mark wrote:
>>>>
>>>> Hi. Hoping someone here might be able to help or point me in the right
>>>> direction. I've been reading docs for many hours, and I can't find any
>>>> examples similar to what I'm trying to do.
>>>>
>>>> Here's what I want to do at a high level:
>>>>
>>>> I have multiple nodes, some have the "windows" label, others the
>>>> "linux" label.
>>>>
>>> >> You can add more than one label. You can call it windows-1, Linux-1
>>> and use them in your pipelines.
>>>
>>>>
>>>> I want to run an end-to-end test that requires a server running on a
>>>> windows node, and a client running automated tests on a linux node against
>>>> the windows server.
>>>>
>>>> First, run checkouts in parallel on both a windows node and a linux
>>>> node. The windows node needs to checkout 3 three svn repos (ideally, in
>>>> parallel), while the linux node needs to checkout 2 svn repos (ideally, in
>>>> parallel).
>>>>
>>> >> You can add more than one scm repo in each job. Have a kick off job
>>> that calls both the freestyle jobs. then checkouts can happen in parallel.
>>> Or if you're using declarative pipeline, you can use the parallel blocks
>>> to checkout on both in parallel.
>>> https://github.com/jenkinsci/pipeline-model-definition-plugin/wiki/Parallelism
>>>
>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fjenkinsci%2Fpipeline-model-definition-plugin%2Fwiki%2FParallelism&sa=D&sntz=1&usg=AFQjCNG9PumS44svAGANCBDVelaQonGAQA>
>>>
>>>>
>>>> Once the the checkout stage is done, on the windows node, build the
>>>> server, then run the server.
>>>>
>>>> While the server continues to run on the windows node, run tests on the
>>>> linux node. (Note that my client doesn't need an explicit build stage).
>>>>
>>>
>>>
>>>> Once the tests complete, generate tests report on the linux node and
>>>> stop the server on the windows node.
>>>>
>>>
>>>> - Is this pipeline possible? This seems like a pretty common scenario
>>>> (i.e. checkout on server + client in parallel, build, start server, run
>>>> tests on client).
>>>>
>>> >> Yes, its possible.
>>>
>>>> - Is there any way to "reuse" a node allocated earlier? In my case, I
>>>> need to ensure that the same windows and linux nodes are always used and
>>>> the workspaces remain intact until the pipeline completes.
>>>>
>>> >> labels is the best way to use the same nodes
>>>
>>>> - What's the best way to synchronize the two nodes after the parallel
>>>> checkouts,
>>>>
>>> >> Synchonize what??
>>>
>>>> then ensure that the same nodes/workspaces continue to be used when the
>>>> windows server runs and the linux client tests execute?
>>>>
>>> >> You can use labels on each and choose that label. Also, for
>>> workspace you can use custom workspace names which will be used over and
>>> over again.
>>>
>>>>
>>>> Thanks!
>>>>
>>>
--
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/bd91db4c-3b72-41fb-bbe6-bdda2cf559ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
