Standard schema for Config.xml

[infybb123]

Hi,

Is there any standard XSD Schema for the config.xml that is used to create 
jobs in Jenkins using the REST API?

Thanks,
Shreya

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Every build has all commits listed in the Changes page

[Mark Waite]

On Wed, Aug 20, 2014 at 7:13 PM, Wood Peter  wrote:

> Jenkins-1.567; Git-Plugin-2.2.5; Gerrit-Trigger-2.11.1
>
> I setup Jenkins-Git-Gerrit and everything works as expected.
>
> The issue I'm having is that every build shows list of changes starting
> from the initial commit all the way to the last commit that actually
> triggered the build. Seems like it doesn't update the local repository and
> it start from scratch every time a build is triggered.
>
>
Did you inadvertently add the "Additional Behaviour" to "Calculate
changelog against a specific branch"?  That might cause the list of changes
to appear for each build, even if no changes arrived.



> My Workspace files are up to date but my Pull Log for the builds is empty.
>
>
I don't recognize the term "pull log".  Is that somehow related to the
Gerrit trigger?


> Also if I manually run a build (i.e. not triggered by an event) it does a
> pull of the very first commit only and then continues with the tests.
>

I assume that is also something provided by the Gerrit trigger, so I don't
recognize the concept of pulling a commit into the git plugin.

Can you duplicate the problem without the Gerrit trigger?

Mark Waite


> I know I missed some settings somewhere.
>
> Any help is appreciated.
>
> Thanks,
>
> -- Peter
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Thanks!
Mark Waite

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Every build has all commits listed in the Changes page

[Wood Peter]

Jenkins-1.567; Git-Plugin-2.2.5; Gerrit-Trigger-2.11.1

I setup Jenkins-Git-Gerrit and everything works as expected.

The issue I'm having is that every build shows list of changes starting
from the initial commit all the way to the last commit that actually
triggered the build. Seems like it doesn't update the local repository and
it start from scratch every time a build is triggered.

My Workspace files are up to date but my Pull Log for the builds is empty.

Also if I manually run a build (i.e. not triggered by an event) it does a
pull of the very first commit only and then continues with the tests.

I know I missed some settings somewhere.

Any help is appreciated.

Thanks,

-- Peter

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Github webhook pushes causing all branches to build

[Mark Waite]

You could use the add "Additional Behaviour" for "Advanced clone option" to
a define a reference repository.  A reference repository will provide the
same data transfer reduction, without the complexity of defining two
repositories.

Mark Waite


On Wed, Aug 20, 2014 at 4:04 PM, Nicholas Paufler <
nicholas.pauf...@goclio.com> wrote:

> I believe I have figured out what the problem is. Still trying to find a
> reasonable workaround.
>
> I had two git repositories defined - one of which was a local cache of the
> full git repo that got cloned when the slave starts up (referenced as a
> file:// repo) and then the actual github repo. It looks like it's somehow
> tied up in that, in that it can't determine the revision (possibly because
> it may have built a revision newer than what is in the file:// repo) so it
> gives up and decides to build it anyway.
>
> Rationale for the locally cached repo is to to cut down on data transfer.
> Due to the number of branches being tested (120+) and the size of the
> workspace (1GB) we delete the workspace after the job completes. To save
> having to pull the full repo from Github every time a job runs we wanted to
> have at least a semi-recent local cache that would mean we'd only need to
> transfer the deltas.
>
> I'm now trying to figure out an alternative that will give the same result.
>
> Thanks for the help!
>
> Nicholas
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Thanks!
Mark Waite

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Github webhook pushes causing all branches to build

[Nicholas Paufler]

I believe I have figured out what the problem is. Still trying to find a 
reasonable workaround.

I had two git repositories defined - one of which was a local cache of the 
full git repo that got cloned when the slave starts up (referenced as a 
file:// repo) and then the actual github repo. It looks like it's somehow 
tied up in that, in that it can't determine the revision (possibly because 
it may have built a revision newer than what is in the file:// repo) so it 
gives up and decides to build it anyway.

Rationale for the locally cached repo is to to cut down on data transfer. 
Due to the number of branches being tested (120+) and the size of the 
workspace (1GB) we delete the workspace after the job completes. To save 
having to pull the full repo from Github every time a job runs we wanted to 
have at least a semi-recent local cache that would mean we'd only need to 
transfer the deltas.

I'm now trying to figure out an alternative that will give the same result.

Thanks for the help!

Nicholas

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Maven build release ${project.basedir}:unknown

[Leandro Andrade]

Hi guys, help me, please.

When I start a Perform Maven Release 

 
erro below appears:

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-release-plugin:2.2.2:prepare (default-cli) on 
project JavaWeb: Cannot prepare the release because you have local 
modifications :[ERROR] [${project.basedir}:unknown][ERROR] -> [Help 1]


My tags directory in SVN is empty.
Pom.xml:


org.apache.maven.plugins
maven-release-plugin
2.2.2


https://server01.com/svn/JavaWeb/tags/

${project.artifactId}-${maven.build.timestamp}
clean install
package
-DskipTests=false


javasvn




${project.build.directory}






com.google.code.maven-scm-provider-svnjava
maven-scm-provider-svnjava
2.0.4




What's means that error? Is a problem in my repository?

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-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Help Running Jenkins (1.535+) on Solaris 10

[valentinoshah]

Did you find answer to your question? I am facing the exact same issue

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins 1.535+ on Solaris 10

[Bhagyesh Shah]

On Aug 20, 2014 11:14 AM, Bhagyesh Shah  wrote:
>
> Hi,
>
> We use Jenkins on Solaris 10 SPARC 64 bit server. The current Jenkins version 
> we are on is 1.532.3 which is a stable version
>
> Recently we tried to upgrade Jenkins to 1.535 but after starting Jenkins like 
> we usually do. The login page did not load. On investigating with different 
> release this is what I found
>
> 1. 1.535 works on a Linux server and does not work on Solaris 10
> 2. With same commands I was able to install/access 1.534 on Solaris and Linux
> 3. I tried latest releases like 1.575 on both Linux and Solaris, again it 
> worked on Linux but did not work on Solaris
> 4. Java version that we have on Solaris is 1.6.0_65
>
> If anyone knows this issue or needs more info I can provide it. I could not 
> find the answer on any forums so hoping to get some answers here
>
> 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-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Github webhook pushes causing all branches to build

[Mark Waite]

On Wed, Aug 20, 2014 at 10:04 AM, Nicholas Paufler <
nicholas.pauf...@goclio.com> wrote:

> Yes,
>
> I see the same behavior with 2.2.4. I've done some more testing this
> morning to confirm with both 2.2.4 and 2.2.5 and I see the same incorrect
> behavior with both.
>
> Is my fundamental impression of how this is supposed to work correct,
> though?
>

I don't know the design or usage of the github webhook, so I can't comment
if that is how it is intended to work.


> When a github webook push event comes in, the Jenkins github webhook
> implementation should be looking at the "ref" in the json push and trying
> to match that to any jobs with a corresponding branch name? If, and only
> if, it finds a match, it's supposed to queue that job to build? Any there
> shouldn't be any reason that an unrelated branch should ever be queued?
>
>
I'm accustomed to the git repository level hooks which I use from my local
bare git repository.  With those hooks, when a commit is pushed to the
local bare git repository, the hook invokes curl to pass the repository URL
to Jenkins.  Jenkins then causes any job to poll which has polling enabled
and uses that repository and is not configured to ignore.  Each of the
matching jobs poll for changes.  Each job which detects changes as a result
of that poll will start.

In the case you describe, if there were no changes on a branch, then I
would expect a poll to happen, but no build would run, since no changes
would be detected.

We'll need someone who is familiar with the github webhook to answer your
question about github webhook behavior.  It appears from your description
that the github webhook has a capability to somehow limit the matching of
which jobs should poll to only those jobs which are matching a specific
branch.  That's different (as far as I know) than the typical behavior I've
used with hooks configured inside local bare repositories.


> With both 2.2.4 and 2.2.5 I see it considering and then poking every
> branch. Even when a webhook push for a branch that doesn't have a locally
> defined job happens, it's poking and queuing every job associated with that
> repo.
>
> I'll get a bug report in if necessary, I just want to make sure that it is
> actually a bug and not my understanding of how it's supposed to work that's
> the problem.
>
> Thanks
>
> Nicholas
>
> On Tuesday, August 19, 2014 8:06:19 PM UTC-6, Mark Waite wrote:
>
>> Do you see the same behavior with git plugin 2.2.4?  A change was made in
>> git plugin 2.2.5 to fix JENKINS-22009.  There is now a bug report which
>> suggests that change has unintended side effects (see JENKINS-24322).  I
>> haven't yet had time to investigate if the fix for JENKINS-22009 introduced
>> the unintended side effect reported in JENKINS-24322, or if it was
>> something else.  I probably won't have time to investigate it until this
>> weekend (at the earliest).
>>
>> You could help with that investigation by comparing the behavior of git
>> plugin 2.2.4 and git plugin 2.2.5 in your use case.  If the behavior is
>> significantly different, submit a bug report which describes those
>> differences, along with enough details so that I can duplicate the bug, and
>> that will increase the odds of the bug being fixed.  It may also provide
>> you a short term work around (if 2.2.4 behaves more the way you want).
>>
>> Thanks,
>> Mark Waite
>>
>>
>> On Tue, Aug 19, 2014 at 4:03 PM, Nicholas Paufler > > wrote:
>>
>>> We're using Jenkins 1.575 with the GIT client (1.10.1), GIT (2.2.5), and
>>> GitHub (1.24) plugins (amongst others) but the issue seems to be related to
>>> those in some fashion.
>>>
>>> Specifically, we're using the Jenkins Build Per Branch script (
>>> http://entagen.github.io/jenkins-build-per-branch/) to create Jenkins
>>> jobs for every branch in our github repo. That much works great - jobs are
>>> created and deleted as branches get added or removed. Each job has the
>>> specific branchname specified within.
>>>
>>> We then have a Github webook setup pointing at our Jenkins install to
>>> notify on pushes. That part is also working - but seemingly too well. Every
>>> time we get changes to one branch pushed into github, the webhook seems to
>>> be causing Jenkins to queue a build for every job.
>>>
>>> The Jenkins log shows events like the following for every local job.
>>>
>>> Aug 19, 2014 9:48:22 PM FINE com.cloudbees.jenkins.GitHubWebHook
>>>
>>> Considering to poke 
>>>
>>> Aug 19, 2014 9:48:22 PM INFO com.cloudbees.jenkins.GitHubWebHook 
>>> processGitHubPayload
>>>
>>> Poked 
>>>
>>> We see that for everything, even for branches that haven't seen a commit in 
>>> months.
>>>
>>>
>>> We do have a single Jenkins master and a number of slaves (using swarm
>>> slave). All jobs are configured to clean their workspace after they are
>>> done executing.
>>>
>>> Am I misunderstanding how this is supposed to be working, or is there
>>> likely something I have configured incorrectly?
>>>
>>> Any help would be appreciate

Re: Jenkins silently skipping MultiJob phase.

[mfisher]

I have just stumbled onto this same issue, with the following setup:

MultiPhase Job A
   Phase 1
   Job1
   Job2
   Job3
   Job4

   Phase 2
   Deploy

MultiPhase Job A runs on master (4 executors), Job1-4 run on
label-restricted slaves.

Repro:
   I kick off 4 concurrent builds of Job A.  The master node has 4 executors
so all multi-phase instances of job A are kicked off (no queued instances of
A).  As 4 instances of multi-phase job A were kicked off, there are now 4
instances of each Job1-4 that need to be built, for this explanation I'll
focus on Job1.

There are only 2 slaves (each with 1 executor) that can build Job1, however
there are 4 instances of Job1 that need to be built.  The first two
instances of Job1 are sent to the available 2 slaves.  The third instance of
Job1 is queued, waiting for one of the two slaves to be available.  THE BUG:
The 4th instance of Job1 does not get queued, it simply gets skipped (gray
circle next to it) with the text "(not built").  Further, "Phase 2" gets
executed on this instance of JobA, which fails because Job1 was never built
and hence the artifact to be deployed simply doesn't exist.


This appears to be an issue using the MultiPhase job plugin + "Allow
Concurrent Builds" + "restrict where this job can be run", and is a blocking
issue for myself and my team.  Any insight into a fix for this would be
greatly appreciated.

Thanks!



--
View this message in context: 
http://jenkins-ci.361315.n4.nabble.com/Jenkins-silently-skipping-MultiJob-phase-tp4696480p4715982.html
Sent from the Jenkins users mailing list archive at Nabble.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.
For more options, visit https://groups.google.com/d/optout.

Re: Getting metadata of another sub-project in Multijob project

[Adam Mercer]

On Tue, Aug 19, 2014 at 8:18 AM, Ginga, Dick  wrote:

> The Parameterized Trigger plugin lets you trigger one job from another and 
> pass to that job a set of parameters. You can use the $BUILD_NUMBER and 
> $JOB_NAME as parameters.

Thanks, that seems to be useful.

> There is also the Build Flow plugin that provide a DSL for scripting job 
> execution. It exposes some underlying Jenkins objects that you can fetch all 
> kinds of information from and pass onto other jobs, again, as parameters.

Thanks, that also looks interesting...

Cheers

Adam

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Mandatory covert pre-build or post-build - possible?

[G Dameron]

Is it possible to configure a pre-build (or post-build) script that runs by 
default before (after) any job, even newly-created ones? The idea is to do 
some checks that ensure all users' projects are adhering to local best 
practices.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[literate] feedback/questions

[Baptiste Mathus]

Hi all,

I've recently been playing with the Literate plugin. As the plugin is still
young, I thought I'd drop some random lines here about my
findings/thoughts. Maybe this can yield some debate about views/future of
the plugin.

##
# Works as advertised
Might sound obvious, but I actually managed to install it and tinker with
it quite quickly on our internal jenkins preprod server. That's not always
the case :-). Congrats to the developers for that (Stephen & Vincent, we're
looking at you :-)).

# Labels/text used in the README.md : tying to some server
In the .md you have to put things like:
* `rhel` and `maven-3.1.0`
- `jdk-1.7.0_64bits`
- `jdk-1.8.0_64bits`

IMO, this somehow ties the sources to an actual server and its labels.

What is your feeling about it? Is it maybe planned to add some form of
label mapping between what's in a project descriptor and the actual labels
in a jenkins instance?

##
# Common values
Having to manage an averagely large Jenkins install (~400 jobs), I often
find myself doing the same things many times, using variables and so on.

Namely, in the case of literate-plugin, I'd see some form of :

# Build

$standardMvnBuild

useful to share between builds (or even through inheritance, mixing in like
Job DSL offers, etc.).
Though I agree it may also defeat some principles of the plugins or worsen
the coupling between sources and the actual server.

##
# Integration with workflow-plugin / coordinating multiple jobs
I've not yet seen how to trigger other builds. I'm not even sure I see
clearly how this would be done in a literate-style without again falling
onto the above issue about tying things.
You'd have for example to define a name of job to trigger, and stick to it.
In Jenkins, the naming updates somehow automatically.
With only text, this would quickly become out-of-date.

##

OK, let's call it a first shot.

Hope I was clear enough. If not just tell me. I hope this will help us
discuss about this very interesting work.

Thanks again.

Cheers

-- 
Baptiste

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Github webhook pushes causing all branches to build

[Nicholas Paufler]

Yes,

I see the same behavior with 2.2.4. I've done some more testing this 
morning to confirm with both 2.2.4 and 2.2.5 and I see the same incorrect 
behavior with both.

Is my fundamental impression of how this is supposed to work correct, 
though? 

When a github webook push event comes in, the Jenkins github webhook 
implementation should be looking at the "ref" in the json push and trying 
to match that to any jobs with a corresponding branch name? If, and only 
if, it finds a match, it's supposed to queue that job to build? Any there 
shouldn't be any reason that an unrelated branch should ever be queued?

With both 2.2.4 and 2.2.5 I see it considering and then poking every 
branch. Even when a webhook push for a branch that doesn't have a locally 
defined job happens, it's poking and queuing every job associated with that 
repo.

I'll get a bug report in if necessary, I just want to make sure that it is 
actually a bug and not my understanding of how it's supposed to work that's 
the problem.

Thanks

Nicholas
On Tuesday, August 19, 2014 8:06:19 PM UTC-6, Mark Waite wrote:
>
> Do you see the same behavior with git plugin 2.2.4?  A change was made in 
> git plugin 2.2.5 to fix JENKINS-22009.  There is now a bug report which 
> suggests that change has unintended side effects (see JENKINS-24322).  I 
> haven't yet had time to investigate if the fix for JENKINS-22009 introduced 
> the unintended side effect reported in JENKINS-24322, or if it was 
> something else.  I probably won't have time to investigate it until this 
> weekend (at the earliest).
>
> You could help with that investigation by comparing the behavior of git 
> plugin 2.2.4 and git plugin 2.2.5 in your use case.  If the behavior is 
> significantly different, submit a bug report which describes those 
> differences, along with enough details so that I can duplicate the bug, and 
> that will increase the odds of the bug being fixed.  It may also provide 
> you a short term work around (if 2.2.4 behaves more the way you want).
>
> Thanks,
> Mark Waite
>
>
> On Tue, Aug 19, 2014 at 4:03 PM, Nicholas Paufler  > wrote:
>
>> We're using Jenkins 1.575 with the GIT client (1.10.1), GIT (2.2.5), and 
>> GitHub (1.24) plugins (amongst others) but the issue seems to be related to 
>> those in some fashion.
>>
>> Specifically, we're using the Jenkins Build Per Branch script (
>> http://entagen.github.io/jenkins-build-per-branch/) to create Jenkins 
>> jobs for every branch in our github repo. That much works great - jobs are 
>> created and deleted as branches get added or removed. Each job has the 
>> specific branchname specified within.
>>
>> We then have a Github webook setup pointing at our Jenkins install to 
>> notify on pushes. That part is also working - but seemingly too well. Every 
>> time we get changes to one branch pushed into github, the webhook seems to 
>> be causing Jenkins to queue a build for every job.
>>
>> The Jenkins log shows events like the following for every local job.
>>
>> Aug 19, 2014 9:48:22 PM FINE com.cloudbees.jenkins.GitHubWebHook
>>
>> Considering to poke 
>>
>> Aug 19, 2014 9:48:22 PM INFO com.cloudbees.jenkins.GitHubWebHook 
>> processGitHubPayload
>>
>> Poked 
>>
>> We see that for everything, even for branches that haven't seen a commit in 
>> months. 
>>
>>
>> We do have a single Jenkins master and a number of slaves (using swarm 
>> slave). All jobs are configured to clean their workspace after they are 
>> done executing.
>>
>> Am I misunderstanding how this is supposed to be working, or is there 
>> likely something I have configured incorrectly?
>>
>> Any help would be appreciated - thanks!
>>
>> Nicholas
>>
>> -- 
>> 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 .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Thanks!
> Mark Waite
>  

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Large scale Jenkins installation : Help!

[Frederic Meyrou]

Dear Rob,

Many tks for your long answer.
As far as I understand the WAN distributed infrastructure is due to several 
factors : JUNIT tests and some war deploy on servers are done next on the 
same LAN as the slaves most of the time.
But then I'm wondering if we can't have several master, one per site as you 
suggest... problem is that some projects are spread over several sites, and 
all consolidates on a central Nexus.
I have to check with R&D team if such architecture make sens to them.

I've now to consider migration scenario for upgrade : migrate everything on 
the same server or create from scratch a new instance with new set of 
plugin and migrate only validated jobs with so much slaves and jobs, I 
have to organize a steering committee with users and find the best 
approach...  

./Fred

Le mardi 19 août 2014 16:21:06 UTC+2, Rob Mandeville a écrit :
>
>  I used to run a system with about as many executors, but all in one 
> server room.
>
>  
>
> First off, is there a good reason to run the slaves on a WAN?  I 
> understand that your users are spread throughout Europe, but why should 
> your builds be?  Users generally only need to talk to the Jenkins server, 
> not every piece of the build farm.  Would it be possible to simply ship all 
> of your racks to one building?
>
>  
>
> If you need a geographically distributed build farm, you should see how 
> much you can localize resources to a single farm.  Of your three SCM 
> systems, Git is distributed, so it’s preferable.  I suspect you don’t get 
> to choose, however.  When using ClearCase, especially with a distributed 
> build farm, make sure to use snapshot views.  You do not want every single 
> file read to be a transcontinental event.
>
>  
>
> Jenkins requires a permanent connection to the slave nodes.  If your WAN 
> is even a little bit flaky, you could lose slaves easily.  Consider putting 
> a separate Jenkins server at each site, and then having a master one for 
> user interface (where the configuration for “build project Foo” is “Tell 
> Jenkins in Frankfurt to build project Foo”).  This will be easier if you 
> can isolate various projects to a single site each.
>
>  
>
> Per the memory leak on the server: do as little as possible on the 
> server’s address space.  See if you can reduce the number of master nodes 
> to zero, so everything is done on the slaves.  If you aren’t already, 
> consider using Java 7 or Java 8, each of which has its own strategy to GC 
> PermGenSpace.
>
>  
>
> Your Jenkins server(s) should be well-connected and have plenty of fast 
> disk.  Logs and artifacts end up being sent to the server in real time.  
> Also, all of the data (except for the logs and artifacts) from the build 
> runs it is aware of goes into memory on the server.  To reduce this, set 
> jobs to erase old builds—do something like keep the last 100 runs, or the 
> last 30 days of runs.
>
>  
>
> If you’ve got a farm this big, you may want to go pro.  While Cloudbees’ 
> bread and butter is serving you build farms on the cloud, they also sell 
> CloudBees Enterprise.  This is a support contract plus some extra plugins 
> not available for general release.  Said plugins are designed for 
> controlling large deployments like yours.  My previous employer used it, 
> and liked it.  It is a bit expensive, and the license fee is per server and 
> per executor.  What we didn’t try is a new product called Jenkins Ops 
> Center.  This appears to be able to tie multiple Jenkins servers together.  
> They are worth investigating.
>
>  
>
> Finally, if you’re considering upgrades, you don’t want the Latest and 
> Greatest.  Get the LTS (Long Term Support) release; currently, that’s 
> 1.565.1.
>
>  
>
> Hope this helps!
>
>  
>
> --Rob
>
>  
>  
> *From:* jenkins...@googlegroups.com  [mailto:
> jenkins...@googlegroups.com ] *On Behalf Of *Frederic Meyrou
> *Sent:* Tuesday, August 19, 2014 8:09 AM
> *To:* jenkins...@googlegroups.com 
> *Subject:* Large scale Jenkins installation : Help!
>  
>  
>  
> Dear mates,
>  
>  
>  
> I'm recently in charge of quite big Jenkins configuration based on a 
> central master (no build on master) with :
>  
>  
>  
> >7000 Jobs
>  
> 136 active Slaves mostly tied build
>  
> 150-200 Total Slaves
>  
> ~450 potential executors
>  
>  
>  
> Users are on many R&D sites in Europe, slaves are spread over the WAN each 
> site has a Nexus proxy next to the slaves. 
>  
> SCM servers (SVN/ClearCase/Git) are not on the same LAN...
>  
>  
>  
> At the moment the console is quite slow and we had recently memory trouble 
> that end-up adding 4 more Gb of RAM to the server and review the JVM setup
>  
> below. At the moment it looks better, but I can't be sure because most 
> builds are schedule at night... I installed the monitoring plugin. 
>  
> The strange thing is that Jenkins is using more memory on the Windows 
> server then just the total of XMX + MaxPermSize (7+1 Gb), and ends-up using 
> more
>  
> then 10 Gb...

Re: Large scale Jenkins installation : Help!

[Frederic Meyrou]

Hi Nigelm,

Tks for your answer.
Yes I have mainly Maven builds.
Fingerprints are necessary, but your contrib is interesting.

./Fred


Le mardi 19 août 2014 19:05:03 UTC+2, nigelm a écrit :
>
> > Nexus proxy next to the slaves. 
>
> Do you have a lot of maven project builds?
>
> Stop Jenkins
> cd ~/.jenkins/fingerprints
> rm -rf *
> Start Jenkins
>
> Our install is like 1/100th the size of yours, and that alone saved 450Mb 
> of memory.
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Builds fail randomly without reason given

[David tha Dude]

Hello,

We use DSL in a Build Flow project to trigger around 50 parallel builds on 
2 slave nodes. However, some of the triggered jobs fail for no apparent 
reason. The only message in the Jenkins log file is:

Aug 20, 2014 12:38:41 AM hudson.model.Run execute
INFO:  #9288 main build action completed: FAILURE

The log message inside the failed triggered builds indicates that execution 
failed at the first action which is some simple shell command. The nodes 
are not under high load.

The build will be successful when re-launched manually. I have posted about 
a similar issue before 
.

Has anyone experienced similar issues? What can be done to fix/work around 
the problem. I would also appreciate hints as to what we can do to make 
error logging more verbose. The lack of information makes the issue nearly 
impossible to debug.

Thank you,

/David

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins upgrade 1.576 issue

[Daniel Beck]

Known issue:
https://issues.jenkins-ci.org/browse/JENKINS-24316

On 20.08.2014, at 06:15, Rajesh Patwardhan  wrote:

> Hello,
> 
> We just upgraded to 1.576 on Centos (CentOS release 5.8 (Final))
> 
> Some of the plugin images are gone missing from the site. The images 
> themselves are on the disk
> 
> 110934464 -rw-r--r--   1 jenkins  jenkins  1572 Aug 11 21:31 
> plugins/credentials/images/24x24/credentials.png
> 
> -rw-r--r-- 1 jenkins jenkins 3981 Nov 18  2013 
> plugins/claim/icons/claim-48x48.png
> 
> I kind of see the issue but don't know how to fix it (or even if I am looking 
> in the right direction)
> 
> 
> here is the url \ images show correct i.e. that works :
>  style="width: 24px; height: 24px; margin: 2px;" alt="" 
> src="/static/e3ea21a2/plugin/credentials/images/48x48/credentials.png" />
> 
> Here is the url \ image shows broken i.e. that does not work: 
> 
>  src="//plugin/claim/icons/claim-24x24.png" />  href="/claims">Claim Report
> 
> 
> Any help in the right direction will be greatly appreciated.
> 
> Regards,
> Rajesh
> 
> 
> -- 
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.