I was implying pipeline `node (label) { }` nodes not build agent nodes...
I could have a pipeline like
def actualLabel1Node;
node (label1) {
actualLabel1Node = **current node full set of labels**;
**checkout... with credA**
}
node (label2) {
**checkout... with credB**
}
node (actualLabel1Node) {
*<!-- your build step goes here*
}
Now even if you were being super sneaky and trying to look for a previous
`node` with a checkout step (which is the equivalent in a freestyle job of
run.getParent().getScm() ) ... and AIUI is not even possible... but
*thought experiment* let's pretend it was possible... how can your build
step hope to know whether to use credA or credB:
- There is more than one node block doing a TFS checkout and the nearest
one is the wrong credentials
- The correct one isn't even using the same label as the block you are
in (because your block has to specify the exact labels of the node the
first one ran on)
Now never-mind that the above is not the way you are supposed to do things
with pipeline (you should be using stash/unstash... in order to play nicer
with ephemeral nodes)
The whole point is that in a pipeline, you have no way of inferring the
credentials to use
Now if we have your build step take credentials then it becomes easier
node (label1) {
checkout... with credA
// perhaps stash depending on what the use case is and your buildstep
functionality
}
node (label2) {
checkout... with credB
}
node (label1) {
// perhaps checkout and unstash if your build step relies on having a
checkout present
your build step... with credA
}
The above besides being less hacky also plays better with ephemeral nodes
so that we do not care if the original label1 node is returned to us for
use with your build step
On 11 August 2016 at 10:29, Rafael Rezende <[email protected]> wrote:
> In practice, this build step MUST be executed in the same node where the
> checkout was performed. Anyway, technically I should not assume it will
> always happen. Better be on the safe side anyway and implement the
> credentials there.
> Thanks Stephen!
>
>
> On Tuesday, August 9, 2016 at 8:02:45 PM UTC+2, Stephen Connolly wrote:
>
>>
>>
>> On Tuesday 9 August 2016, Rafael Rezende <[email protected]> wrote:
>>
>>> - is there any use case where a user may actually want to use different
>>>> credentials in the build step than in the checkout?
>>>>
>>> *No.* They should be always the same.
>>>
>>> - are you writing a pipeline capable build step or one specifically
>>>> tailored for use in old-style jobs only?
>>>>
>>> *Yes.* Should be pipeline capable.
>>>
>>>
>> So this one here is the killer on zero config as the node step within
>> which you run your build step may not be the same node step instance where
>> the checkout took place.
>>
>> Thus you have no way to capture the config of the (potentially many) node
>> step that did the checkout you want to use the credentials of.
>>
>> Now you could have two build step implementations, one for pipeline that
>> takes config, the other for old style jobs that goes hunting for the scm
>>
>>
>>> - are there use cases where a user may want to use eg the multi-scm and
>>>> check out more than one perhaps even with divergent credentials?
>>>>
>>> *No.* There is a single SCM source. I don't even think Team Concert SCM
>>> can cope with multi-SCM.
>>>
>>>
>> Yeah well then at some point somebody will fix that bug (if it doesn't
>> work with it) and then you'd be scuppered...
>>
>>
>>>
>>>
>>> Thanks Stephen for the quick answer! I'll implement the credentials
>>> field in the Build Step.
>>>
>>>
>>> On Tuesday, August 9, 2016 at 9:44:15 AM UTC+2, Stephen Connolly wrote:
>>>>
>>>>
>>>>
>>>> On Monday 8 August 2016, Rafael Rezende <[email protected]> wrote:
>>>>
>>>>> I'm developing a plugin that depends on the Team Concert plugin
>>>>> <https://wiki.jenkins-ci.org/display/JENKINS/Team+Concert+Plugin>. *TC
>>>>> plugin* has a Credentials field, used to connect to the Team Concert
>>>>> server.
>>>>> My plugin -- as a Build Step -- should reconnect to the server using
>>>>> the same credentials, but I would like to avoid the user having to select
>>>>> his credentials twice: first in the SCM configuration, then in the Build
>>>>> Step.
>>>>>
>>>>>
>>>>> The Team Concert plugin does not provide any environment variable to
>>>>> help me with that. No user ID, no credentials hash...
>>>>>
>>>>> Is there any way to reuse the SCM credentials? Or is that simply
>>>>> forbidden because of security concerns?
>>>>>
>>>>
>>>> So questions:
>>>>
>>>> - is there any use case where a user may actually want to use different
>>>> credentials in the build step than in the checkout?
>>>>
>>>> - are you writing a pipeline capable build step or one specifically
>>>> tailored for use in old-style jobs only?
>>>>
>>>> - are there use cases where a user may want to use eg the multi-scm and
>>>> check out more than one perhaps even with divergent credentials?
>>>>
>>>> If the answers are all yes, then you probably need to just accept that
>>>> it is a config option.
>>>>
>>>> If the answers are all no, then you can use run.getParent().getScm()
>>>> and borrow the credentials directly... But in doing this you prevent all
>>>> three use cases I hinted at with my questions
>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Jenkins Developers" 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-dev/02375c1a-91a
>>>>> 1-46b9-92fc-9198861946a1%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/02375c1a-91a1-46b9-92fc-9198861946a1%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>> --
>>>> Sent from my phone
>>>>
>>>
>>
>>
>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" 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/ms
>>> gid/jenkinsci-dev/feb7d9be-e96c-4f60-98a7-6242d425bdb8%40goo
>>> glegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/feb7d9be-e96c-4f60-98a7-6242d425bdb8%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Sent from my phone
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" 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-dev/348ea221-2c40-4913-82d2-c576903890b5%
> 40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/348ea221-2c40-4913-82d2-c576903890b5%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 Developers" 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-dev/CA%2BnPnMzSZ7PGYCDS07b9wJ2DLBWc%3DkyifcnhQZXXHpLgdPf4Og%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
