Unique name (current date+new build number) for build in jenkins Job

[Pradeep Drall]

Hi,

 

I would like to save the build file (ipa and apk file) with unique name 
(like current date+new build number), build number should be reset every 
day based on Jenkins job like

20190209.*1*

20190209.*2*

20190209.3

20190209.4

 

20190210.*1*

20190210*.2*

20190210.3

20190210.4

I tried in build name setter plugin but couldn't reset build number every 
day.

 

This functionality is available in TFS like $(date:MMdd)$(rev:.r).


Please suggest me how to implement this approach in jenkins job.


Regards,

Pradeep

-- 
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/7fd9b66c-2ad9-4d14-8d1f-62d7878087e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to configure $JENKINS_HOME/caches dir location?

[Mark Waite]

Used by multibranch pipeline and possibly by pipeline as far as I recall.

On Fri, Feb 8, 2019, 5:52 PM Calvin Park  It seems to contain some sort of git cache. Thankfully(?) all the
> directories are empty.
>
>> /mnt/nfs/jenkins_home$ ls caches/
>> git-0d341dcbcc7c33c4efc44a104b892b60
>> git-79660c3529cacbdbe1ac71b7c36e1a3f
>> git-0d341dcbcc7c33c4efc44a104b892b60@tmp
>> git-79660c3529cacbdbe1ac71b7c36e1a3f@tmp
>> git-0fba0b0ccfb8c3ca2809f860ea497fbf
>> git-84f1d58c7f2dde1b560bd3471e85cf5f
>> git-0fba0b0ccfb8c3ca2809f860ea497fbf@tmp
>> git-84f1d58c7f2dde1b560bd3471e85cf5f@tmp
>> git-117076ea5a481ebdd2beea321164041c
>> git-93d0b594de0d6af9e1ac33ea8dd03742
>> git-117076ea5a481ebdd2beea321164041c@tmp
>> git-93d0b594de0d6af9e1ac33ea8dd03742@tmp
>> git-20faeeea626404c43e0af02b3443a0ca
>> git-bedd02d2756f33f2b6dd8e496041e9a5
>> git-20faeeea626404c43e0af02b3443a0ca@tmp
>> git-bedd02d2756f33f2b6dd8e496041e9a5@tmp
>> git-663a4358cb957136aec86030ea76
>> git-ca5af9d29c97e0a07af654ef31dbcd93
>> git-663a4358cb957136aec86030ea76@tmp
>> git-cde48c33a9866d69b3dab200ae527b91
>> git-6c18e173e843c139db9b4bcd2949c277
>> git-cde48c33a9866d69b3dab200ae527b91@tmp
>> git-6c18e173e843c139db9b4bcd2949c277@tmp
>> git-ea66c44ab8389abea26eb7f2f93ee8d0
>> git-72cee31ae083a2db1f8fb009bcf624ed
>> git-ea66c44ab8389abea26eb7f2f93ee8d0@tmp
>> git-72cee31ae083a2db1f8fb009bcf624ed@tmp
>
>
>
> In order to minimize the performance hit from putting jenkins_home on NFS,
> I'm trying to find the directories which are frequently accessed
> directories and has many small files
>
>> /mnt/nfs/jenkins_home$ ls -d */
>> .cache/  ?
>> .groovy/ ?
>> .java/   ?
>> caches/  ?
>> config-history/
>> fingerprints/
>> init.groovy.d/
>> jobs/
>
>  builds/ moved out to local disk and not backed up
>>  workspace/  moved out to local disk and not backed up
>
> logs/
>>
> nodes/
>> plugins/   moved out to local disk and not backed up
>> secrets/
>> updates/
>> userContent/
>> users/
>> war/   moved out to local disk and not backed up
>> workflow-libs/
>>
>
> What are some of the other directories in here that I can/should move out
> of NFS? Ideally they should be ephemeral and frequently accessed.
>
> Thank you
>
>
>
> On Tuesday, February 5, 2019 at 6:08:46 AM UTC-8, Baptiste Mathus wrote:
>>
>> I've had a quick look, and I'm not sure I ever saw a caches directory
>> under JENKINS_HOME (this is very possible I just don't remember).
>> Can you possibly list what's in there so we can try and understand what
>> is generating this directory?
>>
>> We segregate data quite aggressively already in Evergreen and I do not
>> remember of such a directory/option.
>>
>> https://github.com/jenkins-infra/evergreen/blob/master/distribution/Dockerfile#L22-L34
>>
>> Thanks
>>
>> Le dim. 3 févr. 2019 à 00:44, Calvin Park  a écrit :
>>
>>> I'm running $JENKINS_HOME on NFS. Due to the performance penalty,
>>> I want to move out as many temp directories as I can to local disk.
>>>
>>> Thus far I've moved
>>>
>>>-
>>>
>>> -Djenkins.model.Jenkins.workspacesDir='/local_cache/workspace/${ITEM_FULL_NAME}'
>>>- --webroot=/local_cache/web
>>>- --pluginroot=/local_cache/plugin
>>>
>>> In $JENKINS_HOME there's caches directory which seems like an obvious
>>> choice to move out.
>>>
>>>1. Is there a way to configure the location for $JENKINS_HOME/caches?
>>>2. What are other directories that can be recreated, thus can be
>>>moved out of the NFS?
>>>
>>> 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 jenkinsci-use...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-users/6a923fd6-da83-484e-b57c-c899e08a56f3%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/998a1e68-9e5a-48e2-b1eb-389e6b5b4652%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 

Re: How to configure $JENKINS_HOME/caches dir location?

[Calvin Park]

This looks useful but I can't follow the thread. What was the change that 
was made at the end?

On Tuesday, February 5, 2019 at 9:06:19 AM UTC-8, Victor Martinez wrote:
>
> https://issues.jenkins-ci.org/browse/JENKINS-18578 provides some details 
> about fixing the 'cache' folder, is that what you need?
>

-- 
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/9eace463-2135-4dba-9150-4d74221083b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to configure $JENKINS_HOME/caches dir location?

[Calvin Park]

It seems to contain some sort of git cache. Thankfully(?) all the 
directories are empty.

> /mnt/nfs/jenkins_home$ ls caches/
> git-0d341dcbcc7c33c4efc44a104b892b60  
> git-79660c3529cacbdbe1ac71b7c36e1a3f
> git-0d341dcbcc7c33c4efc44a104b892b60@tmp  
> git-79660c3529cacbdbe1ac71b7c36e1a3f@tmp
> git-0fba0b0ccfb8c3ca2809f860ea497fbf  
> git-84f1d58c7f2dde1b560bd3471e85cf5f
> git-0fba0b0ccfb8c3ca2809f860ea497fbf@tmp  
> git-84f1d58c7f2dde1b560bd3471e85cf5f@tmp
> git-117076ea5a481ebdd2beea321164041c  
> git-93d0b594de0d6af9e1ac33ea8dd03742
> git-117076ea5a481ebdd2beea321164041c@tmp  
> git-93d0b594de0d6af9e1ac33ea8dd03742@tmp
> git-20faeeea626404c43e0af02b3443a0ca  
> git-bedd02d2756f33f2b6dd8e496041e9a5
> git-20faeeea626404c43e0af02b3443a0ca@tmp  
> git-bedd02d2756f33f2b6dd8e496041e9a5@tmp
> git-663a4358cb957136aec86030ea76  
> git-ca5af9d29c97e0a07af654ef31dbcd93
> git-663a4358cb957136aec86030ea76@tmp  
> git-cde48c33a9866d69b3dab200ae527b91
> git-6c18e173e843c139db9b4bcd2949c277  
> git-cde48c33a9866d69b3dab200ae527b91@tmp
> git-6c18e173e843c139db9b4bcd2949c277@tmp  
> git-ea66c44ab8389abea26eb7f2f93ee8d0
> git-72cee31ae083a2db1f8fb009bcf624ed  
> git-ea66c44ab8389abea26eb7f2f93ee8d0@tmp
> git-72cee31ae083a2db1f8fb009bcf624ed@tmp



In order to minimize the performance hit from putting jenkins_home on NFS, 
I'm trying to find the directories which are frequently accessed 
directories and has many small files

> /mnt/nfs/jenkins_home$ ls -d */
> .cache/  ?
> .groovy/ ?
> .java/   ?
> caches/  ?
> config-history/
> fingerprints/
> init.groovy.d/
> jobs/

 builds/ moved out to local disk and not backed up
>  workspace/  moved out to local disk and not backed up

logs/
>
nodes/
> plugins/   moved out to local disk and not backed up
> secrets/
> updates/
> userContent/
> users/
> war/   moved out to local disk and not backed up
> workflow-libs/
>

What are some of the other directories in here that I can/should move out 
of NFS? Ideally they should be ephemeral and frequently accessed.

Thank you



On Tuesday, February 5, 2019 at 6:08:46 AM UTC-8, Baptiste Mathus wrote:
>
> I've had a quick look, and I'm not sure I ever saw a caches directory 
> under JENKINS_HOME (this is very possible I just don't remember).
> Can you possibly list what's in there so we can try and understand what is 
> generating this directory?
>
> We segregate data quite aggressively already in Evergreen and I do not 
> remember of such a directory/option.
>
> https://github.com/jenkins-infra/evergreen/blob/master/distribution/Dockerfile#L22-L34
>
> Thanks
>
> Le dim. 3 févr. 2019 à 00:44, Calvin Park  > a écrit :
>
>> I'm running $JENKINS_HOME on NFS. Due to the performance penalty, I want 
>> to move out as many temp directories as I can to local disk.
>>
>> Thus far I've moved
>>
>>- 
>>
>> -Djenkins.model.Jenkins.workspacesDir='/local_cache/workspace/${ITEM_FULL_NAME}'
>>- --webroot=/local_cache/web
>>- --pluginroot=/local_cache/plugin
>>
>> In $JENKINS_HOME there's caches directory which seems like an obvious 
>> choice to move out.
>>
>>1. Is there a way to configure the location for $JENKINS_HOME/caches?
>>2. What are other directories that can be recreated, thus can be 
>>moved out of the NFS?
>>
>> 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 jenkinsci-use...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/6a923fd6-da83-484e-b57c-c899e08a56f3%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/998a1e68-9e5a-48e2-b1eb-389e6b5b4652%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using a Variable in Execute Shell that has a . in it

[Eric Fetzer]

That there is some crazy stuff Eric, but it worked, lol:

[OIS-Client] $ /bin/sh -xe /tmp/jenkins1618762877704683861.sh
++ grep 'deploy\.dir='
++ cut -d = -f 2
++ env
+ depdir=/deploy
+ echo 'deploy.dir == /deploy'
deploy.dir == /deploy


I can work that into this and avoid using an ant script or rewriting 15 
different jobs, THANKS!!!


On Friday, February 8, 2019 at 10:25:17 AM UTC-7, Eric Fetzer wrote:
>
> So it works fine to use a variable like build.dir as a parameter in a 
> build trigger.  I'm finding, however, that when I add it to a "execute 
> shell" command, it gets cut off at the ".".  For example:
>
> Execute Shell:
>
> Command:  ls -l $deploy.dir
>
> This tries to ls -l on .dir because $deploy is unset.  I would very much 
> appreciate any help.  I tried escaping the "." but that didn't work.  I 
> tried putting quotes around the variable, no help.  Any help would be 
> greatly appreciated!
>
> Thanks,
> Eric
>

-- 
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/aa6cfbc0-2ae0-4b8c-b309-c131ba7cd01f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using a Variable in Execute Shell that has a . in it

[Eric Pyle]

From Stack Overflow 
:


depdir=`env|grep "deploy\\.dir="|cut -d = -f 2`
echo "deploy.dir == $depdir"

-Eric

On 2/8/2019 3:29 PM, Eric Fetzer wrote:

Sorry, no again:

/tmp/jenkins6366597011192684630.sh: line 2: ${params.'deploy.dir'}: bad 
substitution

On Friday, February 8, 2019 at 10:25:17 AM UTC-7, Eric Fetzer wrote:

So it works fine to use a variable like build.dir as a parameter
in a build trigger.  I'm finding, however, that when I add it to a
"execute shell" command, it gets cut off at the ".".  For example:

Execute Shell:

Command:  ls -l $deploy.dir

This tries to ls -l on .dir because $deploy is unset.  I would
very much appreciate any help.  I tried escaping the "." but that
didn't work.  I tried putting quotes around the variable, no
help.  Any help would be greatly appreciated!

Thanks,
Eric

--
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/613d8387-e420-4898-b8da-47fbed8aeceb%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
Eric Pyle
Siemens PLM Software
Lebanon, NH
+1 603-277-3060
eric.p...@siemens.com
http://www.siemens.com/plm

--
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/b1d96288-8630-908c-b254-9beb6b18e0a7%40siemens.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using a Variable in Execute Shell that has a . in it

[Eric Fetzer]

Sorry, no again:

/tmp/jenkins6366597011192684630.sh: line 2: ${params.'deploy.dir'}: bad 
substitution


On Friday, February 8, 2019 at 10:25:17 AM UTC-7, Eric Fetzer wrote:
>
> So it works fine to use a variable like build.dir as a parameter in a 
> build trigger.  I'm finding, however, that when I add it to a "execute 
> shell" command, it gets cut off at the ".".  For example:
>
> Execute Shell:
>
> Command:  ls -l $deploy.dir
>
> This tries to ls -l on .dir because $deploy is unset.  I would very much 
> appreciate any help.  I tried escaping the "." but that didn't work.  I 
> tried putting quotes around the variable, no help.  Any help would be 
> greatly appreciated!
>
> Thanks,
> Eric
>

-- 
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/613d8387-e420-4898-b8da-47fbed8aeceb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using a Variable in Execute Shell that has a . in it

[Slide]

What about ${params.'deploy.dir'}

On Fri, Feb 8, 2019 at 12:59 PM Eric Fetzer  wrote:

> Second one is:
>
> /tmp/jenkins7135875844305012846.sh: line 2: deploy.dir: syntax error: invalid 
> arithmetic operator (error token is ".dir")
>
>
> On Friday, February 8, 2019 at 10:25:17 AM UTC-7, Eric Fetzer wrote:
>>
>> So it works fine to use a variable like build.dir as a parameter in a
>> build trigger.  I'm finding, however, that when I add it to a "execute
>> shell" command, it gets cut off at the ".".  For example:
>>
>> Execute Shell:
>>
>> Command:  ls -l $deploy.dir
>>
>> This tries to ls -l on .dir because $deploy is unset.  I would very much
>> appreciate any help.  I tried escaping the "." but that didn't work.  I
>> tried putting quotes around the variable, no help.  Any help would be
>> greatly appreciated!
>>
>> Thanks,
>> Eric
>>
> --
> 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/e3d5-f48d-40e9-ad39-3d6a6014ff8b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Website: http://earl-of-code.com

-- 
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/CAPiUgVe-ROJTpbrutUtwR1pMcT0aEkc0qhwaAbOD%3D%3D%2Ba_D96_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using a Variable in Execute Shell that has a . in it

[Eric Fetzer]

Second one is:

/tmp/jenkins7135875844305012846.sh: line 2: deploy.dir: syntax error: invalid 
arithmetic operator (error token is ".dir")


On Friday, February 8, 2019 at 10:25:17 AM UTC-7, Eric Fetzer wrote:
>
> So it works fine to use a variable like build.dir as a parameter in a 
> build trigger.  I'm finding, however, that when I add it to a "execute 
> shell" command, it gets cut off at the ".".  For example:
>
> Execute Shell:
>
> Command:  ls -l $deploy.dir
>
> This tries to ls -l on .dir because $deploy is unset.  I would very much 
> appreciate any help.  I tried escaping the "." but that didn't work.  I 
> tried putting quotes around the variable, no help.  Any help would be 
> greatly appreciated!
>
> Thanks,
> Eric
>

-- 
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/e3d5-f48d-40e9-ad39-3d6a6014ff8b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using a Variable in Execute Shell that has a . in it

[Eric Fetzer]

That was the first, let me try the second.

On Friday, February 8, 2019 at 10:25:17 AM UTC-7, Eric Fetzer wrote:
>
> So it works fine to use a variable like build.dir as a parameter in a 
> build trigger.  I'm finding, however, that when I add it to a "execute 
> shell" command, it gets cut off at the ".".  For example:
>
> Execute Shell:
>
> Command:  ls -l $deploy.dir
>
> This tries to ls -l on .dir because $deploy is unset.  I would very much 
> appreciate any help.  I tried escaping the "." but that didn't work.  I 
> tried putting quotes around the variable, no help.  Any help would be 
> greatly appreciated!
>
> Thanks,
> Eric
>

-- 
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/a87113cd-5243-4b48-abfa-97e28bf5d921%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using a Variable in Execute Shell that has a . in it

[Eric Fetzer]

Nope:

/tmp/jenkins8691176514212713317.sh: line 2: ${params.get('deploy.dir')}: bad 
substitution



On Friday, February 8, 2019 at 10:25:17 AM UTC-7, Eric Fetzer wrote:
>
> So it works fine to use a variable like build.dir as a parameter in a 
> build trigger.  I'm finding, however, that when I add it to a "execute 
> shell" command, it gets cut off at the ".".  For example:
>
> Execute Shell:
>
> Command:  ls -l $deploy.dir
>
> This tries to ls -l on .dir because $deploy is unset.  I would very much 
> appreciate any help.  I tried escaping the "." but that didn't work.  I 
> tried putting quotes around the variable, no help.  Any help would be 
> greatly appreciated!
>
> Thanks,
> Eric
>

-- 
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/d38f3396-22d6-481e-aeae-718ce8101908%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using a Variable in Execute Shell that has a . in it

[Arnaud bourree]

or ${params['deploy.dir']}

Le ven. 8 févr. 2019 à 20:23, Arnaud bourree  a
écrit :

> try: ${params.get('deploy.dir')}
>
> Le ven. 8 févr. 2019 à 20:19, Eric Fetzer  a
> écrit :
>
>> Are you saying that it's not possible to make this work?  The .'s are
>> already in there.  I guess I could write an ant script and just use them
>> inside there because they work fine as parameters to a script...
>>
>> On Friday, February 8, 2019 at 10:25:17 AM UTC-7, Eric Fetzer wrote:
>>>
>>> So it works fine to use a variable like build.dir as a parameter in a
>>> build trigger.  I'm finding, however, that when I add it to a "execute
>>> shell" command, it gets cut off at the ".".  For example:
>>>
>>> Execute Shell:
>>>
>>> Command:  ls -l $deploy.dir
>>>
>>> This tries to ls -l on .dir because $deploy is unset.  I would very much
>>> appreciate any help.  I tried escaping the "." but that didn't work.  I
>>> tried putting quotes around the variable, no help.  Any help would be
>>> greatly appreciated!
>>>
>>> Thanks,
>>> Eric
>>>
>> --
>> 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/cf3db8bc-86be-43b2-a316-891976614704%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/CAESUf_CUAwfNkCZxo2rDkBzwvdP9-9ANmB9k3uSc62YnvJsMNg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using a Variable in Execute Shell that has a . in it

[Arnaud bourree]

try: ${params.get('deploy.dir')}

Le ven. 8 févr. 2019 à 20:19, Eric Fetzer  a écrit :

> Are you saying that it's not possible to make this work?  The .'s are
> already in there.  I guess I could write an ant script and just use them
> inside there because they work fine as parameters to a script...
>
> On Friday, February 8, 2019 at 10:25:17 AM UTC-7, Eric Fetzer wrote:
>>
>> So it works fine to use a variable like build.dir as a parameter in a
>> build trigger.  I'm finding, however, that when I add it to a "execute
>> shell" command, it gets cut off at the ".".  For example:
>>
>> Execute Shell:
>>
>> Command:  ls -l $deploy.dir
>>
>> This tries to ls -l on .dir because $deploy is unset.  I would very much
>> appreciate any help.  I tried escaping the "." but that didn't work.  I
>> tried putting quotes around the variable, no help.  Any help would be
>> greatly appreciated!
>>
>> Thanks,
>> Eric
>>
> --
> 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/cf3db8bc-86be-43b2-a316-891976614704%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/CAESUf_CdJgUuMxVx5F7KREGhv3Gg%2BSwwOxLhiCTVzuh%2B%3DHHJSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using a Variable in Execute Shell that has a . in it

[Eric Fetzer]

Are you saying that it's not possible to make this work?  The .'s are 
already in there.  I guess I could write an ant script and just use them 
inside there because they work fine as parameters to a script...

On Friday, February 8, 2019 at 10:25:17 AM UTC-7, Eric Fetzer wrote:
>
> So it works fine to use a variable like build.dir as a parameter in a 
> build trigger.  I'm finding, however, that when I add it to a "execute 
> shell" command, it gets cut off at the ".".  For example:
>
> Execute Shell:
>
> Command:  ls -l $deploy.dir
>
> This tries to ls -l on .dir because $deploy is unset.  I would very much 
> appreciate any help.  I tried escaping the "." but that didn't work.  I 
> tried putting quotes around the variable, no help.  Any help would be 
> greatly appreciated!
>
> Thanks,
> Eric
>

-- 
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/cf3db8bc-86be-43b2-a316-891976614704%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using a Variable in Execute Shell that has a . in it

[Arnaud bourree]

Do not use dot in parameter names, prefer camel case, kebab case or
skeleton case

Le ven. 8 févr. 2019 à 20:09, Eric Fetzer  a écrit :

> deploy.dir is a string parameter at the top of the job:
>
> [image: Capture.JPG]
>
>
>
>
> On Friday, February 8, 2019 at 10:25:17 AM UTC-7, Eric Fetzer wrote:
>>
>> So it works fine to use a variable like build.dir as a parameter in a
>> build trigger.  I'm finding, however, that when I add it to a "execute
>> shell" command, it gets cut off at the ".".  For example:
>>
>> Execute Shell:
>>
>> Command:  ls -l $deploy.dir
>>
>> This tries to ls -l on .dir because $deploy is unset.  I would very much
>> appreciate any help.  I tried escaping the "." but that didn't work.  I
>> tried putting quotes around the variable, no help.  Any help would be
>> greatly appreciated!
>>
>> Thanks,
>> Eric
>>
> --
> 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/95ec0a54-537f-4726-9245-bf430147d298%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/CAESUf_BVcdjNi9Pq9MVUnL3gn1kgbKAUA5zJA5Z_VKw0GarmCw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using a Variable in Execute Shell that has a . in it

[Eric Fetzer]

If I renamed it deployDir, just using $deployDir would work, but this is a 
child job where the variable is set in the parent and used in this job as 
well so there would be a lot to change to get that working.  I'd prefer to 
be able to just use deploy.dir.  Thanks!

On Friday, February 8, 2019 at 10:25:17 AM UTC-7, Eric Fetzer wrote:
>
> So it works fine to use a variable like build.dir as a parameter in a 
> build trigger.  I'm finding, however, that when I add it to a "execute 
> shell" command, it gets cut off at the ".".  For example:
>
> Execute Shell:
>
> Command:  ls -l $deploy.dir
>
> This tries to ls -l on .dir because $deploy is unset.  I would very much 
> appreciate any help.  I tried escaping the "." but that didn't work.  I 
> tried putting quotes around the variable, no help.  Any help would be 
> greatly appreciated!
>
> Thanks,
> Eric
>

-- 
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/920f1d04-3794-481b-bc8f-2307fffe8801%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using a Variable in Execute Shell that has a . in it

[Eric Fetzer]

deploy.dir is a string parameter at the top of the job:

[image: Capture.JPG]




On Friday, February 8, 2019 at 10:25:17 AM UTC-7, Eric Fetzer wrote:
>
> So it works fine to use a variable like build.dir as a parameter in a 
> build trigger.  I'm finding, however, that when I add it to a "execute 
> shell" command, it gets cut off at the ".".  For example:
>
> Execute Shell:
>
> Command:  ls -l $deploy.dir
>
> This tries to ls -l on .dir because $deploy is unset.  I would very much 
> appreciate any help.  I tried escaping the "." but that didn't work.  I 
> tried putting quotes around the variable, no help.  Any help would be 
> greatly appreciated!
>
> Thanks,
> Eric
>

-- 
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/95ec0a54-537f-4726-9245-bf430147d298%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using a Variable in Execute Shell that has a . in it

[Arnaud bourree]

${deploy.dir} means attribute "dir" of object "deploy".
How do you setup deploy object?

Le ven. 8 févr. 2019 à 18:25, Eric Fetzer  a écrit :

> So it works fine to use a variable like build.dir as a parameter in a
> build trigger.  I'm finding, however, that when I add it to a "execute
> shell" command, it gets cut off at the ".".  For example:
>
> Execute Shell:
>
> Command:  ls -l $deploy.dir
>
> This tries to ls -l on .dir because $deploy is unset.  I would very much
> appreciate any help.  I tried escaping the "." but that didn't work.  I
> tried putting quotes around the variable, no help.  Any help would be
> greatly appreciated!
>
> Thanks,
> Eric
>
> --
> 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/bcb946d6-f25e-4bb3-8fc1-469986804a31%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/CAESUf_BUUgh9%2B-DNKRDzz9bkw37fjAxY3Qvg-GA%3DGWreS%2BPUkQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using a Variable in Execute Shell that has a . in it

[Eric Fetzer]

Here's what I put in:

sh """

ls -l ${deploy.dir}

"""

Here's what I got:

ls -l ${deploy.dir}

: bad substitution




On Friday, February 8, 2019 at 10:25:17 AM UTC-7, Eric Fetzer wrote:
>
> So it works fine to use a variable like build.dir as a parameter in a 
> build trigger.  I'm finding, however, that when I add it to a "execute 
> shell" command, it gets cut off at the ".".  For example:
>
> Execute Shell:
>
> Command:  ls -l $deploy.dir
>
> This tries to ls -l on .dir because $deploy is unset.  I would very much 
> appreciate any help.  I tried escaping the "." but that didn't work.  I 
> tried putting quotes around the variable, no help.  Any help would be 
> greatly appreciated!
>
> Thanks,
> Eric
>

-- 
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/8f336f8d-1780-4381-bce6-82eeec5d68a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using a Variable in Execute Shell that has a . in it

[Viacheslav Dubrovskyi]

Hi Eric

Is it work for you?

sh """

    ls -l ${deploy.dir}

"""

08.02.2019 19:25, Eric Fetzer пишет:
So it works fine to use a variable like build.dir as a parameter in a 
build trigger.  I'm finding, however, that when I add it to a "execute 
shell" command, it gets cut off at the ".".  For example:


Execute Shell:

Command:  ls -l $deploy.dir

This tries to ls -l on .dir because $deploy is unset.  I would very 
much appreciate any help.  I tried escaping the "." but that didn't 
work.  I tried putting quotes around the variable, no help.  Any help 
would be greatly appreciated!


Thanks,
Eric
--
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/bcb946d6-f25e-4bb3-8fc1-469986804a31%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
WBD,
Viacheslav Dubrovskyi

--
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/4f0f6166-c465-046e-a784-53bc636f222a%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: Криптографическая подпись S/MIME

Using a Variable in Execute Shell that has a . in it

[Eric Fetzer]

So it works fine to use a variable like build.dir as a parameter in a build 
trigger.  I'm finding, however, that when I add it to a "execute shell" 
command, it gets cut off at the ".".  For example:

Execute Shell:

Command:  ls -l $deploy.dir

This tries to ls -l on .dir because $deploy is unset.  I would very much 
appreciate any help.  I tried escaping the "." but that didn't work.  I 
tried putting quotes around the variable, no help.  Any help would be 
greatly appreciated!

Thanks,
Eric

-- 
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/bcb946d6-f25e-4bb3-8fc1-469986804a31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to call jenkins custom plugin from Pipeline

[Slide]

In order for your plugin to work in pipeline jobs, you need to implement
SimpleBuildStep in your recorder and then override the perform method that
takes a Run and FilePath instead of an AbstractBuild. You do not need both
overrides, the one that I mentioned first will work for both freestyle and
pipeline jobs. In addition, you can add an @Symbol annotation to your
descriptor and make a shorthand for calling your step instead of having to
use `step()`

On Fri, Feb 8, 2019, 04:27 prasad.pofali via Jenkins Users <
jenkinsci-users@googlegroups.com wrote:

> I am referring a custom Jenkins plugin from here (
> https://github.com/pritic/testExample)
>
> This plugin is working fine with the traditional approach of building
> jenkins jobs.
>
> When I tried to call this plugin using a declarative pipeline, it caused
> an exception. The following is the pipeline code.
>
> import hudson.model.*
> checkout filesystem(clearWorkspace: false, copyHidden: false, path:
> 'C:\\java-junit-sample-master\\java-junit-sample-master')
>
> pipeline {
> agent any
> stages {
> stage('Build and Run Tests') {
> steps {
> node {
> step([$class : 'TestExamplePublisher', applications:[name: 'PrasadP']])
> }
> }
> }
> }
> }
>
>
> Below is the exception stacktrace:
>
> [Pipeline] End of Pipeline
>>
>> org.jenkinsci.plugins.workflow.steps.MissingContextVariableException:
>> Required context class hudson.FilePath is missing
>> at
>> org.jenkinsci.plugins.workflow.steps.StepDescriptor.checkContextAvailability(StepDescriptor.java:260)
>> at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:262)
>> at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:178)
>> at
>> org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:122)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>> at java.lang.reflect.Method.invoke(Unknown Source)
>> at
>> org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
>> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
>> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1213)
>> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
>> at
>> org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:42)
>> at
>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
>> at
>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
>> at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:157)
>> at
>> org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:23)
>> at
>> org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:155)
>> at
>> org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:142)
>> at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:155)
>> at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:159)
>> at
>> com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:17)
>> at WorkflowScript.run(WorkflowScript:2)
>> at ___cps.transform___(Native Method)
>> at
>> com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57)
>> at
>> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
>> at
>> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>> at java.lang.reflect.Method.invoke(Unknown Source)
>> at
>> com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
>> at
>> com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:60)
>> at
>> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
>> at
>> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>> at java.lang.reflect.Method.invoke(Unknown Source)
>> at
>> com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
>> at
>> com.cloudbees.groovy.cps.impl.CollectionLiteralBlock$ContinuationImpl.dispatch(CollectionLiteralBlock.java:55)
>> at
>> com.cloudbees.groovy.cps.impl.CollectionLiteralBlock$ContinuationImpl.item(CollectionLiteralBlock.java:45)
>> at 

RE: How to call jenkins custom plugin from Pipeline

[Reinhold Füreder]

Hi Prasad,

look at the stacktrace:
at WorkflowScript.run(WorkflowScript:2)
then you see why:

  *   On line #2
checkout filesystem(clearWorkspace: false, copyHidden: false, path: 
'C:\\java-junit-sample-master\\java-junit-sample-master')

  *   … is maybe completely wrong, or in wrong scope, but definitely also not 
within a node{ … } block

HTH Reinhold

From: prasad.pofali via Jenkins Users 
Sent: Freitag, 8. Februar 2019 11:57
To: Jenkins Users 
Subject: How to call jenkins custom plugin from Pipeline

I am referring a custom Jenkins plugin from here 
(https://github.com/pritic/testExample)

This plugin is working fine with the traditional approach of building jenkins 
jobs.

When I tried to call this plugin using a declarative pipeline, it caused an 
exception. The following is the pipeline code.

import hudson.model.*
checkout filesystem(clearWorkspace: false, copyHidden: false, path: 
'C:\\java-junit-sample-master\\java-junit-sample-master')

pipeline {
agent any
stages {
stage('Build and Run Tests') {
steps {
  node {
  step([$class : 'TestExamplePublisher', applications:[name: 
'PrasadP']])
  }
}
}
}
}

Below is the exception stacktrace:

[Pipeline] End of Pipeline
org.jenkinsci.plugins.workflow.steps.MissingContextVariableException: Required 
context class hudson.FilePath is missing
at 
org.jenkinsci.plugins.workflow.steps.StepDescriptor.checkContextAvailability(StepDescriptor.java:260)
at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:262)
at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:178)
at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:122)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1213)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
at 
org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:42)
at 
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
at 
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:157)
at 
org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:23)
at 
org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:155)
at 
org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:142)
at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:155)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:159)
at 
com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:17)
at WorkflowScript.run(WorkflowScript:2)
at ___cps.transform___(Native Method)
at 
com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57)
at 
com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
at 
com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at 
com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at 
com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:60)
at 
com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
at 
com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at 
com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at 
com.cloudbees.groovy.cps.impl.CollectionLiteralBlock$ContinuationImpl.dispatch(CollectionLiteralBlock.java:55)
at 
com.cloudbees.groovy.cps.impl.CollectionLiteralBlock$ContinuationImpl.item(CollectionLiteralBlock.java:45)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at 

How to call jenkins custom plugin from Pipeline

[prasad.pofali via Jenkins Users]

I am referring a custom Jenkins plugin from here 
(https://github.com/pritic/testExample)

This plugin is working fine with the traditional approach of building 
jenkins jobs.

When I tried to call this plugin using a declarative pipeline, it caused an 
exception. The following is the pipeline code.

import hudson.model.*
checkout filesystem(clearWorkspace: false, copyHidden: false, path: 
'C:\\java-junit-sample-master\\java-junit-sample-master')

pipeline {
agent any
stages {
stage('Build and Run Tests') {
steps {
node {
step([$class : 'TestExamplePublisher', applications:[name: 'PrasadP']])
}
}
}
}
}


Below is the exception stacktrace:

[Pipeline] End of Pipeline
>
> org.jenkinsci.plugins.workflow.steps.MissingContextVariableException: 
> Required context class hudson.FilePath is missing
> at 
> org.jenkinsci.plugins.workflow.steps.StepDescriptor.checkContextAvailability(StepDescriptor.java:260)
> at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:262)
> at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:178)
> at 
> org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:122)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93)
> at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1213)
> at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022)
> at 
> org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:42)
> at 
> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
> at 
> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
> at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:157)
> at 
> org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:23)
> at 
> org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:155)
> at 
> org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:142)
> at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:155)
> at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:159)
> at 
> com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:17)
> at WorkflowScript.run(WorkflowScript:2)
> at ___cps.transform___(Native Method)
> at 
> com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57)
> at 
> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
> at 
> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at 
> com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
> at 
> com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:60)
> at 
> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
> at 
> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at 
> com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
> at 
> com.cloudbees.groovy.cps.impl.CollectionLiteralBlock$ContinuationImpl.dispatch(CollectionLiteralBlock.java:55)
> at 
> com.cloudbees.groovy.cps.impl.CollectionLiteralBlock$ContinuationImpl.item(CollectionLiteralBlock.java:45)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at 
> com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
> at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
> at com.cloudbees.groovy.cps.Next.step(Next.java:83)
> at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174)
> at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163)
> at 
> 

Upgrading from Jenkins LTS 2.150.1 to 2.150.2 - Slowness and Workaround

[Kurt Routley, MSc]

Hello,


After upgrading from Jenkins LTS 2.150.1 to 2.150.2, we observed 
significant slowdown when loading any page on Jenkins. Load times were 
previously sub-second, and were now taking 4 seconds or longer after the 
upgrade.

 

Workaround for this was to clear cookies from the local browser for the 
Jenkins instance. After re-login to Jenkins, load times were back to normal 
for the user.

 

Since the security advisory for 
https://jenkins.io/security/advisory/2019-01-16/ was the main motivation 
for the upgrade, you may want to mention in the security advisory about the 
additional step for users to clear their cookies for the Jenkins instance, 
as the pre-existing cookies appear to be incompatible.

 

Thanks,

- Kurt Routley, MSc 

-- 
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/590bf020-b6d6-41f6-9c61-c3eaad8a40e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Active Directory plugin warning: TLS is not correctly configured

[wfollonier]

Hello Andreas,

Thank you for the report on such issue. I 
created https://issues.jenkins-ci.org/browse/JENKINS-56047 for you. 
Normally for bug or weird behavior, you can just create a ticket in the 
JENKINS project.

We will try to provide a correction ASAP.

Wadeck

On Tuesday, January 29, 2019 at 11:17:12 PM UTC+1, Andreas Goeb wrote:
>
> Dear fellow Jenkins users, 
>
> I came across an issue today that I just cannot figure out myself. I hope 
> this is the correct place to ask for help. 
>
> *Problem:* 
>
> After some connection issues with Active Directory and following 
> reconfiguration, Jenkins now shows the warning „TLS is not correctly 
> configured on Active Directory plugin.Please, change to a more secured 
> option;" 
>
> *Environment:* 
>
> When the issue occurred for the first time this morning, I was using 
> Jenkins 2.150.2 with Active Directory plugin 2.11 and the following 
> settings 
>
> - StartTLS: true 
> - TRUST_ALL_CERTIFICATES 
>
> *What I did so far:* 
>
> I thought the reason for the warning might be the TRUST_ALL_CERTIFICATES 
> option, so I tried to disable it. However, it is not shown in the Global 
> Security settings anymore, nor is it contained in the settings.xml file. 
> So, I followed the plugin's documentation wiki page and performed the 
> following steps for proper TLS/LDAPS configuration: 
>
> - set the 
> hudson.plugins.active_directory.ActiveDirectorySecurityRealm.forceLdaps=true 
> system property 
> - change the domain controller port in the plugin’s settings to 3269 
> - copy the JVM’s „cacerts" trust store and import the server certificate 
> into the copy 
> - set the javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword 
> system properties to point to the copy 
> - configure a custom logger for ActiveDirectorySecurityRealm and log level 
> FINER 
>
> The log now shows successful LDAPS connections over port 3269, and users 
> can log in. However, the warning about insecure TLS configuration is still 
> shown. 
>
> Does any of you know what the reason for the warning may be and which 
> configuration I might still have to change? 
>
> Thanks a lot, 
> Andreas

-- 
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/c3f9ccec-e213-4aaf-a011-265c3eb3ce26%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.