Re: What is a permanent agent or slave server when discussing Jenkins?

[Kiran]

The CM tools have terms for servers that receive changes.  I don't see why 
a CI tool would not have one.  Apparently the Jenkins community is mature 
and has gotten this far with no term.  To me, a term would really make 
things easier.

On Thursday, August 18, 2016 at 6:52:23 PM UTC-4, Kiran wrote:
>
> In the context of Jenkins, is a slave server one that receives a build?  
> Or is it an auxiliary server that offloads some of the computing demand for 
> resources of a distributed build?
>
> With Jenkins 2.x, the term is "permanent agent."  I want to know precisely 
> what to call a server that receives a Jenkins build/deployment.  If a file 
> receives code or a file from Jenkins, what is the server called?  Is it a 
> managed node?  Is there no term for it?
>

-- 
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/1dbd9e8f-caff-4eb4-a8ba-c9bb81ba96a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Automated Jenkins Plugin/Dependency Management

[Jason Kulatunga]

Yep, the command is `jar xvf jenkins.war`, that will explode the war into 
the current directory. 

On Friday, August 26, 2016 at 12:27:00 PM UTC-7, Michael Kobit wrote:
>
> Is there a way to basically "unzip" the *jenkins.war* so that the 
> plugins, workflow-libs, and other parts can be configured before actually 
> running the service?
>
> On Wednesday, August 17, 2016 at 9:36:08 AM UTC-5, Jason Kulatunga wrote:
>>
>> Hey,
>> Thanks for all the help guys.
>> I slept on this idea for a few days because, to be honest I really didn't 
>> want to write my own package manager 
>> 
>>  and 
>> re-invent the wheel. I took a step back and looked at how Jenkins solved 
>> this problem for Plugin developers, and I think that we could just 
>> piggy-back on top of what they use 
>> .
>>
>> Basically what I've done is specify the plugins I want to install in a 
>> build.gradle file on my Jenkins server. The build.gradle file lets me 
>> specify exactly what versions of the plugins I want for some, and get the 
>> latest for the rest. My install task then goes and copies just the runtime 
>> hpi files to the $JENKINS_HOME/plugins folder (after clearing out whatever 
>> is in there). After restarting my Jenkins server, all plugins are 
>> installed, with the correct versions.
>>
>> I've included a plugin management section in my blog post: You Don't 
>> Know Jenkins - Part 1 
>> 
>>  which 
>> goes into more detail on how it all works, and includes an example 
>> build.gradle file. 
>>
>> Things to note:
>> - The plugin.lock file isn't perfect, its just a STDOUT redirect of 
>> `gradle dependencies` which is great for visually checking which versions 
>> are installed, but committing it to git gets you nothing, subsequent 
>> installs wont be locked to the same transient dependencies. I think I can 
>> solve this by using 
>> https://github.com/nebula-plugins/gradle-dependency-lock-plugin
>> - Since the build.gradle file uses repo.jenkins-ci.org instead of 
>> updates.jenkins-ci.org it does pick up the occassional beta/alpha 
>> version that gets pushed to the releases repo by developers. I'm working to 
>> fix this using a filter in the gradle dependency solver configuration. 
>>
>>
>>
>> On Thursday, August 11, 2016 at 6:03:12 PM UTC-7, Michael Kobit wrote:
>>>
>>> We are looking at doing something similar (actually talking about this 
>>> with colleagues today). The idea is to basically build an immutable Jenkins 
>>> instance that can't be modified. Or at least severely limit any kinds of 
>>> modifications to it so that we have an easily deployable "Jenkins as a 
>>> service".
>>>
>>> I've looked at possibly doing an "unpack and install" execution with the 
>>> *jenkins.war 
>>> *, but it doesn't look like an easy route. The other pain-point I see 
>>> is effectively treating the correct files as "data" that should be 
>>> persisted over time, rather than at "Jenkins build time". I am considering 
>>> trying out the Docker-type approach. I think for plugin resolution, we are 
>>> probably going to have to go the route that you are talking about for doing 
>>> the resolution ourselves.
>>>
>>> For security type issues, I think we could still handle it with the 
>>> Docker approach. Build whatever restrictions into the next "immutable" 
>>> image and making that deployable. Then, we can have a "staging" area and 
>>> easily rollback if we effectively control all the things we need to 
>>> control. We are experimenting with pipelines right now, and are waiting to 
>>> see how https://issues.jenkins-ci.org/browse/JENKINS-33507 will work 
>>> for us to get as much of the job configuration out of Jenkins as possible.
>>>
>>> We are still in the brainstorming phase, so I'm interested to see who 
>>> else has ran into this and what they have done.
>>>
>>> On Thursday, August 11, 2016 at 5:47:45 PM UTC-5, Jason Kulatunga wrote:

 Hey,
 Thanks for all the feedback :)

 @Daniel Beck:
 Yup, I'm familiar with the limitations of the 
 https://updates.jenkins-ci.org/current/update-center.json file. Thats 
 why I'm thinking of creating a plugin/dependency resolution system that 
 will have to directly download the specific version of a plugin file from 
 update site folder structure 
 https://updates.jenkins-ci.org/download/plugins/*/ or use 
 https://updates.jenkins-ci.org/latest/ 
 if no version restriction is found.

 I wasn't aware that pinning was pointless in 2.x so that'll be an 
 interesting problem to deal with. It seems that I'll have to restrict all 
 access to the UpdateCenter for idea #1, or do a hybrid approach with a 
 UpdateCenter subclass as well.

 @Baptiste Mathus 
 Unfortunately just using an image with locked pl

Loaded Classes Count grows over time: crashes Jenkins with Perm Gen

[grayaii]

We went from Jenkins 1.651.1 to 2.7.2 and our Jenkins master kept on 
crashing with:
java.lang.OutOfMemoryError: PermGen space

Where were not specifying -XX:MaxPermSize in our JENKINS_JAVA_OPTIONS 
before, so I added it, and kept on increasing the value after every crash.
We are now at 512m:

JENKINS_JAVA_OPTIONS="-Djava.awt.headless=true -Xms3584m -Xmx3584m 
-XX:MaxPermSize=512m 
-Dhudson.model.ParametersAction.keepUndefinedParameters=true"

Using the Jenkins Monitoring plugin, we see that the Loaded Classes Count 
keeps growing without stopping:


How do you debug this? 
Something must be loading classes continuously.


Any ideas how we can debug 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/025b4d0c-ce5a-4163-8447-6be523629cab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Copy artifact Plugin

[Martin d'Anjou]

Maybe another plugin can help with your problem. It is the external 
workspace manager plugin 
.
 
If the master and the slave can mount the same disk, then they can share 
the workspace. You could use that to perform the file copy, or to simply 
use the artifacts without copying them.

Hope this helps.
Martin

On Thursday, August 25, 2016 at 10:39:00 AM UTC-4, Capfo wrote:
>
> Hello,
>
> I have a Jenkins 1.642.2 with linux slave
>
> Two jobs for the same project the first A for the build and seconde B to 
> deploy the artifact the two jobs build in the slave
>
> the jenkins home in the master : /var/lib/jenkins
> in the slave : /lun/data1/jenkins_slave
>
> when i start the job B it copie all archived artifactd from Job A but also 
> i have this error :
>
> Copied 5 artifacts from "MOSAIC_INT_FR_MAVEN-slave" build number 1
>
> /var/lib/jenkins/jobs/Project/modules/com.project.boas$applet-exchange/builds/1/archive
>
> so how can i do to force the copy artifact plugin to look at the slave 
> home(/lun/data1/jenkins_slave) instead  the master home ( /var/lib/jenkins)
>
> thank you
>
>
> -- 
>
> *Cordilally*
>
> *Cordialement.*
>
>
>

-- 
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/76006e39-0c13-40c5-a5a9-dc0451b9ca80%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.