I have two issues. 1. I'd like to be able to set up concurrentBuild to true
in my job configuration. My aim as a result is to have job with checked
option Execute concurrent builds if necessary. 2. Also I would like to
have a unchecked option Restrict where this project can be run.
In my
Hi Phil,
Your load rule is incorrect. Indeed it should be relative to the view path,
so start with the job name
Le 20 mai 2014 20:40, Phil Lord lordph...@gmail.com a écrit :
Vincent,
Setting the view path per your suggestion improved things! Now the
lshistory command displays the changes
I meant vob name (stupid phone)
Le 21 mai 2014 10:46, Vincent Latombe vincent.lato...@gmail.com a écrit
:
Hi Phil,
Your load rule is incorrect. Indeed it should be relative to the view
path, so start with the job name
Le 20 mai 2014 20:40, Phil Lord lordph...@gmail.com a écrit :
Vincent,
Hey,
If the user has not entered values to its variables, how jenkins can
provides default values if someone has an idea please don't hesitate to help
me.
Best regards,
HAJAR
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To
Vincent,
You the man! It's working! I championed Jenkins and was getting a lot of
unwanted viability due to it not working, but now they'll focus on the next
fire.
Thanks again Vincent!
Ciao!
Phil
On Wednesday, May 21, 2014 4:47:29 AM UTC-4, Vincent Latombe wrote:
I meant vob name (stupid
We are experiencing a 4-5minute delay on a linux slave at the end of a job.
We though it was sending mail but with or without the email step doesn't
make a difference.
It is not the 'Archiving artifacts' step because it usually takes 15-20s
There is not step after the sending mail.
The log
I am now realizing the issue is with my load rule..I do not have global
configurations set, because the view path constantly changes. Something
I'm trying to get the devs to straighten out...but..I need some help with
the load rules.
Please help.
On Tuesday, April 22, 2014 9:19:07 AM UTC-4,
This is not a bug (and actually might be lead to unexpected behavior on a lot
of instances). Set your environment variables elsewhere, e.g. within Jenkins in
the global and node configuration pages.
On 21.05.2014, at 15:49, Sapientlife bpmi...@gmail.com wrote:
Hi,
Jenkins daemon is not
Hi Daniel,
The problem I having though with this behavior is that when a build is
started from the Jenkins GUI the shell that the build runs in does not get
access to our SCM AccuRev no matter where we edit the environment variables
.bashrc/.bash_profile, /etc/profile, /etc/sysconfig/jenkins
We recently had an old Hudson-Jenkins install (running on Windows Server
2k8 R2) go bad (Jenkins service refusing to start - copying back war file
did not resolve as it used to when this would happen) and were unable to
resolve the issue.
This installation pre-dates anyone currently on this
Hello
Keeps happening to me on Jenkins ver. 1.564
Em sexta-feira, 16 de maio de 2014 09h49min17s UTC-3, Rawad hajou escreveu:
reply
2014-05-16 11:59 GMT+02:00 rwdolb [via Jenkins CI] [hidden
email]http://user/SendEmail.jtp?type=nodenode=4701312i=0
:
Hello Chris,
I have the same
I was setting up a new Jenkins instance this morning, and decided to go the
route of running it on 8080/8443, and using iptables to forward 80-8080
and 443-8443. I found this page on the wiki:
https://wiki.jenkins-ci.org/display/JENKINS/Running+Jenkins+on+Port+80+or+443+using+iptables
However,
On 21.05.2014, at 17:52, Sapientlife bpmi...@gmail.com wrote:
no matter where we edit the environment variables
To explain what I meant by the following:
within Jenkins in the global and node configuration pages
Try to set them here if building on the master node:
http://jenkins/configure
Ah, thanks - that's what I was missing.
--Ryan
On Monday, 19 May 2014 12:14:34 UTC-4, slide wrote:
If you click on the list of triggers to add, there should be a Script
Trigger, add that and then define the groovy in the configuration for that
trigger.
Thanks,
slide
On Mon, May 19,
Also, for the sake of adding more information - it looks like the original
installation was done manually - there was a .hudson folder and Hudson
folder in root of C: and a folder for ANT at C:\apache-ant-1.8.4 - before
the 'clean' install I backed up all those then removed then - so now the
OK, I fixed it by doing the following ...
1) Clean install of latest Jenkins to same location as old install (in my
case C:\Hudson)
2) Shut down Jenkins service, deleted all files in C:Hudson (post install)
3) Restored all Hudson-Jenkins files/folders from my backup
(C:\.Hudson, C:\Hudson,
Hi team,
I am new to Jenkins and configured one job to trigger one automation perl
script.
Jenkins is configured and running from unix user named as Jenkins and this
perl script is present in another user. Using ssh plugin to initiate it and
getting below error:
SSH: EXEC:
I run Jenkins 1.554.1 on Windows server. I found if I stopped one job
manually, the spawned process is not killed. And when I re-run the job, some
files are locked by the spawned process.
But I found this document, Jenkins should already have the feature to kill
spawned process, is there any
Did the perl script work on its own.. I mean without Jenkins?
Thanks,
Subbu
On Thu, May 22, 2014 at 5:19 AM, Vivek Jauhari vivekjauh...@gmail.comwrote:
Hi team,
I am new to Jenkins and configured one job to trigger one automation perl
script.
Jenkins is configured and running from
Thanks I have found the solution:
release/=$JOB_NAME/build-$BUILD_NUMBER
--
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
20 matches
Mail list logo
