Hi,
AFAIK, the main goal of using Tomcat is to re-use an existing one.
For example, on my CI server I have both Jenkins, Sonar and Artifactory
running ;
it can be considered "cleaner" to have only one application server running
all these software instead of one per software.
That doesn't change a
ld, this can be cracked.
> a
> Regards
> Faisal
>
>
> On Mon, Jan 14, 2013 at 1:10 PM, Josselin Pierre wrote:
>
>> Hi,
>>
>> On the theorical base, the dependencies should be the other way round.
>> The continuous integration principle is that dependencies s
Hi,
On the theorical base, the dependencies should be the other way round.
The continuous integration principle is that dependencies should trigger
the build of the projects that uses these dependencies, not the other way
round...
But of course, there are always some cases that don't match such a
In case you'd be running into the same issue as me...
I currently have the same kind of issue for a few months now :
it happens for jobs who uses a file upload parameter.
There is a workaround for this bug though :
Remove the
.* tag from the jobs' build.xml
and replace it by
I do it with sed in
> background that prevents correct termination without System.exit ()
>
> ** **
>
> I cannot ignore result termination of my job ?
>
> ** **
>
> *De :* jenkinsci-users@googlegroups.com [mailto:
> jenkinsci-users@googlegroups.com] *De la part de* Josselin Pier
Hi
A System.exit() is a pretty brutal wait to terminate a JVM.
It's more or less equivalent to pulling the plug...
Since the JVM didn't shut down nicely, Jenkins considers it as an error.
You usually don't need to specify a System.exit on your code ; the java
process will end itself at the end o
In this case, you can configure the Product jobs to trigger the Library
jobs, using "Trigger/call on other projects" build step.
And in the Library jobs, uses the path ignore plugin :
https://wiki.jenkins-ci.org/display/JENKINS/Pathignore+Plugin
By using the
"Do not build if only specified paths h
Hi,
Usually, it's done the other way round.
One possible configuration is : one Jenkins jobs for each library, one
Jenkins jobs for each product.
Then, for each library :
- Poll SCM to check if changes happened
- Build the library
- Trigger the builds of the product that relie on this library.
Fo
If you don't want to touch to the jobs themselves, there is another quick
and dirty workaround :
- install a simple mail server somewhere (James, for example)
- configure it to intercept all the mails, storing them somewhere or
deleting them on the fly
- configure Jenkins to use that mail server.
ay/JENKINS/Multijob+Plugin
>
>
> ...
> Mgimza
>
>
> On Wed, Nov 7, 2012 at 11:57 AM, Josselin Pierre wrote:
>
>> Hi,
>>
>> You could give a try to the Join plugin, especially since you have a
>> parent job :
>> https://wiki.jenkins-ci.org/display/JEN
Hi,
You could give a try to the Join plugin, especially since you have a parent
job :
https://wiki.jenkins-ci.org/display/JENKINS/Join+Plugin
On Wednesday, November 7, 2012 5:50:19 PM UTC+1, JohnA wrote:
>
> I've searched google for this but nothing popped out.
>
> I have 122 jobs that run auto
t;>
>>
>> The variables to add/modify:
>> # Unix user account that runs the Jenkins daemon
>> # Be careful when you change this, as you need to update
>> # permissions of $JENKINS_HOME and /var/log/jenkins.
>> #
>> JENKINS_USER=""
>> J
Hi,
Here's my 2 cents, for what it's worth :
Are you sure the forking itself fails ?
One issue that often appears with spawning process from Jenkins is that the
child process might be killed once the job is finished.
You might find quite a few references on this issue on google
https://wiki.jen
Hi,
Another point to check is user rights : does jenkins' user have access to
this folder ?
cheers,
Josselin
2012/11/6 Marek Gimza
> Rakesh,
>
> Does this directory acutally exist?
>
> /Users/rpatel/Documents/MobSources/XX_iOS
>
> Can use cd to this dir manually?
>
> Kind Regards,
> Mgimza
>
14 matches
Mail list logo