Can anyone please send an example script or any other reference for deploying to docker container using pipeline jenkins plugin?

[harsha vardhan]

I couldnt find any help on how to automate deployment of war file to new 
aws ec2 instance or docker container using pipeline feature of jenkins. Can 
anyone send documentation or pipeline script sample to deploy to aws ec2 
instance?

-- 
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/d482ec22-a450-4d84-8c76-699fff7c33c7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins 2.28 fails with a stack trace when one clicks Manage Jenkins and then clicks Configure System

[Rinaldo DiGiorgio]

Thanks it is also happening with 2.29 -- 

javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: 
jar:file:/jpgdata/jpg-infra-ci/jenkins/jenkins-home/war/WEB-INF/lib/jenkins-core-2.29.jar!/jenkins/model/Jenkins/configure.jelly:59:84:
  
jar:file:/jpgdata/jpg-infra-ci/jenkins/jenkins-home/war/WEB-INF/lib/jenkins-core-2.29.jar!/lib/form/section.jelly:48:21:
  
org.kohsuke.stapler.lang.KlassNavigator.getFunctions(Ljava/lang/Object;)Ljava/util/List;
at 



On Monday, November 7, 2016 at 7:26:16 AM UTC-5, Daniel Beck wrote:
>
> Tracked as JENKINS-39414. 
>
> We really need to change the message shown on the exception screen :( 
>
> > On 07.11.2016, at 13:22, Rinaldo DiGiorgio  > wrote: 
> > 
> > javax.servlet.ServletException: 
> org.apache.commons.jelly.JellyTagException: 
> jar:file:/jpgdata/jpg-infra-ci/jenkins/jenkins-home/war/WEB-INF/lib/jenkins-core-2.28.jar!/jenkins/model/Jenkins/configure.jelly:59:84:
>  
>  
> jar:file:/jpgdata/jpg-infra-ci/jenkins/jenkins-home/war/WEB-INF/lib/jenkins-core-2.28.jar!/lib/form/section.jelly:48:21:
>  
>  
> org.kohsuke.stapler.lang.KlassNavigator.getDeclaredFields(Ljava/lang/Object;)Ljava/util/List;
>  
>
> > at 
> org.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.java:103) 
> > at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) 
> > at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) 
> > at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) 
> > 
> > 
> > 
> > -- 
> > 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/c9498847-7d82-44c0-9288-b2f41c017d01%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/4fbe81b4-7f41-4f6c-893f-7afac72aefd8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Versioning the entrie system configuration -- not artifacts

[Rinaldo DiGiorgio]

Thanks but I was doing CI in 1980 and it is IMO a non started that the core 
system doesn't implement versioning and uses a local file store instead of 
a network based store. Given the advances in technology I am seeing less 
and less value in systems that require more and more plugins for basic 
things that should be part of the core.

On Monday, November 7, 2016 at 7:45:57 AM UTC-5, Rinaldo DiGiorgio wrote:
>
> Hi,
>
>   I tried to version my jobs with the Jobs SCM plugin for example and it 
> often gets confused and ends up making my system unusable. Perhaps an 
> entire rewrite is needed and the backend store needs to move to something 
> like redis. I  don't think version control should be done with optional 
> plugins. It should be part of the core system and all configuration data 
> should be in a network store.  
>
>   I can see a solution using docker where one makes a base image.  What 
> happens when you change the configuration however. Do you make a new docker 
> base image?  Some organizations want all the source code to generate an 
> image in some type of SCM and this is the issue.  If you change job 
> configurations or config params you just incurred the hit of a new image 
> generation cycle.  Perhaps I am not looking it in the right way or in the 
> future when everything is pipeline the configuration is pipeline with 
> supporting json and property files.
>
> Rinald
>
>
>

-- 
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/310010e3-af9c-4091-ba56-44a54510cff2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: jenkins 2.29 | console log output

[Baptiste Mathus]

Known issue. Don't use 2.29.

2.30 is going to be released in the next few hours with the fix.

See dev ml if you're interested in details.

Cheers

Le 7 nov. 2016 4:59 PM, "Arnaud bourree"  a
écrit :

> Hello,
>
> Since I upgrade from 2.28 to 2.29, console log only print step name but no
> more step output.
> I didn't see in change-log any point related to a console log new format.
>
> Did someone else fail on same issue?
>
> Regards,
>
> Arnaud.
>
> --
> 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_CTiqCm7S7wPtG%3D1P-bP6y6hOY%
> 3DgTH2RpGmB9vDaTwuSA%40mail.gmail.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/CANWgJS7QriPR8goGEQB_zYR56%2B8csuEkO%2BYJQp0As_wPGbg2gw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Versioning the entrie system configuration -- not artifacts

[Michael Lasevich]

I did not mean to start a religious war - like I said, this is only an 
opinion. I only offered that Pipelines are a bit newer - and while CPS is a 
bear, it does appear, at least to me, to simplify things drastically - 
allowing much simpler setups and avoiding situations where it "gets 
confused and ends up making my system unusable". Perhaps this is the answer 
to original poster's current frustrations. Or maybe not. 

-M


On Monday, November 7, 2016 at 2:23:12 PM UTC-8, Victor Martinez wrote:
>
> Both of them are good but they have different approaches... Although, IMO, 
> Pipeline is still an incubating feature atm.
> I wouldn't say Pipelines are better or worst or even obsolete or modern. 
> If you go for configuration as code, by definition, code should be 
> testable, and I could go further by saying testable locally and 
> automatically, and unfortunately I haven't not seen that feature yet with 
> the Pipelines.
>
> Cheers
>
> On Monday, 7 November 2016 20:53:35 UTC, Michael Lasevich wrote:
>>
>> Ahh, "Job DSL",  I remember that. It was a good thing when it was the 
>> only game in town, but (in my opinion) Pipelines pretty much made it 
>> obsolete. Of course it is a matter of opinion, but if you are finding Jobs 
>> DSL too complicated, Pipelines may be just right for you - it removes a lot 
>> of the complexity, and makes your entire build process far simpler - you no 
>> longer need a rabbit-warren of jobs, and with MultiBranch Pipelines + 
>> Global Libs + something like Slack notifications, your devs may not even 
>> need to login to Jenkins server - just commit code and see notification 
>> that the job was created(if needed) and build was complete :-) Join the 
>> modern age :-)
>>
>> -M
>>
>> On Monday, November 7, 2016 at 11:55:20 AM UTC-8, Victor Martinez wrote:
>>>
>>> Give a try job-dsl-plugin 
>>> - https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin
>>>
>>> Supports 1000+ jenkins plugins, local testing, gradle integration, same 
>>> Jenkins job paradigm, DRY concept and a bunch of other benefits besides of 
>>> converting jobs in code and therefore scm oriented.
>>>
>>> Cheers
>>>
>>>

-- 
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/372afae4-6fb7-4b7a-9ccc-5308d9e0f629%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Adding another co-admin for a plugin

[Ryan Black]

All,

My Google Fu is lacking in finding an answer to this, so I'm trying here. 

If I wish to add another Github user as co-admin for a plugin, ideally each 
of us unable to remove the other, how is this best accomplished? I don't 
believe I have the ability to modify members of the pluginname-developers 
group that is used for this purpose under jenkinssci.


Thank you in advance!


-- 

Ryan Black

-- 
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/e13265dc-f0a0-4fa7-9a0c-10d00b6b09e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Versioning the entrie system configuration -- not artifacts

[Sean McNamara]

On Mon, Nov 7, 2016 at 3:53 PM, Michael Lasevich  wrote:
> Ahh, "Job DSL",  I remember that. It was a good thing when it was the only
> game in town, but (in my opinion) Pipelines pretty much made it obsolete. Of
> course it is a matter of opinion, but if you are finding Jobs DSL too
> complicated, Pipelines may be just right for you - it removes a lot of the
> complexity, and makes your entire build process far simpler - you no longer
> need a rabbit-warren of jobs, and with MultiBranch Pipelines + Global Libs +
> something like Slack notifications, your devs may not even need to login to
> Jenkins server - just commit code and see notification that the job was
> created(if needed) and build was complete :-) Join the modern age :-)


The big limitation of Pipelines is that Pipelines' Groovy code isn't
actually Groovy. It's a small-ish subset of Groovy that breaks in ways
that aren't extremely well-documented. You can't just import any
arbitrary Groovy code and expect it to work. A lot of folks who are
currently using the Groovy plugin running system groovy or external
groovy scripts will have to do major rewrites to dumb things down for
the Pipeline plugin.

Until/unless pipelines support all of Groovy, it's difficult to
recommend for scripts larger than a couple of lines. IMO, anyway.

Sean

>
> -M
>
> On Monday, November 7, 2016 at 11:55:20 AM UTC-8, Victor Martinez wrote:
>>
>> Give a try job-dsl-plugin
>> - https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin
>>
>> Supports 1000+ jenkins plugins, local testing, gradle integration, same
>> Jenkins job paradigm, DRY concept and a bunch of other benefits besides of
>> converting jobs in code and therefore scm oriented.
>>
>> Cheers
>
> --
> 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/5200fb48-2be3-4f51-a26f-08681272a80c%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/CAPAActcpPLKXV%2B7S-p1oqELrw0u0p8L_Z0imP14j1ozMddDpBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Versioning the entrie system configuration -- not artifacts

[Victor Martinez]

Both of them are good but they have different approaches... Although, IMO, 
Pipeline is still an incubating feature atm.
I wouldn't say Pipelines are better or worst or even obsolete or modern. If 
you go for configuration as code, by definition, code should be testable, 
and I could go further by saying testable locally and automatically, and 
unfortunately I haven't not seen that feature yet with the Pipelines.

Cheers

On Monday, 7 November 2016 20:53:35 UTC, Michael Lasevich wrote:
>
> Ahh, "Job DSL",  I remember that. It was a good thing when it was the only 
> game in town, but (in my opinion) Pipelines pretty much made it obsolete. 
> Of course it is a matter of opinion, but if you are finding Jobs DSL too 
> complicated, Pipelines may be just right for you - it removes a lot of the 
> complexity, and makes your entire build process far simpler - you no longer 
> need a rabbit-warren of jobs, and with MultiBranch Pipelines + Global Libs 
> + something like Slack notifications, your devs may not even need to login 
> to Jenkins server - just commit code and see notification that the job was 
> created(if needed) and build was complete :-) Join the modern age :-)
>
> -M
>
> On Monday, November 7, 2016 at 11:55:20 AM UTC-8, Victor Martinez wrote:
>>
>> Give a try job-dsl-plugin 
>> - https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin
>>
>> Supports 1000+ jenkins plugins, local testing, gradle integration, same 
>> Jenkins job paradigm, DRY concept and a bunch of other benefits besides of 
>> converting jobs in code and therefore scm oriented.
>>
>> Cheers
>>
>>

-- 
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/82387c59-9217-42fb-bbe3-d8ce9740b114%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Most Jenkins way to compare files between builds?

[Victor Martinez]

Hi,

 If I recall correctly, you can use: 
https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin
There are a bunch of different triggers:
- 
https://github.com/jenkinsci/email-ext-plugin/tree/master/src/main/java/hudson/plugins/emailext/plugins/trigger
And you can send email to different people: 
https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin#Email-extplugin-Triggers

Cheers

On Monday, 7 November 2016 19:58:50 UTC, Rob Gulley wrote:
>
> Each build runs test cases which compiles the state to a single text file 
> (e.g. test1=Fail, test2=Pass)
>
>
> What I want to do is diff THIS build's text file to the MOST recent (i.e. 
> BUILD_NUM-1) build's text file. If any tests went from Pass->Fail, then the 
> developer who triggered the change gets a nagging email.
>
>
> I believe the dirty approach would be to write a script (Python, Groovy, 
> whatever) that is aware of the filesystem underneath Jenkins to find the 
> location of the previous build's file. That seems hacky to me, but maybe 
> it's not. I've been browsing the plugin repository and lurking some forums 
> but I haven't found a satisfying answer to this.
>
>
> What are your thoughts?
>

-- 
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/f159ca3e-6d9d-4cf0-90ca-fb57e9781e8b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Writing integration tests for Global Libraries

[Michael Kobit]

Using the support for @Library seems like a much simpler way to go about 
testing it, and was thought about as the option. We were hoping to have 
turnaround time locally as well as having more codified tests. We have seen 
the Groovy CPS plugin bite us in the ass a few times, so we wanted to get 
some testing infrastructure in place and were hoping we could it as close 
to the writer as possible.

It will definitely be easier to set up a few simple jobs or something for 
us to run tests against the global libraries.

Thanks for the response.

On Monday, November 7, 2016 at 12:45:25 PM UTC-6, Michael Lasevich wrote:
>
> There is no reason why you cannot automate the local running of the 
> Jenkins tests. See how plugin development works - they have setup to start 
> a local Jenkins instance with plugin installed, and it should be relatively 
> simple to automate that to run test jobs and check for output. 
>
> That said, you are WAY overthinking this. A much simpler solution is to 
> store your library in a proper SCM and use the @Library's version support 
> to allow a job to specify the branch of the repo. Create a pre-production 
> branch and set up a validation job to trigger on commit of code to preprod 
> to test the pre-production version of the library. Validation job can 
> execute various tests against the pre-prod branch (which, if you desire, 
> can include executing of other jobs) and if everything passes, either 
> auto-merge the commit tested to production, or signal you that it is safe 
> to merge that commit. No additional infrastructure is required, use the 
> same Jenkins server you are already using with this library.
>
> The tricky part would be figuring out how to write proper validation tests.
>
> -M
>
>
>
>
> On Sunday, November 6, 2016 at 5:30:16 PM UTC-8, Michael Kobit wrote:
>>
>> I'm working on writing some global libraries using 
>> https://github.com/jenkinsci/workflow-cps-global-lib-plugin. My current 
>> process for iterating locally is:
>>
>>- Start up a local Jenkins instance
>>- Point the *globalLibs* directory to my global libraries repository
>>- Create a few jobs that use my global libraries
>>- Write some code
>>- Run jobs
>>- Check for results in logs
>>
>> This is inefficient and error prone.
>>
>> The workflow doesn't seem much better when using the recent @Library 
>> 
>>  
>> support.
>>
>> My question is, what do I need to do to get some of the Jenkins 
>> infrastructure in place to write automated, integration tests for Jenkins 
>> pipelines jobs and Global libraries code?
>>
>> I am using Gradle, and was hoping to see if anybody else has been 
>> successful in setting up testing locally so I can validate that I my 
>> libraries work in an actual Jenkins pipeline execution with all of the 
>> Groovy CPS transformations and other nuances of writing Groovy libraries 
>> for Jenkins pipelines.
>>
>> My current *build.gradle* looks something like this, but I still haven't 
>> gotten it working:
>>
>> plugins {
>>   id 'build-dashboard'
>>   id 'groovy'
>> }
>> description = 'Libraries written for use with Jenkins Global Pipeline 
>> Libraries'
>>
>> repositories {
>>   jcenter()
>>   maven {
>> url 'http://repo.jenkins-ci.org/public'
>>   }
>>   mavenLocal()
>> }
>>
>> sourceSets {
>>   main {
>> groovy {
>>   // Jenkins Global Workflow Libraries requires sources to be at 'src'
>>   srcDirs = ['src']
>> }
>> java {
>>   srcDirs = []
>> }
>> resources {
>>   srcDirs = []
>> }
>>   }
>>   test {
>> groovy {
>>   // configure the test source set so that it is not part of the Global 
>> Pipeline Libraries
>>   srcDirs = ['unitTest']
>> }
>> java {
>>   srcDirs = []
>> }
>> resources {
>>   srcDirs = []
>> }
>>   }
>>   jenkinsIntegrationTest {
>> groovy {
>>   srcDirs = ['jenkinsIntegrationTest']
>> }
>> java {
>>   srcDirs = []
>> }
>> resources {
>>   srcDirs = []
>> }
>> compileClasspath += sourceSets.main.runtimeClasspath
>> runtimeClasspath += sourceSets.main.runtimeClasspath
>>   }
>> }
>>
>> configurations {
>>   jenkinsIntegrationTestCompile.extendsFrom testCompile
>>   jenkinsIntegrationTestRuntime.extendsFrom testRuntime
>> }
>>
>> tasks.create('jenkinsIntegrationTest', Test) {
>>   group = LifecycleBasePlugin.VERIFICATION_GROUP
>>   description = 'Runs tests against of actual Jenkins Pipelines'
>>   testClassesDir = sourceSets.jenkinsIntegrationTest.output.classesDir
>>   classpath = sourceSets.jenkinsIntegrationTest.runtimeClasspath
>> }
>>
>> dependencies {
>>   compile 'org.codehaus.groovy:groovy-all:2.4.7'
>>
>>   testCompile 'org.spockframework:spock-core:1.0-groovy-2.4'
>>   testCompile 'junit:junit:4.12'
>>
>>   jenkinsIntegrationTestCompile 'org.jenkins-ci.main:jenkins-core:2.17'
>>   jenkinsIntegrationTestCompile 
>> 

Pipeline shared libraries, can I have a constructor when I don't explicitly declare the enclosing class?

[Jonathan Hodgson]

Hi,

I'm setting up a folder library as per here.

Now in one of their examples they talk about not declaring the enclosing 
class (so as to allow access to steps)

This works fine, in the file MyClass.groovy

@package my.package



def myMethod(data)
{
// do stuff with data
}


return this


I can declare an instance of the class and use it with 

method = new my.package.MyClass()


myClass.myMethod(my_data)


But I cannot create a contructor, is there a way to do this?

-- 
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/3c86d57e-4186-43df-8288-e5f4c552c17e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Any way to run code in Pipeline Global Library from Scriptler?

[Michael Lasevich]

The Functionality in Scriptler and Global Libraries can and does often 
intersect. I would like to avoid repeating same code in multiple places and 
I was wondering if there is any way to call one from another?

The specific use-case I am looking at is using active parameters in a job 
that execute some code to generate a selection/value, but allowing 
pipelines to run same code directly.

Ideally i would want to call Pipeline GL code from Scriptler, but vice 
versa would do in a pinch - I would really hate to write same code in both 
locations.

Thanks, 

-M

-- 
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/082e86ed-8af7-4248-b37f-9994913ebef9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Versioning the entrie system configuration -- not artifacts

[Michael Lasevich]

Ahh, "Job DSL",  I remember that. It was a good thing when it was the only 
game in town, but (in my opinion) Pipelines pretty much made it obsolete. 
Of course it is a matter of opinion, but if you are finding Jobs DSL too 
complicated, Pipelines may be just right for you - it removes a lot of the 
complexity, and makes your entire build process far simpler - you no longer 
need a rabbit-warren of jobs, and with MultiBranch Pipelines + Global Libs 
+ something like Slack notifications, your devs may not even need to login 
to Jenkins server - just commit code and see notification that the job was 
created(if needed) and build was complete :-) Join the modern age :-)

-M

On Monday, November 7, 2016 at 11:55:20 AM UTC-8, Victor Martinez wrote:
>
> Give a try job-dsl-plugin 
> - https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin
>
> Supports 1000+ jenkins plugins, local testing, gradle integration, same 
> Jenkins job paradigm, DRY concept and a bunch of other benefits besides of 
> converting jobs in code and therefore scm oriented.
>
> Cheers
>
>

-- 
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/5200fb48-2be3-4f51-a26f-08681272a80c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins is hanging

[Rachel Moreno]

Hi Mirko,

In my personal opinion, I'd open a new issue with more detail (all data in 
this thread).

Best regards, 
Rachel

On Monday, November 7, 2016 at 8:40:15 AM UTC+1, SGD53 wrote:
>
> Hi Rachel,
>
> I've attached my "observations" to this 
> ticket, but 
> unfortunately no reactions :(
>
> Is ist better to open a new ticket?
>
> Regards
> Mirko
>

-- 
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/f1909ceb-fecb-4a8b-910f-cc6bb6a1eb2a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Most Jenkins way to compare files between builds?

[Rob Gulley]

Each build runs test cases which compiles the state to a single text file 
(e.g. test1=Fail, test2=Pass)


What I want to do is diff THIS build's text file to the MOST recent (i.e. 
BUILD_NUM-1) build's text file. If any tests went from Pass->Fail, then the 
developer who triggered the change gets a nagging email.


I believe the dirty approach would be to write a script (Python, Groovy, 
whatever) that is aware of the filesystem underneath Jenkins to find the 
location of the previous build's file. That seems hacky to me, but maybe 
it's not. I've been browsing the plugin repository and lurking some forums 
but I haven't found a satisfying answer to this.


What are your thoughts?

-- 
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/291e5a5e-97be-4fae-9b65-dd590bb8c12b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Versioning the entrie system configuration -- not artifacts

[Victor Martinez]

Give a try job-dsl-plugin 
- https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin

Supports 1000+ jenkins plugins, local testing, gradle integration, same Jenkins 
job paradigm, DRY concept and a bunch of other benefits besides of converting 
jobs in code and therefore scm oriented.

Cheers



-- 
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/1106951a-b4c3-4288-a5d6-2ec8bccd6bc3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Versioning the entrie system configuration -- not artifacts

[Michael Lasevich]

Not familiar with "Jobs SCM" and unclear as to what you are trying to do - 
or how Redis or Docker fits it here. If you have some idea, you are welcome 
to write a plugin and make it work however you want, which is why the 
plugin system exists - and answers your question as to why this is done 
with plugin. But onestly, it sounds like you are making it far more 
complicated than it needs to be. Generally the setup would be a single, 
static Jenkins Master server that manages job scheduling and coordination 
and a number of "slave" nodes" that execute the job. Ideally slave nodes 
would be pristine and disposable and not have any code/tools installed on 
them - with master managing any code/tools requires - meaning they do not 
ever need to be versioned on the slave. 

Modern way of managing your jobs is via Pipelines. You just store your jobs 
along with your code (I assume your code is in some sort of a SCM to begin 
with) and for shared libraries use global library repo(s).  Jenkins does 
not really have a lot of configuration on Jenkins Master side after this, 
the only thing you really need here is a decent backup strategy - but if 
you are really interested in tracking individual job changes, there is a 
"Job Configuration History" plugin that will track each change and who did 
it, but with most of the job coming with source code, it is not all that 
critical/necessary.

HTH,

-M

On Monday, November 7, 2016 at 4:45:57 AM UTC-8, Rinaldo DiGiorgio wrote:
>
> Hi,
>
>   I tried to version my jobs with the Jobs SCM plugin for example and it 
> often gets confused and ends up making my system unusable. Perhaps an 
> entire rewrite is needed and the backend store needs to move to something 
> like redis. I  don't think version control should be done with optional 
> plugins. It should be part of the core system and all configuration data 
> should be in a network store.  
>
>   I can see a solution using docker where one makes a base image.  What 
> happens when you change the configuration however. Do you make a new docker 
> base image?  Some organizations want all the source code to generate an 
> image in some type of SCM and this is the issue.  If you change job 
> configurations or config params you just incurred the hit of a new image 
> generation cycle.  Perhaps I am not looking it in the right way or in the 
> future when everything is pipeline the configuration is pipeline with 
> supporting json and property files.
>
> Rinald
>
>
>

-- 
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/9547956d-bf32-4827-ab38-bbaf41b971f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Writing integration tests for Global Libraries

[Michael Lasevich]

There is no reason why you cannot automate the local running of the Jenkins 
tests. See how plugin development works - they have setup to start a local 
Jenkins instance with plugin installed, and it should be relatively simple 
to automate that to run test jobs and check for output. 

That said, you are WAY overthinking this. A much simpler solution is to 
store your library in a proper SCM and use the @Library's version support 
to allow a job to specify the branch of the repo. Create a pre-production 
branch and set up a validation job to trigger on commit of code to preprod 
to test the pre-production version of the library. Validation job can 
execute various tests against the pre-prod branch (which, if you desire, 
can include executing of other jobs) and if everything passes, either 
auto-merge the commit tested to production, or signal you that it is safe 
to merge that commit. No additional infrastructure is required, use the 
same Jenkins server you are already using with this library.

The tricky part would be figuring out how to write proper validation tests.

-M




On Sunday, November 6, 2016 at 5:30:16 PM UTC-8, Michael Kobit wrote:
>
> I'm working on writing some global libraries using 
> https://github.com/jenkinsci/workflow-cps-global-lib-plugin. My current 
> process for iterating locally is:
>
>- Start up a local Jenkins instance
>- Point the *globalLibs* directory to my global libraries repository
>- Create a few jobs that use my global libraries
>- Write some code
>- Run jobs
>- Check for results in logs
>
> This is inefficient and error prone.
>
> The workflow doesn't seem much better when using the recent @Library 
>  
> support.
>
> My question is, what do I need to do to get some of the Jenkins 
> infrastructure in place to write automated, integration tests for Jenkins 
> pipelines jobs and Global libraries code?
>
> I am using Gradle, and was hoping to see if anybody else has been 
> successful in setting up testing locally so I can validate that I my 
> libraries work in an actual Jenkins pipeline execution with all of the 
> Groovy CPS transformations and other nuances of writing Groovy libraries 
> for Jenkins pipelines.
>
> My current *build.gradle* looks something like this, but I still haven't 
> gotten it working:
>
> plugins {
>   id 'build-dashboard'
>   id 'groovy'
> }
> description = 'Libraries written for use with Jenkins Global Pipeline 
> Libraries'
>
> repositories {
>   jcenter()
>   maven {
> url 'http://repo.jenkins-ci.org/public'
>   }
>   mavenLocal()
> }
>
> sourceSets {
>   main {
> groovy {
>   // Jenkins Global Workflow Libraries requires sources to be at 'src'
>   srcDirs = ['src']
> }
> java {
>   srcDirs = []
> }
> resources {
>   srcDirs = []
> }
>   }
>   test {
> groovy {
>   // configure the test source set so that it is not part of the Global 
> Pipeline Libraries
>   srcDirs = ['unitTest']
> }
> java {
>   srcDirs = []
> }
> resources {
>   srcDirs = []
> }
>   }
>   jenkinsIntegrationTest {
> groovy {
>   srcDirs = ['jenkinsIntegrationTest']
> }
> java {
>   srcDirs = []
> }
> resources {
>   srcDirs = []
> }
> compileClasspath += sourceSets.main.runtimeClasspath
> runtimeClasspath += sourceSets.main.runtimeClasspath
>   }
> }
>
> configurations {
>   jenkinsIntegrationTestCompile.extendsFrom testCompile
>   jenkinsIntegrationTestRuntime.extendsFrom testRuntime
> }
>
> tasks.create('jenkinsIntegrationTest', Test) {
>   group = LifecycleBasePlugin.VERIFICATION_GROUP
>   description = 'Runs tests against of actual Jenkins Pipelines'
>   testClassesDir = sourceSets.jenkinsIntegrationTest.output.classesDir
>   classpath = sourceSets.jenkinsIntegrationTest.runtimeClasspath
> }
>
> dependencies {
>   compile 'org.codehaus.groovy:groovy-all:2.4.7'
>
>   testCompile 'org.spockframework:spock-core:1.0-groovy-2.4'
>   testCompile 'junit:junit:4.12'
>
>   jenkinsIntegrationTestCompile 'org.jenkins-ci.main:jenkins-core:2.17'
>   jenkinsIntegrationTestCompile 
> 'org.jenkins-ci.main:jenkins-test-harness:2.17'
>   jenkinsIntegrationTestCompile 
> 'org.jenkins-ci.main:jenkins-war:2.17:war-for-test@jar'
>   jenkinsIntegrationTestCompile 'org.jenkins-ci.plugins:git:3.0.0:tests'
>   jenkinsIntegrationTestCompile 
> 'org.jenkins-ci.plugins.workflow:workflow-cps-global-lib:2.4'
>   jenkinsIntegrationTestCompile 
> 'org.jenkins-ci.plugins.workflow:workflow-support:1.15:tests'
>   jenkinsIntegrationTestCompile 
> 'org.jenkins-ci.plugins.workflow:workflow-job:2.6'
> }
>
> // Make sure only the Groovy dependency is available.
> // Other dependencies must be used with @Grab in the defined classes due to 
> how Jenkins Global Libraries work
> project.afterEvaluate {
>   final compile = it.configurations.compile.dependencies
>   if 

Re: Integrating Jenkins with chef

[Lavanya pujari]

Yes the cookbook pattern is same there. I also done validating syntax it is 
correct one, the nodes also assigned to that cook book only.


On Sunday, November 6, 2016 at 4:04:53 AM UTC-5, Irfan Sayed wrote:
>
> lavanya,
> any update ?
>
> On Sat, Nov 5, 2016 at 12:12 AM, Irfan Sayed  > wrote:
>
>> can you confirm following:
>>
>>1. curl::default is really the "cookbook::recipe" pattern?
>>2. can you click on validate syntax button and check whether the 
>>syntax is correct 
>>3. nodes are really assigned to that cookbooks ?
>>
>> please let me know 
>> Regards,
>>
>>
>> On Fri, Nov 4, 2016 at 12:39 PM, Irfan Sayed > > wrote:
>>
>>> I am looking into it. 
>>> Regards,
>>>
>>>
>>> On Wed, Nov 2, 2016 at 12:36 AM, Lavanya pujari >> > wrote:
>>>


 On Tuesday, November 1, 2016 at 3:04:00 PM UTC-4, Lavanya pujari wrote:
>
> The scenario of Integrating Jenkins with Chef is:  
>
> I have configured jenkins with 3 plugins like Chef Identity plugin, 
> Chef Sinatra Plugin and Chef plugin. 
>
> While configuring with Chef Identity, I provided the identity name, 
> knife.rb and pem file details. From there using sinatra plugin, I am 
> providing the url of the chefserver and tested the connection it is 
> showing 
> as test connection is success. But here I am unable to fetch the nodes. I 
> am attaching the screenshot which I have configured with sinatra plugin.  
>  
> Does anyone have any idea about this, suggest me Is this is correct or not
>
>
>
>
> On Tuesday, October 25, 2016 at 2:55:28 PM UTC-4, Irfan Sayed wrote:
>>
>> if you want to execute the chef-client on the set of nodes which are 
>> fetched based on certain pattern of cookbook and recipe pattern, then 
>> chef 
>> sinatra plugin is the better choice. further, chef client runs in 
>> parallel 
>> on all these nodes so that you can save much time there.
>>
>> please let us know if this is what you are looking for ?
>> else let us know what is your exact requirement 
>>
>> Regards,
>>
>>
>> On Tue, Oct 25, 2016 at 9:01 PM, suresh kumar  
>> wrote:
>>
>>> Hi Lavanya,
>>> Could you explain the full scenario what you are trying to achieve. 
>>> In that case you may get correct guidance rather than fix for your 
>>> problem.
>>> I foresee you are trying to register a node to chef server and then 
>>> execute the respective recipes.
>>>
>>> -Suresh
>>>
>>> On Tuesday, October 25, 2016 at 4:40:01 PM UTC+5:30, Lavanya pujari 
>>> wrote:

 Is there any requirement to add certificate to jenkins for fetching 
 nodes from online chef server. As I am using chef sinatra plugin and 
 chef 
 Identity plugin.

 On Monday, October 24, 2016 at 3:43:36 PM UTC-4, Teichner Peter 
 wrote:
>
> Which plugin are you using?
>
> Get Outlook for Android 
>
>
>
> On Mon, Oct 24, 2016 at 8:39 PM +0100, "Lavanya pujari" <
> pujarila...@gmail.com> wrote:
>
> I am working on integrating jenkins with chef. So Inorder to 
> communicate I need to fetch the nodes from chef server where I am 
> able to 
> establish connection between these two. How can I fetch the nodes?
>
> -- 
> 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/dcf93914-b0fc-4fd1-8ffc-ca926027129b%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-use...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-users/81bb82c6-e9be-4763-b205-1a3fbf2e880b%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> -- 
 You received this message because you are 

jenkins 2.29 | console log output

[Arnaud bourree]

Hello,

Since I upgrade from 2.28 to 2.29, console log only print step name but no
more step output.
I didn't see in change-log any point related to a console log new format.

Did someone else fail on same issue?

Regards,

Arnaud.

-- 
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_CTiqCm7S7wPtG%3D1P-bP6y6hOY%3DgTH2RpGmB9vDaTwuSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use jenkinsfile from "multi-configuration project"

[Jesús Linares]

I think is what I need. I don't know why I can select it in "multi 
configuration project". Anyway, I will try it in a Pipeline project.

Thanks a lot.
Regards.

El lunes, 7 de noviembre de 2016, 13:04:54 (UTC+1), Björn Pedersen escribió:
>
>
>
> Am Montag, 7. November 2016 11:38:41 UTC+1 schrieb Jesús Linares:
>>
>> Hi,
>>
>> I have a repository with a *jenkinsfile *and I need to execute it in 
>> several linux distributions like Debian, Ubuntu and so on. From *Pipeline 
>> *project I can't use several slaves (a slave for each linux 
>> distribution) so I thought the proper project for my goal was 
>> *Multi-configuration* project but it seems that it is impossible to 
>> select a *jenkinsfile *in this kind of project. Is there other way to 
>> execute the jenkinsfile in several linux distributions?.
>>
>> Thanks.
>>
>>
> Hi,
> you can use several slaves from Pipeline quite easy:
>
>  parallel 'host1 {
> node('label1') {  }
>  }, 'host2' {
>node('label2') {  }
> } 
>
> If you need to find more info, see 
> https://github.com/jenkinsci/pipeline-examples/tree/master/pipeline-examples/parallel-multiple-nodes
>
> Björn
>

-- 
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/6da8f590-1c19-4d9d-8f44-31d4008c473a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Global "disable triggers" options

[Michael Giroux]

We have a large jenkins configuration with 1700 jobs.  We have two use 
cases in which the configuration is copied. We make a copy of the 
configuration prior to any upgrade:

1. for purposes of testing new version and plugins prior to an upgrade
2. to have a running instance of the previous version to allow "emergency 
builds" for projects that will not build in new version after an upgrade.

In both of these use cases, we have two copies of Jenkins running at the 
same time (on different ports of course), the old version, and the new 
version.  In either case, we want to disable the build triggers for one of 
the instances.  We do not want two copies of jenkins building the same 
project based on polling, or due to upstream builds and/or snapshot changes.

We can use "prepare to shutdown" to suspend one instance.  But if we cancel 
shutdown to allow a specific build to be run, the flood gates open.

It would be helpful  if there was an option to allow manual builds even 
when "prepare to shutdown" is in effect.  Or, as the subject line suggests, 
an option to disable triggers. Such an option should have an initial state 
set by a system property allowing us to launch Jenkins with the option 
initially on or off.

Similar requests have been made previously:
http://jenkins-ci.361315.n4.nabble.com/Suspend-Plugin-td1599530.html
http://stackoverflow.com/questions/1299180/can-i-disable-hudsons-automatic-scheduled-builds-all-at-once

I would be interested in hearing how other users handle this case, 
especially case #2 in which we wish to have the old instance of Jenkins 
available to run builds that might not execute in the new version.

Michael


-- 
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/ee104f05-9679-4111-8c5b-33e4a3a6a986%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Versioning the entrie system configuration -- not artifacts

[Rinaldo DiGiorgio]

Hi,

  I tried to version my jobs with the Jobs SCM plugin for example and it 
often gets confused and ends up making my system unusable. Perhaps an 
entire rewrite is needed and the backend store needs to move to something 
like redis. I  don't think version control should be done with optional 
plugins. It should be part of the core system and all configuration data 
should be in a network store.  

  I can see a solution using docker where one makes a base image.  What 
happens when you change the configuration however. Do you make a new docker 
base image?  Some organizations want all the source code to generate an 
image in some type of SCM and this is the issue.  If you change job 
configurations or config params you just incurred the hit of a new image 
generation cycle.  Perhaps I am not looking it in the right way or in the 
future when everything is pipeline the configuration is pipeline with 
supporting json and property files.

Rinald


-- 
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/62746fe4-fc0e-41e8-9060-184632462c7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Testability

[Rinaldo DiGiorgio]

I would like to write some tests for pipeline scripts. Has anyone created a 
mock pipeline implementation. Development of pipeline script unit tests is 
pretty convoluted when you have to run the test in jenkins.  I am looking 
for something that allows me to use replacements for existing pipeline 
steps so there is no source level change between tests and the deployed 
code. I understand how to replace annotations in Groovy. However trying to 
replace something like this at runtime has proven to be a challenge. I want 
to provide my own node closure and my own git method.  Is there some kind 
of interface for all the pipeline support that I can include on my test 
class path? 



node("master") {
git http://internet.com/according-to-bitcoin 
}


I want to write a test that verifies this code so I need to replace node 
and git.  

Has anyone looked tried something similar?

Of course I could create a local instance and run tests in my local test 
instance and that is the answer. 




-- 
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/ea33eae8-6ffa-4224-8afc-fb893e554f48%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pipeline: Support for DependencyGraph

[Sverre Moe]

Dependency Graph is very useful to display any upstream and downstream 
dependencies. However with Pipeline it seems no longer an option.

Is there any plans for *DependencyGraph* pipeline support with 
*WorkflowMultiBranchProject*? Since *DependencyGraph* can only work with 
*AbstractProject*, and the closest inherited class between them is 
*AbstractItem*.

In my Pipeline script I parse the RPM spec files (looking for 
BuildRequirements) of all Jenkins Multibranch Pipeline jobs in order to 
create a list of upstream and downstream dependencies. This in order to 
trigger builds, as the Pipeline equivalent of build triggers (Build other 
projects).

An ugly hack: Keep duplicate FreestyleProject of all Multibranch projects. 
Update the build triggers of a FreestyleProject from a running pipeline 
build.
The FreeStyleProject does not need to do anything actually. It is just 
there to support DependencyGraph.

-- 
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/0f0b5b92-d3c1-431c-b878-9b4982390c37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins 2.28 fails with a stack trace when one clicks Manage Jenkins and then clicks Configure System

[Daniel Beck]

Tracked as JENKINS-39414.

We really need to change the message shown on the exception screen :(

> On 07.11.2016, at 13:22, Rinaldo DiGiorgio  wrote:
> 
> javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: 
> jar:file:/jpgdata/jpg-infra-ci/jenkins/jenkins-home/war/WEB-INF/lib/jenkins-core-2.28.jar!/jenkins/model/Jenkins/configure.jelly:59:84:
>   
> jar:file:/jpgdata/jpg-infra-ci/jenkins/jenkins-home/war/WEB-INF/lib/jenkins-core-2.28.jar!/lib/form/section.jelly:48:21:
>   
> org.kohsuke.stapler.lang.KlassNavigator.getDeclaredFields(Ljava/lang/Object;)Ljava/util/List;
>   at org.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.java:103)
>   at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
>   at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649)
> 
> 
> 
> -- 
> 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/c9498847-7d82-44c0-9288-b2f41c017d01%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/29E795A4-BFF5-4743-8282-1E40D68F29A1%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

GitHub Commits aren't triggering builds

[Naveen Srinivasan]

Hi,
 We are using jenkins pipeline with github organization. The github 
hooks are setup by the plugin and there are notifications coming to the 
repo AFAIK. In the jenkins logs we could see "Received POST for 
https://github.com/Revature/core; but the builds aren't being triggered. 
And our jenkinsfile has this

properties([pipelineTriggers([[$class: 'GitHubPushTrigger']])])

But even with this builds aren't triggered automatically. What are we 
missing? 

Thanks
Naveen

-- 
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/a11105e6-42fb-4ee5-a0ce-34b49210a171%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins 2.28 fails with a stack trace when one clicks Manage Jenkins and then clicks Configure System

[Rinaldo DiGiorgio]

javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: 
jar:file:/jpgdata/jpg-infra-ci/jenkins/jenkins-home/war/WEB-INF/lib/jenkins-core-2.28.jar!/jenkins/model/Jenkins/configure.jelly:59:84:
  
jar:file:/jpgdata/jpg-infra-ci/jenkins/jenkins-home/war/WEB-INF/lib/jenkins-core-2.28.jar!/lib/form/section.jelly:48:21:
  
org.kohsuke.stapler.lang.KlassNavigator.getDeclaredFields(Ljava/lang/Object;)Ljava/util/List;
at org.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.java:103)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649)


-- 
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/c9498847-7d82-44c0-9288-b2f41c017d01%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use jenkinsfile from "multi-configuration project"

['Björn Pedersen' via Jenkins Users]

Am Montag, 7. November 2016 11:38:41 UTC+1 schrieb Jesús Linares:
>
> Hi,
>
> I have a repository with a *jenkinsfile *and I need to execute it in 
> several linux distributions like Debian, Ubuntu and so on. From *Pipeline 
> *project I can't use several slaves (a slave for each linux distribution) 
> so I thought the proper project for my goal was *Multi-configuration* 
> project but it seems that it is impossible to select a *jenkinsfile *in 
> this kind of project. Is there other way to execute the jenkinsfile in 
> several linux distributions?.
>
> Thanks.
>
>
Hi,
you can use several slaves from Pipeline quite easy:

 parallel 'host1 {
node('label1') {  }
 }, 'host2' {
   node('label2') {  }
} 

If you need to find more info, see 
https://github.com/jenkinsci/pipeline-examples/tree/master/pipeline-examples/parallel-multiple-nodes

Björn

-- 
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/085036d6-dd5c-4a1a-9f32-6b369969935f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Iterate FileWrapper, fails with shell script within the loop

[Sverre Moe]

Was aware of it. Iterating for loops using for(def foo : foos) will work 
for List. Using closure forEach does not work in Pipeline without using 
@NonCPS.

>
>- Beware for (Foo f: foos) loops and Groovy closure-style operators 
>like .each and the like. They will not work right in normal Pipeline 
>script contexts where Pipeline steps are involved directly.
>
> I have been using shell script within for (String f: foos) 
for (def file : files) {
  sh "scp $file user@$server:$path"
}
This works fine. No problem at all. However this time I had problem 
iterating through a list of FileWrapper, regardless of existing shell 
script within or just a simple println of it. 

Thus, putting the iteration of FileWrapper within a method annotated with 
@NonCPS should fix that serializable problem.
However I was unaware the sh step could not be executed within a method 
annotated with @NonCPS. If that is mentioned in the documentation I must 
have missed it.

In any case, I have a workaround with first iterating the list of 
FileWrapper and putting it in a new list of Strings.

torsdag 3. november 2016 16.56.41 UTC+1 skrev Björn Pedersen følgende:
>
> See 
> https://github.com/jenkinsci/pipeline-examples/blob/master/docs/BEST_PRACTICES.md#groovy-gotchas
>
>
>
>
> Am Montag, 31. Oktober 2016 12:22:08 UTC+1 schrieb Sverre Moe:
>>
>> Problem looping through the result of findFiles.
>> The result from this method returns a 
>> org.jenkinsci.plugins.pipeline.utility.steps.fs.FileWrapper
>>
>> node {
>> stage("Publish") {
>> def files = findFiles(glob: '**/*.rpm')
>>
>> for (def file : files) {
>> sh "echo Hello World! ${file.path}"
>> }
>> }
>> Fails with java.io.NotSerializableException: java.util.AbstractList$Itr
>>
>> Trying to use @NonCPS
>> node {
>> stage("Publish") {
>> def files = findFiles(glob: '**/*.rpm')
>> loopFiles(files)
>> }
>> }
>>
>> @NonCPS
>> void loopFiles(files) {
>> for (def file : files) { 
>> sh "echo Hello World! ${file.path}"
>> }
>> }
>> It breaks the loop after first item in list. If 3 files found, then there 
>> is only one output.
>> However, if I remove the shell script and just use println it loops 
>> through all 3 files found.
>>
>>
>> Works if I loop the files first and put the file path in a new list:
>> node {
>> stage("Publish") {
>> def files = findFiles(glob: '**/*.rpm')
>> def packages = []
>> for (def file : files) {
>> packages.add(file.path)
>> }
>>
>> for (def packagePath : packages) {
>> sh "echo Hello World! ${packagePath}"
>> }
>> }
>>
>> I reckon that FileWrapper is not serializable, hence the problem, but why 
>> doesn't the @NonCPS work on all items?
>>
>

-- 
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/4d556850-5a4f-4d64-b632-458119f4b604%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to make the Jenkins build output as downloadable from Jenkins server machine itself?

[Ben Patterson]

I realize this is not as pretty as was what you were looking for, but you 
can always tee your build scripts to a log file, and archive that.

(I thought I'd answer in case there's not an easier way; but if there is, 
hopefully someone can suggest something more Jenkins-y.  --cheers)

On Monday, November 7, 2016 at 1:34:13 AM UTC-5, Vadivel Natarajan wrote:
>
> Hi All,
>
> I found the artifacts download information from the below link for 
> Appveyor.
>
> https://www.appveyor.com/docs/packaging-artifacts/
>
> Is there anything similar this for jenkins?
>
> Please share your suggestions about this..
>
> Thanks in advance.
>
> On Mon, Nov 7, 2016 at 1:25 AM, Vadivel Natarajan  > wrote:
>
>> I am new to Jenkins. i have configured the Jenkins "Free Style" project 
>> and executing a power shell a script to get an executable application(Exe) 
>> as output. i have searched for some of the plugins to make the Jenkins 
>> output (exe) as downloadable from the Jenkins server machine itself as an 
>> artifact link(download link). But i found the Jenkins plugins to copy the 
>> archive files, upload to ftp and some other plugins.
>>
>> So, Could anyone please suggest me is there any option or plugin 
>> available to make the each Jenkins build output file as downloadable from 
>> the Jenkins server machine by keeping it in a server machine some other 
>> place?
>>
>
>

-- 
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/06317e9f-9827-400e-9527-0aeb8d362ee0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use jenkinsfile from "multi-configuration project"

[Jesús Linares]

Hi,

I have a repository with a *jenkinsfile *and I need to execute it in 
several linux distributions like Debian, Ubuntu and so on. From *Pipeline 
*project 
I can't use several slaves (a slave for each linux distribution) so I 
thought the proper project for my goal was *Multi-configuration* project 
but it seems that it is impossible to select a *jenkinsfile *in this kind 
of project. Is there other way to execute the jenkinsfile in several linux 
distributions?.

Thanks.


El domingo, 6 de noviembre de 2016, 8:24:09 (UTC+1), Baptiste Mathus 
escribió:
>
> IIUC your question, no.
>
> Cheers
>
> Le 4 nov. 2016 8:38 PM, "Jesús Linares"  > a écrit :
>
>> Hi,
>>
>> is it possible to select a jenkinfile in a multi-configuration project?.
>>
>> 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/a2d24b19-cb87-4175-8d7c-a8bd8eef0a69%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/6a6e0f2d-0953-4231-b42c-77325ac6d564%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Pipeline] No error when invoking "git" step w/o installing Git plugin

[Logan MAUZAIZE]

I don't if it's a general problem when invoking non-existing function but 
doing a fresh install from Jenkins 2.19.1 and Pipeline 
 2.4 (
Pipeline: SCM Step 
 2.2), 
but not Git Plugin .


When invoking this Pipeline script:
stage('Checkout') {
  git credentialsId: 'GIT_SSH_KEY', url: 
'ssh://g...@stash.xxx.com/project/repository.git'
}
There's absolutely no output and no error.


Installing Git plugin 3.0.0 makes the Pipeline script works like a charm 
but I was expecting error if "step command" isn't available. Is it a bug or 
I'm missing something ?

-- 
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/1bc7d29a-5cd5-4ad2-962d-0d35d2d559f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Permission denied error

[Subramanyeswari Ravinutala]

Hi,
 
Our jenkins master is ubuntu and the slaves are windows.  With 775 
permission on the ClearCase VOB, the builds are failing with permission 
denied for write operations in the jenkins slave.
 
with 777 (everyone all), the builds are working fine on jenkins slaves.
 
We have given clearcase environment variables in the slaves and the jenkins 
service is configured with the maser build account who has all access to 
clearcase. 
 
I have also set up build runs thorugh the masterbuild account as an 
alternative.  But whatever it may be, our jenkins clearcase buildes are 
failing with permission denied with 775 permission.
 
WE ahve checked the group and owner.  The both are at permissable level. I 
have also given all privileges to the master build account to the jenkins 
installation directory on the windows.  The windows slaves are some Windows 
2003 and some are Windows7.  But whatever may be the Operating system, the 
builds are failing.
 
Can any one helps me here ?
 
Regards,
 
 

-- 
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/2adc93ed-cf1c-4913-a21d-9f900af61a86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Summary of changes build information

[Mike Bayliss]

If you look at the page for the email-ext plugin
 there are
links to groovy scripts that will find the change history for a job.

Mike

On Sat, Nov 5, 2016 at 12:21 AM,  wrote:

> If I view build information I see a "summary of changes", in my case the
> Perforce changelists and some detail. I would like to include that in the
> notification email. I am aware of P4_CHANGELIST variable, but that seems to
> only show the last changelist number or at least only the change list
> number and I would like more of the details.
>
> Any suggestions?
>
> Thanx
> Tim
>
> --
> 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/b3f40f48-aabf-4ba1-a3c3-c7a1bddcc7ba%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/CAC-P8ut9QOFsfdArKtx7%3DPN4EWeg-Y-2yVzszyuUGQVcwGC9FQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.