Re: Job Generator Plugin jobs get stuck when deleting generated jobs

2013-01-04 Thread syl20bnr
Can you give me more details on your hierarchy so I can try to reproduce 
this bug ?
Thank you.

Le jeudi 3 janvier 2013 23:02:15 UTC-5, JonathanRRogers a écrit :
>
> Whenever I run a job generator job to delete an existing hierarchy of 
> generated jobs, the generator jobs themselves get stuck. They never 
> complete and if I attempt to kill them manually, the entire Jenkins web 
> interface gets stuck and I can never load another page. The only way to get 
> rid of the stuck jobs I've found so far is to restart Jenkins. Generating 
> new jobs doesn't seem to have the same problem, even if replacing existing 
> ones.
>


Changing dashboard column header names

2013-01-04 Thread Jeff
Is changing the column names possible?  I just added the Configure Job
Column Plugin that gives me a direct link to the job configuration.

However the column name is called "Configure" which is about 8 characters
wider than the icon:

[image: Inline image 1]


which is a wasted space.

I have the same issue with the "Console" column that has a little icon for
the console output:

[image: Inline image 2]


Is there a way to change these names?

-- 
Jeff Vincent
predato...@gmail.com
See my LinkedIn profile at:
http://www.linkedin.com/in/rjeffreyvincent
I ♥ DropBox  !!
<><>

Re: Run junkins jobs as different user

2013-01-04 Thread Les Mikesell
On Fri, Jan 4, 2013 at 3:35 PM, Adam Tong  wrote:
> We are using Linux.
>
> So maybe there is a way to that on Linux? But this supposes Jenkins
> offers that possibility.

If you use ssh to start the slave, you should be able to log in as any
user - as long as you have the password or set up keys.  I think you
should even be able to run multiple instances on the same host as
different users if you wanted.

-- 
   Les Mikesell
  lesmikes...@gmail.com


Re: Deleting Bogus Users

2013-01-04 Thread axelabs
A delete option became available to me for the 'bogus' users after I've did
'add description' after clicking on the user in question.



--
View this message in context: 
http://jenkins.361315.n4.nabble.com/Deleting-Bogus-Users-tp3745626p4650456.html
Sent from the Jenkins users mailing list archive at Nabble.com.


Re: Two quick questions about slave nodes.

2013-01-04 Thread Andrew Bayless
Ah, Thank you very much for the input. 

Andrew

On Friday, January 4, 2013 11:18:56 AM UTC-8, LesMikesell wrote:
>
> On Fri, Jan 4, 2013 at 1:02 PM, Andrew Bayless 
> > 
> wrote: 
> > My original purposes were to use a build server to build computer 
> > appliances. While removing the JAR file is not absolutely necessary for 
> the 
> > functionality of the appliances as their presence it not a hindrance on 
> that 
> > functionality, it would be preferable to have no files that are 
> unnecessary 
> > for that functionality. 
>
> The master will be unhappy and the job run marked broken if a slave 
> breaks its own connection during a job.  Maybe you can set up a 
> cleanup script to run as the computer is booted into its new role that 
> would remove the jenkins user and its home/working directory.   Or ssh 
> the commands to do that after everything else is finished and the 
> slave connection stopped. 
>
> -- 
>Les Mikesell 
>   lesmi...@gmail.com  
>


Master + slave + job JVM memory tuning...

2013-01-04 Thread Jeff
I'm trying to optimize how much memory I allocate to the master application
(aka - tomcat), slave processes, maven tasks, etc. and going crazy.

I've been unsuccessful in finding a guideline to determine how much memory
I ought to allocate or if I should just let the defaults work.

All machines are single processor, dual core with 4 GB ram.

I've typically set tomcat to use 2048MB + 512MB permgen space and set my
maven process to use 384MB max.  Is this reasonable?

My slaves are set to run 4 executors.  Jobs use either svn or git to check
out code and Maven to build with a SONAR post-build analysis.  We also do
Maven releases at times.

How much does the core slave process need?  Is there a "rule-of-thumb"
based on the number of executors?

Any perspective/considerations/resources/links/pointers are much
appreciated.

-- 
Jeff Vincent
predato...@gmail.com
See my LinkedIn profile at:
http://www.linkedin.com/in/rjeffreyvincent
I ♥ DropBox  !!


Re: Run junkins jobs as different user

2013-01-04 Thread Adam Tong
We are using Linux.

So maybe there is a way to that on Linux? But this supposes Jenkins
offers that possibility.


On Fri, Jan 4, 2013 at 4:30 PM, Jason Swager  wrote:
> The company I work for had a similar issue.  Our solution was to run slaves
> that were logged in as the user to be tested.  We had to use the JNLP slave
> starting method for this work properly; the SSH and Windows Services methods
> always logged in as an admin.  Then we targeted the job at the particular
> slave that was running as a particular user.
>
> I don't know of any way to run as multiple users on the Jenkins master
> itself - but that was fine for us.
> Jason Swager
>
>
> On Friday, January 4, 2013 1:14:29 PM UTC-8, Adam Tong wrote:
>>
>> Hi,
>>
>> If it is complicated to make it personalized (each job has a
>> possibility to get run under a different user), Running the hole
>> service and all jobs as a specific user different than the default
>> "jenkins" user would help me to solve the issue that I have now.
>>
>> Thank you
>>
>> On Fri, Jan 4, 2013 at 4:11 PM, Slide  wrote:
>> > Do you want to run the whole service under a different user or just
>> > specific
>> > jobs?
>> >
>> > slide
>> >
>> >
>> > On Fri, Jan 4, 2013 at 2:10 PM, Adam Tong  wrote:
>> >>
>> >> Hi,
>> >>
>> >> Is there a way to run jenkins as a different user?
>> >>
>> >> If yes please tell me how.
>> >>
>> >> Thank you
>> >
>> >
>> >
>> >
>> > --
>> > Website: http://earl-of-code.com


RE: Run junkins jobs as different user

2013-01-04 Thread Neerenberg, Aaron
I tend to use the “start slave as service” option under windows, and just gave 
it the credentials to use on the slave nodes in the slave configuration.  
Running the jnlp start as specific users worked well for us for a while, but 
the jnlp startup mode didn’t always reconnect as well as the service start.

Regards,
Aaron

From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of Jason Swager
Sent: Friday, January 04, 2013 1:31 PM
To: jenkinsci-users@googlegroups.com
Subject: Re: Run junkins jobs as different user

The company I work for had a similar issue.  Our solution was to run slaves 
that were logged in as the user to be tested.  We had to use the JNLP slave 
starting method for this work properly; the SSH and Windows Services methods 
always logged in as an admin.  Then we targeted the job at the particular slave 
that was running as a particular user.

I don't know of any way to run as multiple users on the Jenkins master itself - 
but that was fine for us.
Jason Swager

On Friday, January 4, 2013 1:14:29 PM UTC-8, Adam Tong wrote:
Hi,

If it is complicated to make it personalized (each job has a
possibility to get run under a different user), Running the hole
service and all jobs as a specific user different than the default
"jenkins" user would help me to solve the issue that I have now.

Thank you

On Fri, Jan 4, 2013 at 4:11 PM, Slide > wrote:
> Do you want to run the whole service under a different user or just specific
> jobs?
>
> slide
>
>
> On Fri, Jan 4, 2013 at 2:10 PM, Adam Tong > 
> wrote:
>>
>> Hi,
>>
>> Is there a way to run jenkins as a different user?
>>
>> If yes please tell me how.
>>
>> Thank you
>
>
>
>
> --
> Website: http://earl-of-code.com


Re: Run junkins jobs as different user

2013-01-04 Thread Jason Swager
The company I work for had a similar issue.  Our solution was to run slaves 
that were logged in as the user to be tested.  We had to use the JNLP slave 
starting method for this work properly; the SSH and Windows Services 
methods always logged in as an admin.  Then we targeted the job at the 
particular slave that was running as a particular user.

I don't know of any way to run as multiple users on the Jenkins master 
itself - but that was fine for us.
Jason Swager

On Friday, January 4, 2013 1:14:29 PM UTC-8, Adam Tong wrote:
>
> Hi, 
>
> If it is complicated to make it personalized (each job has a 
> possibility to get run under a different user), Running the hole 
> service and all jobs as a specific user different than the default 
> "jenkins" user would help me to solve the issue that I have now. 
>
> Thank you 
>
> On Fri, Jan 4, 2013 at 4:11 PM, Slide > 
> wrote: 
> > Do you want to run the whole service under a different user or just 
> specific 
> > jobs? 
> > 
> > slide 
> > 
> > 
> > On Fri, Jan 4, 2013 at 2:10 PM, Adam Tong > 
> wrote: 
> >> 
> >> Hi, 
> >> 
> >> Is there a way to run jenkins as a different user? 
> >> 
> >> If yes please tell me how. 
> >> 
> >> Thank you 
> > 
> > 
> > 
> > 
> > -- 
> > Website: http://earl-of-code.com 
>


Re: Run junkins jobs as different user

2013-01-04 Thread Adam Tong
Hi,

If it is complicated to make it personalized (each job has a
possibility to get run under a different user), Running the hole
service and all jobs as a specific user different than the default
"jenkins" user would help me to solve the issue that I have now.

Thank you

On Fri, Jan 4, 2013 at 4:11 PM, Slide  wrote:
> Do you want to run the whole service under a different user or just specific
> jobs?
>
> slide
>
>
> On Fri, Jan 4, 2013 at 2:10 PM, Adam Tong  wrote:
>>
>> Hi,
>>
>> Is there a way to run jenkins as a different user?
>>
>> If yes please tell me how.
>>
>> Thank you
>
>
>
>
> --
> Website: http://earl-of-code.com


Re: Run junkins jobs as different user

2013-01-04 Thread Slide
Do you want to run the whole service under a different user or just
specific jobs?

slide


On Fri, Jan 4, 2013 at 2:10 PM, Adam Tong  wrote:

> Hi,
>
> Is there a way to run jenkins as a different user?
>
> If yes please tell me how.
>
> Thank you
>



-- 
Website: http://earl-of-code.com


Run junkins jobs as different user

2013-01-04 Thread Adam Tong
Hi,

Is there a way to run jenkins as a different user?

If yes please tell me how.

Thank you


publish-over-ssh plugin not transferring files

2013-01-04 Thread iamgenius
Hi,

I am trying to use publish-over-ssh plugin along with Jenkins on Windows 
2008 R2 server. Jenkins plug-in is installed and seems to be configured 
correctly. I can see in the verbose output (pasted below) that Jenkins is 
able to connect to the remote unix server and is able to run a command but 
is not able to transfer any files. It always says 0 files transferred.

Output:

SSH: Connecting from host [ABCDEF]
SSH: Connecting with configuration [AIX DEV] ...
SSH: Creating session: username [aaa], hostname [10.10.10.10], port [22]
SSH: Connecting session ...
SSH: Connected
SSH: Opening SFTP channel ...
SSH: SFTP channel open
SSH: Connecting SFTP channel ...
SSH: Connected
SSH: cd [/home/aaa]
SSH: OK
SSH: Disconnecting configuration [AIX DEV] ...
SSH: Transferred 0 file(s)
Build step 'Send files or execute commands over SSH' changed build result 
to SUCCESS
SSH: Connecting from host [ABCDEF]
SSH: Connecting with configuration [AIX DEV] ...
SSH: Creating session: username [aaa], hostname [10.10.10.10], port [22]
SSH: Connecting session ...
SSH: Connected
SSH: Opening SFTP channel ...
SSH: SFTP channel open
SSH: Connecting SFTP channel ...
SSH: Connected
SSH: cd [/home/aaa]
SSH: OK
SSH: Opening exec channel ...
SSH: EXEC: channel open
SSH: EXEC: STDOUT/STDERR from command [echo hello
] ...
SSH: EXEC: connected
hello
SSH: EXEC: completed after 203 ms
SSH: Disconnecting configuration [AIX DEV] ...
SSH: Transferred 0 file(s)
No emails were triggered.

--

Configuration:

Source files:  ${web.dir}/war/WEB-INF/lib/*.jar

--

I have looked at the log, trying to see the actual path for the source 
files but it doesn't seem to help much. Every time the configured source 
file path and actual path comes out to be the same hence doesn't help much 
in pin pointing the erorr:

04-Jan-2013 15:04:56 jenkins.plugins.publish_over.BPTransfer getSourceFiles
FINE: Source files: configured [./ui/ProjectName/build.xml/**], actual 
[./ui/ProjectName/build.xml/**]

04-Jan-2013 15:04:54 jenkins.plugins.publish_over.BPTransfer getSourceFiles
FINE: Source files: configured [./ui/ProjectName/**], actual 
[./ui/ProjectName/**]


--

Can someone please help me identify what is the issue with file transfer?

Thanks,
Prashant


Re: Two quick questions about slave nodes.

2013-01-04 Thread Les Mikesell
On Fri, Jan 4, 2013 at 1:02 PM, Andrew Bayless  wrote:
> My original purposes were to use a build server to build computer
> appliances. While removing the JAR file is not absolutely necessary for the
> functionality of the appliances as their presence it not a hindrance on that
> functionality, it would be preferable to have no files that are unnecessary
> for that functionality.

The master will be unhappy and the job run marked broken if a slave
breaks its own connection during a job.  Maybe you can set up a
cleanup script to run as the computer is booted into its new role that
would remove the jenkins user and its home/working directory.   Or ssh
the commands to do that after everything else is finished and the
slave connection stopped.

-- 
   Les Mikesell
  lesmikes...@gmail.com


Re: Two quick questions about slave nodes.

2013-01-04 Thread Andrew Bayless
My original purposes were to use a build server to build computer 
appliances. While removing the JAR file is not absolutely necessary for the 
functionality of the appliances as their presence it not a hindrance on 
that functionality, it would be preferable to have no files that are 
unnecessary for that functionality. 

Thank You, 
Andrew 

On Friday, January 4, 2013 10:11:19 AM UTC-8, Mandeville, Rob wrote:
>
>  Do you mean installing a slave or launching it?
>
>  
>
> A slave is simply a .jar file.  Copy it where it needs to be, make sure 
> you have a JVM that can run it, and you’ve installed it.
>
>  
>
> I have a number of slaves set up with “launch by running a command on the 
> server”.  Said command just ssh’s to the target host as the right user and 
> runs “java –jar slave.jar”.  At least in Unix (my forte), you can set up a 
> launcher command like “ssh remote_host \”curl {right args to get slave.jar 
> from the Jenkins server} && java –jar slave.jar”.  The actual command, and 
> what it would take on other platforms, is left as an exercise to the reader.
>
>  
>
> As far as uninstalling goes, I don’t think so.  I don’t think there’s a 
> “trigger this job on shutdown” command.  Is there a real need to delete 
> slave.jar from the remote machine after shutting down the slave?
>
>  
>
> --Rob Mandeville
>
> Litle & Co (a member of the Vantiv family)
>


Build hang, apparently related to template jobs plugin and artifacts

2013-01-04 Thread Mandeville, Rob
I have a job which uses the template jobs plugin to use builders and publishers 
from other projects.  I'm also using the timeout plugin to give an absolute 
timeout of 1120 minutes (18 hours 40 minutes).

After 10-12 hours, the actual build completes and writes "Build finished" to 
the console log.  Its next step should be (from the publisher it's getting from 
another project) to archive an artifact, but it doesn't do that.  The artifact 
is there on the slave node end to be archived, but it doesn't show up on the 
server end.

I'm running a recent Red Hat Linux on both client and server, and the Jenkins 
server is 1.480 (circa September).  Here's what I'm finding:

1: The slave node has no subordinate processes it is waiting on.
2: The only files that the slave node has open (looking in /proc) are 
stdin/out/err to the shell script that's launching it and to a number of Jar 
files like slave.jar.
3: The thread dump says that:
3a: The executor thread declares "waiting for Check point 
Hudson.plugins.templateproject.ProxyPublisher on {job name}"
3b: The ping thread for the slave node is just running Thread.sleep, like the 
other ping threads.
3c: the pipe writer thread for the slave node is "parked" like all the others 
(WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer)
3d: The stedrr copier thread and channel reader thread for remote agent on the 
slave node are both RUNNABLE in read_bytes (again like all the rest)
3e: The main thread is waiting from hudson.remoting.Channel.join()
4: If I kill the job (by clicking on the red 'X' icon), it performs the 
archive, finishes up everything else, and reports itself as ABORTED.
5: If I let the job run, it runs for 18 hours and 40 minutes, hanging after the 
build is done.  After 18 hours 40 minutes, it performs the archive, finishes up 
everything else, and reports itself as SUCCESS, noting that it took 18 hours to 
run.

Any ideas on this one, folks?

--Rob Mandeville
Litle & Co. (part of the Vantiv family)




The information in this message is for the intended recipient(s) only and may 
be the proprietary and/or confidential property of Litle & Co., LLC, and thus 
protected from disclosure. If you are not the intended recipient(s), or an 
employee or agent responsible for delivering this message to the intended 
recipient, you are hereby notified that any use, dissemination, distribution or 
copying of this communication is prohibited. If you have received this 
communication in error, please notify Litle & Co. immediately by replying to 
this message and then promptly deleting it and your reply permanently from your 
computer.


Re: Two quick questions about slave nodes.

2013-01-04 Thread Andrew Bayless
Thank you, I believe this answers much of my question. 

I apologize for my poor choice of words. What you are doing here is what I 
meant by installing a slave on a machine remotely.  

After copying over the JAR file automatically, is it possible for the slave 
to delete the JAR file after it has finished executing a job successfully, 
or would the Jenkins Master be responsible for removing the JAR file ? 

Thank You, 
Andrew


Re: Build hangs with Jenkins, runs fine from command line

2013-01-04 Thread Bryan Evenson
slide,

That did it!  I first tried just allowing the service to interact with the
desktop, and I started getting a few messages popping up from Jenkins.  One
of the messages showed that flexlm was trying to do something.  I had no
idea that the compiler I was using was using flexlm for license management,
especially since the compiler is free.  I changed the service settings to
log on using my account and the build now works.

Thanks,
Bryan


On Fri, Jan 4, 2013 at 12:49 PM, Slide  wrote:

> You could take a look at [1] and see if this works for you. I've had
> success with something similar in the past.
>
> slide
>
> 1 -
> http://lostechies.com/keithdahlby/2011/08/13/allowing-a-windows-service-to-interact-with-desktop-without-localsystem/
>
>
> On Fri, Jan 4, 2013 at 10:47 AM, Mark Waite  wrote:
>
>> Just guessing, but is your Jenkins on Windows configured to run as a
>> service?  If so, then there may be portions of your build which assume that
>> a desktop is available, or that the process is running in a desktop context.
>>
>> I spent a little time wrestling with trying to perform builds as a
>> service.  Eventually I stopped, frustrated because I had some tests which I
>> knew would need to run as a desktop and there was not enough benefit to the
>> organization by me spending time investigating how to run a build as a
>> service when no one cares if the build runs as a service.
>>
>> I now configure any Windows Jenkins server to always from a logged in
>> desktop session rather than as a service.  Your mileage may vary...
>>
>> Mark Waite
>>
>>   --
>> *From:* Bryan Evenson 
>> *To:* jenkinsci-users@googlegroups.com
>> *Sent:* Friday, January 4, 2013 9:10 AM
>> *Subject:* Build hangs with Jenkins, runs fine from command line
>>
>> All,
>>
>> I am new to Jenkins and have two separate build jobs setup.  One job
>> builds successfully and the other one fails.  On the one that fails,
>> Jenkins successfully checks the project out of Subversion, successfully
>> runs "make clean", starts "make all" but then hangs when compiling the
>> first source file.  If I stop the job, open a command prompt and run "make
>> all" from the same directory which Jenkins had tried then the build
>> completes without issue.  Any ideas why Jenkins would stall in the middle
>> of a compile like that?
>>
>> Here is the thread dump from my system when the build was stalled.
>>
>> Regards,
>> Bryan
>>
>> Thread Dump
>>
>> AWT-Windows
>>
>> "AWT-Windows" Id=55 Group=main RUNNABLE (in native)
>> at sun.awt.windows.WToolkit.eventLoop(Native Method)
>> at sun.awt.windows.WToolkit.run(Unknown Source)
>> at java.lang.Thread.run(Unknown Source)
>>
>> cmd /c call C:\windows\TEMP\hudson7335823588872127651.bat: stdout copier
>>
>> "cmd /c call C:\windows\TEMP\hudson7335823588872127651.bat: stdout
>> copier" Id=128 Group=main RUNNABLE (in native)
>> at java.io.FileInputStream.readBytes(Native Method)
>> at java.io.FileInputStream.read(Unknown Source)
>> at java.io.BufferedInputStream.read1(Unknown Source)
>> at java.io.BufferedInputStream.read(Unknown Source)
>> -  locked java.io.BufferedInputStream@1851a89
>> at java.io.FilterInputStream.read(Unknown Source)
>> at hudson.util.StreamCopyThread.run(StreamCopyThread.java:60)
>>
>> ComThread for Handling GET /configureSecurity/ : RequestHandlerThread[#3]
>>
>> "ComThread for Handling GET /configureSecurity/ :
>> RequestHandlerThread[#3]" Id=59 Group=main RUNNABLE (in native)
>> at com4j.Win32Lock.suspend0(Native Method)
>> at com4j.Win32Lock.suspend(Win32Lock.java:37)
>> at com4j.ComThread.run0(ComThread.java:146)
>> at com4j.ComThread.run(ComThread.java:134)
>>
>> ConnectorThread:[ajp13-8009]
>>
>> "ConnectorThread:[ajp13-8009]" Id=12 Group=main RUNNABLE (in native)
>> at java.net.PlainSocketImpl.socketAccept(Native Method)
>> at java.net.PlainSocketImpl.accept(Unknown Source)
>> -  locked java.net.SocksSocketImpl@45548
>> at java.net.ServerSocket.implAccept(Unknown Source)
>> at java.net.ServerSocket.accept(Unknown Source)
>> at winstone.ajp13.Ajp13Listener.run(Ajp13Listener.java:116)
>> at java.lang.Thread.run(Unknown Source)
>>
>> ConnectorThread:[http-8080]
>>
>> "ConnectorThread:[http-8080]" Id=11 Group=main RUNNABLE (in native)
>> at java.net.PlainSocketImpl.socketAccept(Native Method)
>> at java.net.PlainSocketImpl.accept(Unknown Source)
>> -  locked java.net.SocksSocketImpl@7aec07
>> at java.net.ServerSocket.implAccept(Unknown Source)
>> at java.net.ServerSocket.accept(Unknown Source)
>> at winstone.HttpListener.run(HttpListener.java:137)
>> at java.lang.Thread.run(Unknown Source)
>>
>> DestroyJavaVM
>>
>> "DestroyJavaVM" Id=15 Group=main RUNNABLE
>>
>> Executor #0 for master : executing Hood Controller Autobuild #72
>>
>> "Executor #0 for master : executing Hood Controller Autobuild #72" Id=36
>> Group=main RUNNABLE (in native)
>> at java.lang.ProcessImpl.waitFor(Native Method)
>> at hudson.Proc$LocalProc.join(Proc.java:319)
>> at hudson.Launcher$ProcStar

RE: Two quick questions about slave nodes.

2013-01-04 Thread Mandeville, Rob
Do you mean installing a slave or launching it?

A slave is simply a .jar file.  Copy it where it needs to be, make sure you 
have a JVM that can run it, and you’ve installed it.

I have a number of slaves set up with “launch by running a command on the 
server”.  Said command just ssh’s to the target host as the right user and runs 
“java –jar slave.jar”.  At least in Unix (my forte), you can set up a launcher 
command like “ssh remote_host \”curl {right args to get slave.jar from the 
Jenkins server} && java –jar slave.jar”.  The actual command, and what it would 
take on other platforms, is left as an exercise to the reader.

As far as uninstalling goes, I don’t think so.  I don’t think there’s a 
“trigger this job on shutdown” command.  Is there a real need to delete 
slave.jar from the remote machine after shutting down the slave?

--Rob Mandeville
Litle & Co (a member of the Vantiv family)

From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of Andrew Bayless
Sent: Friday, January 04, 2013 12:55 PM
To: jenkinsci-users@googlegroups.com
Subject: Two quick questions about slave nodes.

Hello,

I have two quick questions about Jenkins slaves:

1) Is it possible to have Jenkins install a slave on a machine remotely ?

2) Is it possible to have a slave uninstall itself ?

Thank you,
Andrew

The information in this message is for the intended recipient(s) only and may 
be the proprietary and/or confidential property of Litle & Co., LLC, and thus 
protected from disclosure. If you are not the intended recipient(s), or an 
employee or agent responsible for delivering this message to the intended 
recipient, you are hereby notified that any use, dissemination, distribution or 
copying of this communication is prohibited. If you have received this 
communication in error, please notify Litle & Co. immediately by replying to 
this message and then promptly deleting it and your reply permanently from your 
computer.


Re: Two quick questions about slave nodes.

2013-01-04 Thread Jonathan Rogers
Andrew Bayless wrote:
> Hello,
>
> I have two quick questions about Jenkins slaves:
>
> 1) Is it possible to have Jenkins install a slave on a machine remotely ?
>
> 2) Is it possible to have a slave uninstall itself ?

Neither installation nor uninstallation is necessary in many cases as
long as a JVM capable of running the slave exists on the system. I have
Jenkins run a slave via SSH and it copies the JAR automatically and runs
it with no installation step necessary.

For more details:
https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds#Distributedbuilds-Differentwaysofstartingslaveagents>

-- 
Jonathan Rogers



Re: serially build on multiple slaves

2013-01-04 Thread Les Mikesell
On Fri, Jan 4, 2013 at 11:16 AM, christopher barry  wrote:
> Greetings,
>
> I have jenkins setup in a vm, and have 3 vm slaves all on the same
> physical machine - each with a different distro with different
> dependency versions for our application. Each time git has changed, all
> 3 slaves build at the same time.
>
> Is there a way to have jenkins build on slave1, and if OK then build on
> slave2, etc. in order like that?

If you are doing a matrix build you should have options to build
sequentially and to execute touchstone builds first.

-- 
   Les Mikesell
  lesmikes...@gmail.com


Two quick questions about slave nodes.

2013-01-04 Thread Andrew Bayless
Hello, 

I have two quick questions about Jenkins slaves: 

1) Is it possible to have Jenkins install a slave on a machine remotely ? 

2) Is it possible to have a slave uninstall itself ? 

Thank you, 
Andrew 


Re: Build hangs with Jenkins, runs fine from command line

2013-01-04 Thread Slide
You could take a look at [1] and see if this works for you. I've had
success with something similar in the past.

slide

1 -
http://lostechies.com/keithdahlby/2011/08/13/allowing-a-windows-service-to-interact-with-desktop-without-localsystem/


On Fri, Jan 4, 2013 at 10:47 AM, Mark Waite  wrote:

> Just guessing, but is your Jenkins on Windows configured to run as a
> service?  If so, then there may be portions of your build which assume that
> a desktop is available, or that the process is running in a desktop context.
>
> I spent a little time wrestling with trying to perform builds as a
> service.  Eventually I stopped, frustrated because I had some tests which I
> knew would need to run as a desktop and there was not enough benefit to the
> organization by me spending time investigating how to run a build as a
> service when no one cares if the build runs as a service.
>
> I now configure any Windows Jenkins server to always from a logged in
> desktop session rather than as a service.  Your mileage may vary...
>
> Mark Waite
>
>   --
> *From:* Bryan Evenson 
> *To:* jenkinsci-users@googlegroups.com
> *Sent:* Friday, January 4, 2013 9:10 AM
> *Subject:* Build hangs with Jenkins, runs fine from command line
>
> All,
>
> I am new to Jenkins and have two separate build jobs setup.  One job
> builds successfully and the other one fails.  On the one that fails,
> Jenkins successfully checks the project out of Subversion, successfully
> runs "make clean", starts "make all" but then hangs when compiling the
> first source file.  If I stop the job, open a command prompt and run "make
> all" from the same directory which Jenkins had tried then the build
> completes without issue.  Any ideas why Jenkins would stall in the middle
> of a compile like that?
>
> Here is the thread dump from my system when the build was stalled.
>
> Regards,
> Bryan
>
> Thread Dump
>
> AWT-Windows
>
> "AWT-Windows" Id=55 Group=main RUNNABLE (in native)
> at sun.awt.windows.WToolkit.eventLoop(Native Method)
> at sun.awt.windows.WToolkit.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
>
> cmd /c call C:\windows\TEMP\hudson7335823588872127651.bat: stdout copier
>
> "cmd /c call C:\windows\TEMP\hudson7335823588872127651.bat: stdout copier"
> Id=128 Group=main RUNNABLE (in native)
> at java.io.FileInputStream.readBytes(Native Method)
> at java.io.FileInputStream.read(Unknown Source)
> at java.io.BufferedInputStream.read1(Unknown Source)
> at java.io.BufferedInputStream.read(Unknown Source)
> -  locked java.io.BufferedInputStream@1851a89
> at java.io.FilterInputStream.read(Unknown Source)
> at hudson.util.StreamCopyThread.run(StreamCopyThread.java:60)
>
> ComThread for Handling GET /configureSecurity/ : RequestHandlerThread[#3]
>
> "ComThread for Handling GET /configureSecurity/ :
> RequestHandlerThread[#3]" Id=59 Group=main RUNNABLE (in native)
> at com4j.Win32Lock.suspend0(Native Method)
> at com4j.Win32Lock.suspend(Win32Lock.java:37)
> at com4j.ComThread.run0(ComThread.java:146)
> at com4j.ComThread.run(ComThread.java:134)
>
> ConnectorThread:[ajp13-8009]
>
> "ConnectorThread:[ajp13-8009]" Id=12 Group=main RUNNABLE (in native)
> at java.net.PlainSocketImpl.socketAccept(Native Method)
> at java.net.PlainSocketImpl.accept(Unknown Source)
> -  locked java.net.SocksSocketImpl@45548
> at java.net.ServerSocket.implAccept(Unknown Source)
> at java.net.ServerSocket.accept(Unknown Source)
> at winstone.ajp13.Ajp13Listener.run(Ajp13Listener.java:116)
> at java.lang.Thread.run(Unknown Source)
>
> ConnectorThread:[http-8080]
>
> "ConnectorThread:[http-8080]" Id=11 Group=main RUNNABLE (in native)
> at java.net.PlainSocketImpl.socketAccept(Native Method)
> at java.net.PlainSocketImpl.accept(Unknown Source)
> -  locked java.net.SocksSocketImpl@7aec07
> at java.net.ServerSocket.implAccept(Unknown Source)
> at java.net.ServerSocket.accept(Unknown Source)
> at winstone.HttpListener.run(HttpListener.java:137)
> at java.lang.Thread.run(Unknown Source)
>
> DestroyJavaVM
>
> "DestroyJavaVM" Id=15 Group=main RUNNABLE
>
> Executor #0 for master : executing Hood Controller Autobuild #72
>
> "Executor #0 for master : executing Hood Controller Autobuild #72" Id=36
> Group=main RUNNABLE (in native)
> at java.lang.ProcessImpl.waitFor(Native Method)
> at hudson.Proc$LocalProc.join(Proc.java:319)
> at hudson.Launcher$ProcStarter.join(Launcher.java:360)
> at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:91)
> at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:60)
> at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
> at
> hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804)
> at hudson.model.Build$BuildExecution.build(Build.java:199)
> at hudson.model.Build$BuildExecution.doRun(Build.java:160)
> at
> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:586)
> at hudson.model.Run.execute(Run.java:1543)
> at hudson.model.FreeStyle

RE: Post Build Task matching - quick question

2013-01-04 Thread Merrow, Frank
I am not saying this is your issue, but you have a minor bug . . . a missing 
“.” After the second S in SUCCESS:

^.*POST.*BUILD.*TASK.*SUCCESS.*$

Because of the missing “.” . . . if there was any white space after SUCCESS the 
rexexp would fail.

Might be your problem . . . might not.

Frank

From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of zw
Sent: Friday, January 04, 2013 9:26 AM
To: jenkinsci-users@googlegroups.com
Subject: Post Build Task matching - quick question

Hi

We have a plugin to perform task post build. We have 2 post tasks
We tried to match this string below, belonging to the first post task run

POST BUILD TASK : SUCCESS



On our second post task, we tried to match it, as a condition, to

^.*POST.*BUILD.*TASK.*SUCCESS*$



But we're getting

Could not match :^.*POST.*BUILD.*TASK.*SUCCESS*$  : False



and so it skipped our shell script execution.



How can we fix this regex ?



Thanks you all.






Re: Build hangs with Jenkins, runs fine from command line

2013-01-04 Thread Mark Waite
Just guessing, but is your Jenkins on Windows configured to run as a service?  
If so, then there may be portions of your build which assume that a desktop is 
available, or that the process is running in a desktop context.

I spent a little time wrestling with trying to perform builds as a service.  
Eventually I stopped, frustrated because I had some tests which I knew would 
need to run as a desktop and there was not enough benefit to the organization 
by me spending time investigating how to run a build as a service when no one 
cares if the build runs as a service.

I now configure any Windows Jenkins server to always from a logged in desktop 
session rather than as a service.  Your mileage may vary...

Mark Waite



>
> From: Bryan Evenson 
>To: jenkinsci-users@googlegroups.com 
>Sent: Friday, January 4, 2013 9:10 AM
>Subject: Build hangs with Jenkins, runs fine from command line
> 
>
>All,
>
>I am new to Jenkins and have two separate build jobs setup.  One job builds 
>successfully and the other one fails.  On the one that fails, Jenkins 
>successfully checks the project out of Subversion, successfully runs "make 
>clean", starts "make all" but then hangs when compiling the first source file. 
> If I stop the job, open a command prompt and run "make all" from the same 
>directory which Jenkins had tried then the build completes without issue.  Any 
>ideas why Jenkins would stall in the middle of a compile like that?
>
>Here is the thread dump from my system when the build was stalled.
>
>Regards,
>Bryan
>
>
>Thread Dump
>
>AWT-Windows
>
>"AWT-Windows" Id=55 Group=main RUNNABLE (in native)
>at sun.awt.windows.WToolkit.eventLoop(Native Method)
>at sun.awt.windows.WToolkit.run(Unknown Source)
>at java.lang.Thread.run(Unknown Source)
>
>cmd /c call C:\windows\TEMP\hudson7335823588872127651.bat: stdout copier
>
>"cmd /c call C:\windows\TEMP\hudson7335823588872127651.bat: stdout copier" 
>Id=128 Group=main RUNNABLE (in native)
>at java.io.FileInputStream.readBytes(Native Method)
>at java.io.FileInputStream.read(Unknown Source)
>at java.io.BufferedInputStream.read1(Unknown Source)
>at java.io.BufferedInputStream.read(Unknown Source)
>-  locked java.io.BufferedInputStream@1851a89
>at java.io.FilterInputStream.read(Unknown Source)
>at hudson.util.StreamCopyThread.run(StreamCopyThread.java:60)
>
>ComThread for Handling GET /configureSecurity/ : RequestHandlerThread[#3]
>
>"ComThread for Handling GET /configureSecurity/ : RequestHandlerThread[#3]" 
>Id=59 Group=main RUNNABLE (in native)
>at com4j.Win32Lock.suspend0(Native Method)
>at com4j.Win32Lock.suspend(Win32Lock.java:37)
>at com4j.ComThread.run0(ComThread.java:146)
>at com4j.ComThread.run(ComThread.java:134)
>
>ConnectorThread:[ajp13-8009]
>
>"ConnectorThread:[ajp13-8009]" Id=12 Group=main RUNNABLE (in native)
>at java.net.PlainSocketImpl.socketAccept(Native Method)
>at java.net.PlainSocketImpl.accept(Unknown Source)
>-  locked java.net.SocksSocketImpl@45548
>at java.net.ServerSocket.implAccept(Unknown Source)
>at java.net.ServerSocket.accept(Unknown Source)
>at winstone.ajp13.Ajp13Listener.run(Ajp13Listener.java:116)
>at java.lang.Thread.run(Unknown Source)
>
>ConnectorThread:[http-8080]
>
>"ConnectorThread:[http-8080]" Id=11 Group=main RUNNABLE (in native)
>at java.net.PlainSocketImpl.socketAccept(Native Method)
>at java.net.PlainSocketImpl.accept(Unknown Source)
>-  locked java.net.SocksSocketImpl@7aec07
>at java.net.ServerSocket.implAccept(Unknown Source)
>at java.net.ServerSocket.accept(Unknown Source)
>at winstone.HttpListener.run(HttpListener.java:137)
>at java.lang.Thread.run(Unknown Source)
>
>DestroyJavaVM
>
>"DestroyJavaVM" Id=15 Group=main RUNNABLE
>
>Executor #0 for master : executing Hood Controller Autobuild #72
>
>"Executor #0 for master : executing Hood Controller Autobuild #72" Id=36 
>Group=main RUNNABLE (in native)
>at java.lang.ProcessImpl.waitFor(Native Method)
>at hudson.Proc$LocalProc.join(Proc.java:319)
>at hudson.Launcher$ProcStarter.join(Launcher.java:360)
>at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:91)
>at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:60)
>at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
>at 
>hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804)
>at hudson.model.Build$BuildExecution.build(Build.java:199)
>at hudson.model.Build$BuildExecution.doRun(Build.java:160)
>at 
>hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:586)
>at hudson.model.Run.execute(Run.java:1543)
>at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
>at hudson.model.ResourceController.execute(ResourceController.java:88)
>at hudson.model.Executor.run(Executor.java:236)
>
>Executor #1 for master
>
>"Executor #1 for master" Id=37 Group=main WAITING on hudson.model.Queue@9d75be
>at java.lang.Object.wait(Native Method)
>-  waiting on hudson.model.Queue@9d75be
>at java.lang.Object.wait(Object.java:

Re: Git question...

2013-01-04 Thread Mark Waite
That is very good news.  

You might consider using the plugin that automatic labels slaves (and the 
master).  It labels for operating system type, operating system release, and 
processor type, and spares you the hassle of remembering to apply those types 
of labels.

Mark Waite



>
> From: Jeff 
>To: jenkinsci-users@googlegroups.com 
>Sent: Friday, January 4, 2013 9:53 AM
>Subject: Re: Git question...
> 
>
>That was it!  Thank you!  
>
>
>I had the auto installer running "sudo apt-get install git" on nodes labeled 
>"Linux" but didn't label the master because it wasn't doing builds.  It didn't 
>occur to me that the job configs still needed the tool configured.
>
>
>I added the label "Linux" to the master config and updated the /etc/sudoers 
>file to allow the tomcat user to run apt-get without password and the error 
>went away.
>
>
>tomcat7       ALL = NOPASSWD: /usr/bin/apt-get
>
>
>Thanks again!
>
>
>
>On Fri, Jan 4, 2013 at 1:35 AM, Michaël Pailloncy  wrote:
>
>Hi,
>>
>>
>>We've faced with the same problem in our company. 
>>
>>
>>Do you used an automatic installation for git in the global configuration ?
>>
>>
>>It seems that, the Git plugin uses the first Git installation found in 
>>Jenkins global configuration (see 
>>https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/UserRemoteConfig.java#L73).
>>So, If the first git installation found used automatic installation, it seems 
>>that Jenkins doesn't download/install git before doing the git ls-remote 
>>(because your Jenkins master doesn't make any build), resulting in :
>>Failed to connect to repository : Error performing command:  ls-remote -h 
>>gitolite@mygitrepo:/myproject.git HEAD
>>
>>
>>
>>The git executable isn't found here, otherwise we would have :
>>Failed to connect to repository : Error performing command: git ls-remote -h 
>>gitolite@mygitrepo:/myproject.git HEAD
>>
>>
>>
>>To solve this problem, I have declared a local git installation for the 
>>master (not installed automatically) and set it in first in the global 
>>configuration.
>>
>>
>>I hope this will help you.
>>
>>
>>Michaël Pailloncy 
>>
>>
>>
>>
>>
>>2013/1/4 Jeff 
>>
>>Thanks for the tips...I'll try and poke around with it tomorrow.  I'm finding 
>>Git to be a pain compared to SVNugh...likely loose nut behind the 
>>keyboard.  
>>>
>>>
>>>My Jenkins server has 4GB of RAM and 2.5 GB is dedicated to tomcat running 
>>>Jenkins but I will triple check the settings as well.  We actually have 2 
>>>Jenkins masters now experiencing the issue that are identically configured 
>>>(cloned VM).  One is running 40 jobs (3 Git, 37 SVN) on 3 slaves (no jobs 
>>>run on master).  The other running only one Git job on the master (no 
>>>slaves).
>>>
>>>
>>>
>>>
>>>
>>>On Thu, Jan 3, 2013 at 8:02 PM, Mark Waite  wrote:
>>>
>>>There was a report of the same error message in late November that was due 
>>>to insufficient memory being available for the Jenkins process.  Refer to 
>>>http://jenkins.361315.n4.nabble.com/Jenkins-GIT-ls-remote-error-td4646903.html
>>> for more details on it.  I suspect that is not your issue, but it should be 
>>>easy to check if it is the problem.


You could also try configuring a git repository without using gitolite (for 
instance, use apt-get to install the git server, publish the repository to 
/var/cache/git/repo_name, touch git-daemon-export-ok in that directory, and 
then create a job which uses git://yourserver/git/repo_name to checkout.  
That idea is suggested in 
http://stackoverflow.com/questions/12614771/configure-git-repository-in-jenkins
 .  I don't think that is likely your problem either, but trying the fix 
may expose the real problem to you.


Mark Waite







>
> From: Jeff 
>To: jenkinsci-users@googlegroups.com 
>Sent: Thursday, January 3, 2013 5:22 PM
>Subject: Re: Git question...
> 
>
>
>I didn't even realize those options existed...ack!  
>
>
>I checked and "Fast remote polling" is NOT set.  I have not set any other 
>options beyond the repo URL.  Did I possibly miss something?
>
>
>
>
>
>On Thu, Jan 3, 2013 at 5:17 PM, Mark Waite  wrote:
>
>I thought that I had seen that failure when I enabled "fast remote 
>polling" and had not yet cloned  the git repository.  
>>
>>
>>My quick web search did not show that as a bug, so I may be wrong, but it 
>>won't hurt to try disabling fast remote polling (it is in the Advanced 
>>section of the git plugin settings for your job).  I tried to duplicate 
>>the problem myself and was unable to duplicate it, so I'm probably not 
>>using exactly the steps you are using.
>>
>>
>>Mark Waite
>>
>>
>>
>>>
>>> From: Jeff 
>>>To: jenkinsci-users@g

now getting 401 unauthorized in jenkins when deploying artifact to archiva maven repo

2013-01-04 Thread Gary Ogden
This used to work before I upgraded Jenkins to 1.494. Now I get this error 
in Jenkins when using the promoted builds plugin to copy the war artifact 
to the snapshot repo:

ERROR: Failed to deploy artifacts: Could not transfer artifact 
com.blah.data:RestWebServices:war:1.0-20121224.163825-2 from/to 
archiva.apache.snapshots 
(http://10.31.31.64:8080/archiva/repository/snapshots): Failed to transfer 
file: 
http://10.31.31.64:8080/archiva/repository/snapshots/com/blah/data/RestWebServices/1.0-SNAPSHOT/RestWebServices-1.0-20121224.163825-2.war.
 Return code is: 401, ReasonPhrase:Unauthorized.
org.apache.maven.artifact.deployer.ArtifactDeploymentException: Failed to 
deploy artifacts: Could not transfer artifact 
com.blah.data:RestWebServices:war:1.0-20121224.163825-2 from/to 
archiva.apache.snapshots 
(http://10.31.31.64:8080/archiva/repository/snapshots): Failed to transfer 
file: 
http://10.31.31.64:8080/archiva/repository/snapshots/com/blah/data/RestWebServices/1.0-SNAPSHOT/RestWebServices-1.0-20121224.163825-2.war.
 Return code is: 401, ReasonPhrase:Unauthorized.
at 
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:141)
at 
hudson.maven.reporters.MavenArtifactRecord.deploy(MavenArtifactRecord.java:190)
at hudson.maven.RedeployPublisher.perform(RedeployPublisher.java:173)
at 
hudson.plugins.promoted_builds.Promotion$RunnerImpl.build(Promotion.java:187)
at 
hudson.plugins.promoted_builds.Promotion$RunnerImpl.doRun(Promotion.java:141)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:586)
at hudson.model.Run.execute(Run.java:1543)
at hudson.model.Run.run(Run.java:1489)
at hudson.plugins.promoted_builds.Promotion.run(Promotion.java:106)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:236)
Caused by: org.sonatype.aether.deployment.DeploymentException: Failed to deploy 
artifacts: Could not transfer artifact 
com.blah.data:RestWebServices:war:1.0-20121224.163825-2 from/to 
archiva.apache.snapshots 
(http://10.31.31.64:8080/archiva/repository/snapshots): Failed to transfer 
file: 
http://10.31.31.64:8080/archiva/repository/snapshots/com/blah/data/RestWebServices/1.0-SNAPSHOT/RestWebServices-1.0-20121224.163825-2.war.
 Return code is: 401, ReasonPhrase:Unauthorized.
at 
org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:280)
at 
org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:211)
at 
org.sonatype.aether.impl.internal.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:443)
at 
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:137)
... 10 more
Caused by: org.sonatype.aether.transfer.ArtifactTransferException: Could not 
transfer artifact com.blah.data:RestWebServices:war:1.0-20121224.163825-2 
from/to archiva.apache.snapshots 
(http://10.31.31.64:8080/archiva/repository/snapshots): Failed to transfer 
file: 
http://10.31.31.64:8080/archiva/repository/snapshots/com/blah/data/RestWebServices/1.0-SNAPSHOT/RestWebServices-1.0-20121224.163825-2.war.
 Return code is: 401, ReasonPhrase:Unauthorized.
at 
org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap(WagonRepositoryConnector.java:951)
at 
org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap(WagonRepositoryConnector.java:941)
at 
org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:837)
at 
org.sonatype.aether.connector.wagon.WagonRepositoryConnector.put(WagonRepositoryConnector.java:467)
at 
org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:274)
... 13 more
Caused by: org.apache.maven.wagon.TransferFailedException: Failed to transfer 
file: 
http://10.31.31.64:8080/archiva/repository/snapshots/com/blah/data/RestWebServices/1.0-SNAPSHOT/RestWebServices-1.0-20121224.163825-2.war.
 Return code is: 401, ReasonPhrase:Unauthorized.
at 
org.apache.maven.wagon.shared.http4.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:613)
at 
org.apache.maven.wagon.shared.http4.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:509)
at 
org.apache.maven.wagon.shared.http4.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:490)
at 
org.apache.maven.wagon.shared.http4.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:470)
at 
org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:811)
... 15 more

I have the creds in the settings.xml file:


  snapshots
  admin
  **


Not sure why this all of a sudden stopped working with 1.494. I downgraded 
incrementally to 1.491 and it still happened. Very frustrating.

I know what settings.xml file it is using since I added 
help:effective-settings to the build and it gets printed in the build.

Need your help on Plot plugin.

2013-01-04 Thread rangashankar
Hi Team,

Bit puzzled, Need your help to know if the following .csv data format works
for Plot plugin.

API  Query  Count
XX,INSERT , 2
YY,INSERT , 4
DD,UPDATE , 4
SS,UPDATE , 33

and also, can we plot Bar graph with it ?

Thanks in advance,
Shankar





--
View this message in context: 
http://jenkins.361315.n4.nabble.com/current-status-of-plot-plugin-tp1689987p4650200.html
Sent from the Jenkins users mailing list archive at Nabble.com.


getting 401 unauthorized in jenkins when deploying artifact to archiva maven repo

2013-01-04 Thread Gary Ogden
This used to work before I upgraded Jenkins to 1.494. Now I get this error 
in Jenkins when using the promote builds plugin to copy the war artifact to 
the snapshot repo. But nothing has changed except I upgraded the 
jenkins.war.

ERROR: Failed to deploy artifacts: Could not transfer artifact 
> com.blah.data:RestWebServices:war:1.0-20121224.163825-2 from/to 
> archiva.apache.snapshots 
> (http://10.31.31.64:8080/archiva/repository/snapshots): Failed to transfer 
> file: 
> http://10.31.31.64:8080/archiva/repository/snapshots/com/blah/data/RestWebServices/1.0-SNAPSHOT/RestWebServices-1.0-20121224.163825-2.war.
>  
> Return code is: 401, ReasonPhrase:Unauthorized.
> org.apache.maven.artifact.deployer.ArtifactDeploymentException: Failed to 
> deploy artifacts: Could not transfer artifact 
> com.blah.data:RestWebServices:war:1.0-20121224.163825-2 from/to 
> archiva.apache.snapshots 
> (http://10.31.31.64:8080/archiva/repository/snapshots): Failed to transfer 
> file: 
> http://10.31.31.64:8080/archiva/repository/snapshots/com/blah/data/RestWebServices/1.0-SNAPSHOT/RestWebServices-1.0-20121224.163825-2.war.
>  
> Return code is: 401, ReasonPhrase:Unauthorized.
> at 
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:141)
> at 
> hudson.maven.reporters.MavenArtifactRecord.deploy(MavenArtifactRecord.java:190)
> at hudson.maven.RedeployPublisher.perform(RedeployPublisher.java:173)
> at 
> hudson.plugins.promoted_builds.Promotion$RunnerImpl.build(Promotion.java:187)
> at 
> hudson.plugins.promoted_builds.Promotion$RunnerImpl.doRun(Promotion.java:141)
> at 
> hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:586)
> at hudson.model.Run.execute(Run.java:1543)
> at hudson.model.Run.run(Run.java:1489)
> at hudson.plugins.promoted_builds.Promotion.run(Promotion.java:106)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:236)
> Caused by: org.sonatype.aether.deployment.DeploymentException: Failed to 
> deploy artifacts: Could not transfer artifact 
> com.blah.data:RestWebServices:war:1.0-20121224.163825-2 from/to 
> archiva.apache.snapshots 
> (http://10.31.31.64:8080/archiva/repository/snapshots): Failed to transfer 
> file: 
> http://10.31.31.64:8080/archiva/repository/snapshots/com/blah/data/RestWebServices/1.0-SNAPSHOT/RestWebServices-1.0-20121224.163825-2.war.
>  
> Return code is: 401, ReasonPhrase:Unauthorized.
> at 
> org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:280)
> at 
> org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:211)
> at 
> org.sonatype.aether.impl.internal.DefaultRepositorySystem.deploy(DefaultRepositorySystem.java:443)
> at 
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:137)
> ... 10 more
> Caused by: org.sonatype.aether.transfer.ArtifactTransferException: Could 
> not transfer artifact 
> com.blah.data:RestWebServices:war:1.0-20121224.163825-2 from/to 
> archiva.apache.snapshots 
> (http://10.31.31.64:8080/archiva/repository/snapshots): Failed to transfer 
> file: 
> http://10.31.31.64:8080/archiva/repository/snapshots/com/blah/data/RestWebServices/1.0-SNAPSHOT/RestWebServices-1.0-20121224.163825-2.war.
>  
> Return code is: 401, ReasonPhrase:Unauthorized.
> at 
> org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap(WagonRepositoryConnector.java:951)
> at 
> org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap(WagonRepositoryConnector.java:941)
> at 
> org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:837)
> at 
> org.sonatype.aether.connector.wagon.WagonRepositoryConnector.put(WagonRepositoryConnector.java:467)
> at 
> org.sonatype.aether.impl.internal.DefaultDeployer.deploy(DefaultDeployer.java:274)
> ... 13 more
> Caused by: org.apache.maven.wagon.TransferFailedException: Failed to 
> transfer file: 
> http://10.31.31.64:8080/archiva/repository/snapshots/com/blah/data/RestWebServices/1.0-SNAPSHOT/RestWebServices-1.0-20121224.163825-2.war.
>  
> Return code is: 401, ReasonPhrase:Unauthorized.
> at 
> org.apache.maven.wagon.shared.http4.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:613)
> at 
> org.apache.maven.wagon.shared.http4.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:509)
> at 
> org.apache.maven.wagon.shared.http4.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:490)
> at 
> org.apache.maven.wagon.shared.http4.AbstractHttpClientWagon.put(AbstractHttpClientWagon.java:470)
> at 
> org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:811)
> ... 15 more


I have the correct creds in settings.xml. It's the same as it was when this 
used to work.


snapshots
deployment
deployment






getting 401 unauthorized in jenkins when deploying artifact to archiva maven repo

2013-01-04 Thread oggie
This used to work before I upgraded Jenkins to 1.494. Now I get this error in
Jenkins when using the build promotion plugin to copy the war artifact to
the snapshot repo. It used to work and the only thing that changed was the
jenkins.war.I have the creds in the settings.xml file:Not sure why this
all of a sudden stopped working with 1.494. I downgraded incrementally to
1.491 and it still happened, so the upgrade changed something. Very
frustrating.



--
View this message in context: 
http://jenkins.361315.n4.nabble.com/getting-401-unauthorized-in-jenkins-when-deploying-artifact-to-archiva-maven-repo-tp4650071.html
Sent from the Jenkins users mailing list archive at Nabble.com.

Re: Change path of .m2 directory if using maven-plugin

2013-01-04 Thread Alec Disharoon
I'm having this issue, too.  Since we already set a JENKINS_HOME, shouldn't 
that be used, instead of whatever user.home is set to?  For me, Jenkins is 
running under Tomcat from Ubuntu's apt repository, so it is running as the 
tomcat7 user which has a home of /usr/share/tomcat7, which isn't writable 
by the tomcat7 user.  Looking at JIRA and googling around, it doesn't 
appear that anyone else thinks this is a problem, so maybe I am not 
understanding something.  

I realize that ~/.m2 is the standard, but I can't think of any reason why 
this standard should be adhered to so strictly that no customization is 
allowed, even for non-recommended cases.  

Alec

On Tuesday, March 20, 2012 7:20:56 PM UTC+1, domi wrote:
>>  
>> add "-Duser.home=/oath/toNewDir" to the options
>>  
>> /Domi
>>  
>>
>>  

Post Build Task matching - quick question

2013-01-04 Thread zw
Hi 

We have a plugin to perform task post build. We have 2 post tasks
We tried to match this string below, belonging to the first post task run

POST BUILD TASK : SUCCESS 


On our second post task, we tried to match it, as a condition, to 

^.*POST.*BUILD.*TASK.*SUCCESS*$


But we're getting

Could not match :^.*POST.*BUILD.*TASK.*SUCCESS*$  : False


and so it skipped our shell script execution.


How can we fix this regex ?


Thanks you all.





serially build on multiple slaves

2013-01-04 Thread christopher barry
Greetings,

I have jenkins setup in a vm, and have 3 vm slaves all on the same
physical machine - each with a different distro with different
dependency versions for our application. Each time git has changed, all
3 slaves build at the same time.

Is there a way to have jenkins build on slave1, and if OK then build on
slave2, etc. in order like that?

Thanks,
-C



Re: Git question...

2013-01-04 Thread Jeff
That was it!  Thank you!

I had the auto installer running "sudo apt-get install git" on nodes
labeled "Linux" but didn't label the master because it wasn't doing builds.
 It didn't occur to me that the job configs still needed the tool
configured.

I added the label "Linux" to the master config and updated the /etc/sudoers
file to allow the tomcat user to run apt-get without password and the error
went away.

tomcat7   ALL = NOPASSWD: /usr/bin/apt-get

Thanks again!


On Fri, Jan 4, 2013 at 1:35 AM, Michaël Pailloncy wrote:

> Hi,
>
> We've faced with the same problem in our company.
>
> Do you used an automatic installation for git in the global configuration ?
>
> It seems that, the Git plugin uses the first Git installation found in
> Jenkins global configuration (see
> https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/UserRemoteConfig.java#L73
> ).
> So, If the first git installation found used automatic installation, it
> seems that Jenkins doesn't download/install git before doing the
> git ls-remote (because your Jenkins master doesn't make any
> build), resulting in :
>  *Failed to connect to repository : Error performing command:  ls-remote
> -h gitolite@mygitrepo:/myproject.git HEAD*
> *
> *
> The git executable isn't found here, otherwise we would have :
> *Failed to connect to repository : Error performing command: git
> ls-remote -h gitolite@mygitrepo:/myproject.git HEAD*
>
> To solve this problem, I have declared a local git installation for the
> master (not installed automatically) and set it in first in the global
> configuration.
>
> I hope this will help you.
>
> Michaël Pailloncy
> *
> *
>
>
> 2013/1/4 Jeff 
>
>> Thanks for the tips...I'll try and poke around with it tomorrow.  I'm
>> finding Git to be a pain compared to SVNugh...likely loose nut behind
>> the keyboard.
>>
>> My Jenkins server has 4GB of RAM and 2.5 GB is dedicated to tomcat
>> running Jenkins but I will triple check the settings as well.  We actually
>> have 2 Jenkins masters now experiencing the issue that are identically
>> configured (cloned VM).  One is running 40 jobs (3 Git, 37 SVN) on 3 slaves
>> (no jobs run on master).  The other running only one Git job on the master
>> (no slaves).
>>
>>
>>
>> On Thu, Jan 3, 2013 at 8:02 PM, Mark Waite  wrote:
>>
>>> There was a report of the same error message in late November that was
>>> due to insufficient memory being available for the Jenkins process.  Refer
>>> to
>>> http://jenkins.361315.n4.nabble.com/Jenkins-GIT-ls-remote-error-td4646903.htmlfor
>>>  more details on it.  I suspect that is not your issue, but it should be
>>> easy to check if it is the problem.
>>>
>>> You could also try configuring a git repository without using gitolite
>>> (for instance, use apt-get to install the git server, publish the
>>> repository to /var/cache/git/repo_name, touch git-daemon-export-ok in that
>>> directory, and then create a job which uses git://yourserver/git/repo_name
>>> to checkout.  That idea is suggested in
>>> http://stackoverflow.com/questions/12614771/configure-git-repository-in-jenkins.
>>>   I don't think that is likely your problem either, but trying the fix may
>>> expose the real problem to you.
>>>
>>> Mark Waite
>>>
>>>
>>>
>>>   --
>>> *From:* Jeff 
>>> *To:* jenkinsci-users@googlegroups.com
>>> *Sent:* Thursday, January 3, 2013 5:22 PM
>>> *Subject:* Re: Git question...
>>>
>>> I didn't even realize those options existed...ack!
>>>
>>> I checked and "Fast remote polling" is NOT set.  I have not set any
>>> other options beyond the repo URL.  Did I possibly miss something?
>>>
>>>
>>>
>>> On Thu, Jan 3, 2013 at 5:17 PM, Mark Waite  wrote:
>>>
>>> I thought that I had seen that failure when I enabled "fast remote
>>> polling" and had not yet cloned  the git repository.
>>>
>>> My quick web search did not show that as a bug, so I may be wrong, but
>>> it won't hurt to try disabling fast remote polling (it is in the Advanced
>>> section of the git plugin settings for your job).  I tried to duplicate the
>>> problem myself and was unable to duplicate it, so I'm probably not using
>>> exactly the steps you are using.
>>>
>>> Mark Waite
>>>
>>>   --
>>> *From:* Jeff 
>>> *To:* jenkinsci-users@googlegroups.com
>>> *Sent:* Thursday, January 3, 2013 1:35 PM
>>> *Subject:* Git question...
>>>
>>> I have some Git projects (internal gitolite repository) that I'm
>>> configuring and when I put the git repo URL in, it shows this error below
>>> field:
>>>
>>> *Failed to connect to repository : Error performing command:  ls-remote
>>> -h gitolite@mygitrepo:/myproject.git HEAD*
>>>
>>> If I login as the user that Jenkins is running as (tomcat7 on Ubuntu
>>> 12.10) and type the same command, I don't get an error, but I also don't
>>> see any output of any kind.
>>>
>>> If I leave off the "HEAD" option, I get a response like:
>>>
>>> 6156c0bd163a1b9e3a878e889be53c5b80f48c36   

Build hangs with Jenkins, runs fine from command line

2013-01-04 Thread Bryan Evenson
All,

I am new to Jenkins and have two separate build jobs setup.  One job builds
successfully and the other one fails.  On the one that fails, Jenkins
successfully checks the project out of Subversion, successfully runs "make
clean", starts "make all" but then hangs when compiling the first source
file.  If I stop the job, open a command prompt and run "make all" from the
same directory which Jenkins had tried then the build completes without
issue.  Any ideas why Jenkins would stall in the middle of a compile like
that?

Here is the thread dump from my system when the build was stalled.

Regards,
Bryan

Thread Dump

AWT-Windows

"AWT-Windows" Id=55 Group=main RUNNABLE (in native)
at sun.awt.windows.WToolkit.eventLoop(Native Method)
at sun.awt.windows.WToolkit.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

cmd /c call C:\windows\TEMP\hudson7335823588872127651.bat: stdout copier

"cmd /c call C:\windows\TEMP\hudson7335823588872127651.bat: stdout copier"
Id=128 Group=main RUNNABLE (in native)
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
-  locked java.io.BufferedInputStream@1851a89
at java.io.FilterInputStream.read(Unknown Source)
at hudson.util.StreamCopyThread.run(StreamCopyThread.java:60)

ComThread for Handling GET /configureSecurity/ : RequestHandlerThread[#3]

"ComThread for Handling GET /configureSecurity/ : RequestHandlerThread[#3]"
Id=59 Group=main RUNNABLE (in native)
at com4j.Win32Lock.suspend0(Native Method)
at com4j.Win32Lock.suspend(Win32Lock.java:37)
at com4j.ComThread.run0(ComThread.java:146)
at com4j.ComThread.run(ComThread.java:134)

ConnectorThread:[ajp13-8009]

"ConnectorThread:[ajp13-8009]" Id=12 Group=main RUNNABLE (in native)
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(Unknown Source)
-  locked java.net.SocksSocketImpl@45548
at java.net.ServerSocket.implAccept(Unknown Source)
at java.net.ServerSocket.accept(Unknown Source)
at winstone.ajp13.Ajp13Listener.run(Ajp13Listener.java:116)
at java.lang.Thread.run(Unknown Source)

ConnectorThread:[http-8080]

"ConnectorThread:[http-8080]" Id=11 Group=main RUNNABLE (in native)
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(Unknown Source)
-  locked java.net.SocksSocketImpl@7aec07
at java.net.ServerSocket.implAccept(Unknown Source)
at java.net.ServerSocket.accept(Unknown Source)
at winstone.HttpListener.run(HttpListener.java:137)
at java.lang.Thread.run(Unknown Source)

DestroyJavaVM

"DestroyJavaVM" Id=15 Group=main RUNNABLE

Executor #0 for master : executing Hood Controller Autobuild #72

"Executor #0 for master : executing Hood Controller Autobuild #72" Id=36
Group=main RUNNABLE (in native)
at java.lang.ProcessImpl.waitFor(Native Method)
at hudson.Proc$LocalProc.join(Proc.java:319)
at hudson.Launcher$ProcStarter.join(Launcher.java:360)
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:91)
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:60)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804)
at hudson.model.Build$BuildExecution.build(Build.java:199)
at hudson.model.Build$BuildExecution.doRun(Build.java:160)
at
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:586)
at hudson.model.Run.execute(Run.java:1543)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:236)

Executor #1 for master

"Executor #1 for master" Id=37 Group=main WAITING on
hudson.model.Queue@9d75be
at java.lang.Object.wait(Native Method)
-  waiting on hudson.model.Queue@9d75be
at java.lang.Object.wait(Object.java:485)
at hudson.util.OneShotEvent.block(OneShotEvent.java:72)
at hudson.model.Queue.pop(Queue.java:875)
at hudson.model.Executor.grabJob(Executor.java:284)
at hudson.model.Executor.run(Executor.java:205)

Handling GET /threadDump : RequestHandlerThread[#20]

"Handling GET /threadDump : RequestHandlerThread[#20]" Id=97 Group=main
TIMED_WAITING on java.util.concurrent.FutureTask$Sync@3f6b14
at sun.misc.Unsafe.park(Native Method)
-  waiting on java.util.concurrent.FutureTask$Sync@3f6b14
at java.util.concurrent.locks.LockSupport.parkNanos(Unknown Source)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(Unknown
Source)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(Unknown
Source)
at java.util.concurrent.FutureTask$Sync.innerGet(Unknown Source)
at java.util.concurrent.FutureTask.get(Unknown Source)
at hudson.remoting.LocalChannel$2.get(LocalChannel.java:81)
at jenkins.model.Jenkins.getAllThreadDumps(Jenkins.java:2813)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Metho

Re: Jenkins svn ssh / host key verification problems

2013-01-04 Thread Bjørn Water
Yes i have checked both the user file wich is jenkins and the root and they 
both contain .

Still think that it is very wierd that a checkout works and tagging it 
works aswell but doing a release gives host problems.
Shouldn't checkout and tag give the same problem then?

On Friday, January 4, 2013 4:42:56 PM UTC+1, teilo wrote:
>
> are you sure you are looking in the correct file?
> it should be in the home file of the user that the jenkins service runs as.
> for the rpm the default (IIRC is ~jenkins/.ssh/known_hosts) - it may be 
> somewhere else depending on your container / launch /install method.
>
> the svn commands also needs to be run as this jenkins user.
>
>
> On Friday, 4 January 2013 15:32:55 UTC, Bjørn Water wrote:
>>
>> I have removed the host from the file and then ran it again.
>> There is no entry being made in that file so it does not override or 
>> writes something to the known_hosts file
>>
>> On Friday, January 4, 2013 3:54:09 PM UTC+1, teilo wrote:
>>>
>>> Jenkins tags using its inbuilt library (svnkit) as far as I am aware so 
>>> the native ssh client doesn't get a look in.
>>>
>>> to see if its overridden the entry just check ~/.ssh/known_hosts for an 
>>> entry for your server (after you removed it)
>>>
>>> What happens if as the jenkins user on the slave you run svn info 
>>> svn+ssh://yourserver/path/to/repo  ?
>>>
>>> On Friday, 4 January 2013 14:46:40 UTC, Bjørn Water wrote:

 Hi James,

 I have manually removed the entry from the file and then did a SSH 
 command again and accepted the certificate.
 Still getting the same problems as before.
 Is there a way to see if it overrides the entry?
 Because it works when I tag it and that is also a commit right?

 Thanks,

 Bjørn

 On Friday, January 4, 2013 3:28:46 PM UTC+1, teilo wrote:
>
> Hi Bjørn
>
>  As the jenkins user on the slave ssh to the svn server and accept 
> its key.
>
>  Depending on your ssh clinet it may override the entry stored in 
> ~/.ssh/known_hosts or may not.  (if not then remove the entry 
> manually from this file and retry with the ssh command)
>
> That should get it working
>
>  /James
>
> On Friday, 4 January 2013 14:19:31 UTC, Bjørn Water wrote:
>>
>> So i am trying to use the M2-release plugin to release my project and 
>> push it to my nexus.
>> I can do svn checkout and i can even tag my build and see it in my 
>> repo 
>> but when i try to do mvn release:prepare after a succesfull build i 
>> get an error
>>
>> [ERROR] BUILD FAILURE[INFO] 
>> 
>> [INFO] Unable to commit files
>> Provider message:
>> The svn command failed.
>> Command output:
>> Host key verification failed.
>> svn: Commit failed (details follow):
>> svn: To better debug SSH connection problems, remove the -q option from 
>> 'ssh' in the [tunnels] section of your Subversion configuration file.
>> svn: Network connection closed unexpectedly
>>
>> [INFO] 
>> 
>> [INFO] Trace
>> org.apache.maven.BuildFailureException: Unable to commit files
>> Provider message:
>> The svn command failed.
>> Command output:
>> Host key verification failed.
>> svn: Commit failed (details follow):
>> svn: To better debug SSH connection problems, remove the -q option from 
>> 'ssh' in the [tunnels] section of your Subversion configuration file.
>> svn: Network connection closed unexpectedly
>>
>>  at 
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
>>  at 
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
>>  at 
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
>>  at 
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
>>  at 
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
>>  at 
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
>>  at 
>> org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
>>  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
>>  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
>>  at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
>>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>  at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>  at 
>> sun.reflect.DelegatingMethodAccessorImpl.

Re: Jenkins svn ssh / host key verification problems

2013-01-04 Thread teilo
are you sure you are looking in the correct file?
it should be in the home file of the user that the jenkins service runs as.
for the rpm the default (IIRC is ~jenkins/.ssh/known_hosts) - it may be 
somewhere else depending on your container / launch /install method.

the svn commands also needs to be run as this jenkins user.


On Friday, 4 January 2013 15:32:55 UTC, Bjørn Water wrote:
>
> I have removed the host from the file and then ran it again.
> There is no entry being made in that file so it does not override or 
> writes something to the known_hosts file
>
> On Friday, January 4, 2013 3:54:09 PM UTC+1, teilo wrote:
>>
>> Jenkins tags using its inbuilt library (svnkit) as far as I am aware so 
>> the native ssh client doesn't get a look in.
>>
>> to see if its overridden the entry just check ~/.ssh/known_hosts for an 
>> entry for your server (after you removed it)
>>
>> What happens if as the jenkins user on the slave you run svn info 
>> svn+ssh://yourserver/path/to/repo  ?
>>
>> On Friday, 4 January 2013 14:46:40 UTC, Bjørn Water wrote:
>>>
>>> Hi James,
>>>
>>> I have manually removed the entry from the file and then did a SSH 
>>> command again and accepted the certificate.
>>> Still getting the same problems as before.
>>> Is there a way to see if it overrides the entry?
>>> Because it works when I tag it and that is also a commit right?
>>>
>>> Thanks,
>>>
>>> Bjørn
>>>
>>> On Friday, January 4, 2013 3:28:46 PM UTC+1, teilo wrote:

 Hi Bjørn

  As the jenkins user on the slave ssh to the svn server and accept its 
 key.

  Depending on your ssh clinet it may override the entry stored in 
 ~/.ssh/known_hosts or may not.  (if not then remove the entry manually 
 from this file and retry with the ssh command)

 That should get it working

  /James

 On Friday, 4 January 2013 14:19:31 UTC, Bjørn Water wrote:
>
> So i am trying to use the M2-release plugin to release my project and 
> push it to my nexus.
> I can do svn checkout and i can even tag my build and see it in my 
> repo 
> but when i try to do mvn release:prepare after a succesfull build i 
> get an error
>
> [ERROR] BUILD FAILURE[INFO] 
> 
> [INFO] Unable to commit files
> Provider message:
> The svn command failed.
> Command output:
> Host key verification failed.
> svn: Commit failed (details follow):
> svn: To better debug SSH connection problems, remove the -q option from 
> 'ssh' in the [tunnels] section of your Subversion configuration file.
> svn: Network connection closed unexpectedly
>
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.BuildFailureException: Unable to commit files
> Provider message:
> The svn command failed.
> Command output:
> Host key verification failed.
> svn: Commit failed (details follow):
> svn: To better debug SSH connection problems, remove the -q option from 
> 'ssh' in the [tunnels] section of your Subversion configuration file.
> svn: Network connection closed unexpectedly
>
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
>   at 
> org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:597)
>   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>   at hudson.maven.agent.Main.launch(Main.java:185)
>   at hudson.maven.MavenBuilder.call(MavenBuilder.java:153)
>   at hudson.maven.Maven2Builder.call(Maven2Builder.java

Re: Jenkins svn ssh / host key verification problems

2013-01-04 Thread Bjørn Water
I have removed the host from the file and then ran it again.
There is no entry being made in that file so it does not override or writes 
something to the known_hosts file

On Friday, January 4, 2013 3:54:09 PM UTC+1, teilo wrote:
>
> Jenkins tags using its inbuilt library (svnkit) as far as I am aware so 
> the native ssh client doesn't get a look in.
>
> to see if its overridden the entry just check ~/.ssh/known_hosts for an 
> entry for your server (after you removed it)
>
> What happens if as the jenkins user on the slave you run svn info 
> svn+ssh://yourserver/path/to/repo  ?
>
> On Friday, 4 January 2013 14:46:40 UTC, Bjørn Water wrote:
>>
>> Hi James,
>>
>> I have manually removed the entry from the file and then did a SSH 
>> command again and accepted the certificate.
>> Still getting the same problems as before.
>> Is there a way to see if it overrides the entry?
>> Because it works when I tag it and that is also a commit right?
>>
>> Thanks,
>>
>> Bjørn
>>
>> On Friday, January 4, 2013 3:28:46 PM UTC+1, teilo wrote:
>>>
>>> Hi Bjørn
>>>
>>>  As the jenkins user on the slave ssh to the svn server and accept its 
>>> key.
>>>
>>>  Depending on your ssh clinet it may override the entry stored in 
>>> ~/.ssh/known_hosts or may not.  (if not then remove the entry manually 
>>> from this file and retry with the ssh command)
>>>
>>> That should get it working
>>>
>>>  /James
>>>
>>> On Friday, 4 January 2013 14:19:31 UTC, Bjørn Water wrote:

 So i am trying to use the M2-release plugin to release my project and 
 push it to my nexus.
 I can do svn checkout and i can even tag my build and see it in my repo 
 but when i try to do mvn release:prepare after a succesfull build i get 
 an error

 [ERROR] BUILD FAILURE[INFO] 
 
 [INFO] Unable to commit files
 Provider message:
 The svn command failed.
 Command output:
 Host key verification failed.
 svn: Commit failed (details follow):
 svn: To better debug SSH connection problems, remove the -q option from 
 'ssh' in the [tunnels] section of your Subversion configuration file.
 svn: Network connection closed unexpectedly

 [INFO] 
 
 [INFO] Trace
 org.apache.maven.BuildFailureException: Unable to commit files
 Provider message:
 The svn command failed.
 Command output:
 Host key verification failed.
 svn: Commit failed (details follow):
 svn: To better debug SSH connection problems, remove the -q option from 
 'ssh' in the [tunnels] section of your Subversion configuration file.
 svn: Network connection closed unexpectedly

at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at 
 org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at hudson.maven.agent.Main.launch(Main.java:185)
at hudson.maven.MavenBuilder.call(MavenBuilder.java:153)
at hudson.maven.Maven2Builder.call(Maven2Builder.java:79)
at hudson.maven.Maven2Builder.call(Maven2Builder.java:55)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at 
 hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureT

Re: Jenkins svn ssh / host key verification problems

2013-01-04 Thread Bjørn Water
yes it is in var/lib/jenkins/.ssh thats is where our keys are already in 
place

On Friday, January 4, 2013 4:09:53 PM UTC+1, Adam Tong wrote:
>
> Hi, 
>
> Did you try copying the .ssh folder to the jenkins folder? 
>
> I am using git but this solved the problem. 
>
>
> On Fri, Jan 4, 2013 at 9:19 AM, Bjørn Water > 
> wrote: 
> > So i am trying to use the M2-release plugin to release my project and 
> push 
> > it to my nexus. 
> > I can do svn checkout and i can even tag my build and see it in my repo 
> > but when i try to do mvn release:prepare after a succesfull build i get 
> an 
> > error 
> > 
> > [ERROR] BUILD FAILURE 
> > [INFO] 
> >  
> > [INFO] Unable to commit files 
> > Provider message: 
> > The svn command failed. 
> > Command output: 
> > Host key verification failed. 
> > svn: Commit failed (details follow): 
> > svn: To better debug SSH connection problems, remove the -q option from 
> > 'ssh' in the [tunnels] section of your Subversion configuration file. 
> > svn: Network connection closed unexpectedly 
> > 
> > [INFO] 
> >  
> > [INFO] Trace 
> > org.apache.maven.BuildFailureException: Unable to commit files 
> > Provider message: 
> > The svn command failed. 
> > Command output: 
> > Host key verification failed. 
> > svn: Commit failed (details follow): 
> > svn: To better debug SSH connection problems, remove the -q option from 
> > 'ssh' in the [tunnels] section of your Subversion configuration file. 
> > svn: Network connection closed unexpectedly 
> > 
> > at 
> > 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
>  
>
> > at 
> > 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
>  
>
> > at 
> > 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
>  
>
> > at 
> > 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
>  
>
> > at 
> > 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
>  
>
> > at 
> > 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
>  
>
> > at 
> > 
> org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
>  
>
> > at 
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) 
> > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) 
> > at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) 
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
> > at 
> > 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
>
> > at 
> > 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>  
>
> > at java.lang.reflect.Method.invoke(Method.java:597) 
> > at 
> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) 
> > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) 
> > at hudson.maven.agent.Main.launch(Main.java:185) 
> > at hudson.maven.MavenBuilder.call(MavenBuilder.java:153) 
> > at hudson.maven.Maven2Builder.call(Maven2Builder.java:79) 
> > at hudson.maven.Maven2Builder.call(Maven2Builder.java:55) 
> > at hudson.remoting.UserRequest.perform(UserRequest.java:118) 
> > at hudson.remoting.UserRequest.perform(UserRequest.java:48) 
> > at hudson.remoting.Request$2.run(Request.java:326) 
> > at 
> > 
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
>  
>
> > at 
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) 
> > at java.util.concurrent.FutureTask.run(FutureTask.java:138) 
> > at 
> > 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>  
>
> > at 
> > 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>  
>
> > at java.lang.Thread.run(Thread.java:662) 
> > Caused by: org.apache.maven.plugin.MojoFailureException: Unable to 
> commit 
> > files 
> > Provider message: 
> > The svn command failed. 
> > Command output: 
> > Host key verification failed. 
> > svn: Commit failed (details follow): 
> > svn: To better debug SSH connection problems, remove the -q option from 
> > 'ssh' in the [tunnels] section of your Subversion configuration file. 
> > svn: Network connection closed unexpectedly 
> > 
> > at 
> > 
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:287)
>  
>
> > at 
> > 
> org.apache.maven.plugins.release.P

Re: Jenkins svn ssh / host key verification problems

2013-01-04 Thread Adam Tong
Hi,

Did you try copying the .ssh folder to the jenkins folder?

I am using git but this solved the problem.


On Fri, Jan 4, 2013 at 9:19 AM, Bjørn Water  wrote:
> So i am trying to use the M2-release plugin to release my project and push
> it to my nexus.
> I can do svn checkout and i can even tag my build and see it in my repo
> but when i try to do mvn release:prepare after a succesfull build i get an
> error
>
> [ERROR] BUILD FAILURE
> [INFO]
> 
> [INFO] Unable to commit files
> Provider message:
> The svn command failed.
> Command output:
> Host key verification failed.
> svn: Commit failed (details follow):
> svn: To better debug SSH connection problems, remove the -q option from
> 'ssh' in the [tunnels] section of your Subversion configuration file.
> svn: Network connection closed unexpectedly
>
> [INFO]
> 
> [INFO] Trace
> org.apache.maven.BuildFailureException: Unable to commit files
> Provider message:
> The svn command failed.
> Command output:
> Host key verification failed.
> svn: Commit failed (details follow):
> svn: To better debug SSH connection problems, remove the -q option from
> 'ssh' in the [tunnels] section of your Subversion configuration file.
> svn: Network connection closed unexpectedly
>
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
>   at
> org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:597)
>   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>   at hudson.maven.agent.Main.launch(Main.java:185)
>   at hudson.maven.MavenBuilder.call(MavenBuilder.java:153)
>   at hudson.maven.Maven2Builder.call(Maven2Builder.java:79)
>   at hudson.maven.Maven2Builder.call(Maven2Builder.java:55)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:118)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:48)
>   at hudson.remoting.Request$2.run(Request.java:326)
>   at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
>   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>   at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>   at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>   at java.lang.Thread.run(Thread.java:662)
> Caused by: org.apache.maven.plugin.MojoFailureException: Unable to commit
> files
> Provider message:
> The svn command failed.
> Command output:
> Host key verification failed.
> svn: Commit failed (details follow):
> svn: To better debug SSH connection problems, remove the -q option from
> 'ssh' in the [tunnels] section of your Subversion configuration file.
> svn: Network connection closed unexpectedly
>
>   at
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:287)
>   at
> org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:237)
>   at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
>   at
> hudson.maven.agent.PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:182)
>   at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
>   ... 28 more
> Caused by: org.apache.maven.shared.release.scm.ReleaseScmCommandException:
> Unable to commit files
> Provider message:
> The svn command failed.
> Command output:
> Host key verification failed.
> svn: Commit failed 

Re: Jenkins svn ssh / host key verification problems

2013-01-04 Thread teilo
Jenkins tags using its inbuilt library (svnkit) as far as I am aware so the 
native ssh client doesn't get a look in.

to see if its overridden the entry just check ~/.ssh/known_hosts for an 
entry for your server (after you removed it)

What happens if as the jenkins user on the slave you run svn info 
svn+ssh://yourserver/path/to/repo  ?

On Friday, 4 January 2013 14:46:40 UTC, Bjørn Water wrote:
>
> Hi James,
>
> I have manually removed the entry from the file and then did a SSH command 
> again and accepted the certificate.
> Still getting the same problems as before.
> Is there a way to see if it overrides the entry?
> Because it works when I tag it and that is also a commit right?
>
> Thanks,
>
> Bjørn
>
> On Friday, January 4, 2013 3:28:46 PM UTC+1, teilo wrote:
>>
>> Hi Bjørn
>>
>>  As the jenkins user on the slave ssh to the svn server and accept its 
>> key.
>>
>>  Depending on your ssh clinet it may override the entry stored in 
>> ~/.ssh/known_hosts or may not.  (if not then remove the entry manually 
>> from this file and retry with the ssh command)
>>
>> That should get it working
>>
>>  /James
>>
>> On Friday, 4 January 2013 14:19:31 UTC, Bjørn Water wrote:
>>>
>>> So i am trying to use the M2-release plugin to release my project and 
>>> push it to my nexus.
>>> I can do svn checkout and i can even tag my build and see it in my repo 
>>> but when i try to do mvn release:prepare after a succesfull build i get 
>>> an error
>>>
>>> [ERROR] BUILD FAILURE[INFO] 
>>> 
>>> [INFO] Unable to commit files
>>> Provider message:
>>> The svn command failed.
>>> Command output:
>>> Host key verification failed.
>>> svn: Commit failed (details follow):
>>> svn: To better debug SSH connection problems, remove the -q option from 
>>> 'ssh' in the [tunnels] section of your Subversion configuration file.
>>> svn: Network connection closed unexpectedly
>>>
>>> [INFO] 
>>> 
>>> [INFO] Trace
>>> org.apache.maven.BuildFailureException: Unable to commit files
>>> Provider message:
>>> The svn command failed.
>>> Command output:
>>> Host key verification failed.
>>> svn: Commit failed (details follow):
>>> svn: To better debug SSH connection problems, remove the -q option from 
>>> 'ssh' in the [tunnels] section of your Subversion configuration file.
>>> svn: Network connection closed unexpectedly
>>>
>>> at 
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
>>> at 
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
>>> at 
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
>>> at 
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
>>> at 
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
>>> at 
>>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
>>> at 
>>> org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
>>> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
>>> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
>>> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at 
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>> at 
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>> at java.lang.reflect.Method.invoke(Method.java:597)
>>> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>>> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>>> at hudson.maven.agent.Main.launch(Main.java:185)
>>> at hudson.maven.MavenBuilder.call(MavenBuilder.java:153)
>>> at hudson.maven.Maven2Builder.call(Maven2Builder.java:79)
>>> at hudson.maven.Maven2Builder.call(Maven2Builder.java:55)
>>> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
>>> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
>>> at hudson.remoting.Request$2.run(Request.java:326)
>>> at 
>>> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
>>> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>>> at 
>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>> at 
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>> at java.lang.Thread.run(Thread.java:662)
>>> Caused by: org.apache.maven.plugin.MojoFail

Re: Jenkins svn ssh / host key verification problems

2013-01-04 Thread Bjørn Water
Hi James,

I have manually removed the entry from the file and then did a SSH command 
again and accepted the certificate.
Still getting the same problems as before.
Is there a way to see if it overrides the entry?
Because it works when I tag it and that is also a commit right?

Thanks,

Bjørn

On Friday, January 4, 2013 3:28:46 PM UTC+1, teilo wrote:
>
> Hi Bjørn
>
>  As the jenkins user on the slave ssh to the svn server and accept its 
> key.
>
>  Depending on your ssh clinet it may override the entry stored in 
> ~/.ssh/known_hosts or may not.  (if not then remove the entry manually 
> from this file and retry with the ssh command)
>
> That should get it working
>
>  /James
>
> On Friday, 4 January 2013 14:19:31 UTC, Bjørn Water wrote:
>>
>> So i am trying to use the M2-release plugin to release my project and 
>> push it to my nexus.
>> I can do svn checkout and i can even tag my build and see it in my repo 
>> but when i try to do mvn release:prepare after a succesfull build i get 
>> an error
>>
>> [ERROR] BUILD FAILURE[INFO] 
>> 
>> [INFO] Unable to commit files
>> Provider message:
>> The svn command failed.
>> Command output:
>> Host key verification failed.
>> svn: Commit failed (details follow):
>> svn: To better debug SSH connection problems, remove the -q option from 
>> 'ssh' in the [tunnels] section of your Subversion configuration file.
>> svn: Network connection closed unexpectedly
>>
>> [INFO] 
>> 
>> [INFO] Trace
>> org.apache.maven.BuildFailureException: Unable to commit files
>> Provider message:
>> The svn command failed.
>> Command output:
>> Host key verification failed.
>> svn: Commit failed (details follow):
>> svn: To better debug SSH connection problems, remove the -q option from 
>> 'ssh' in the [tunnels] section of your Subversion configuration file.
>> svn: Network connection closed unexpectedly
>>
>>  at 
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
>>  at 
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
>>  at 
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
>>  at 
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
>>  at 
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
>>  at 
>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
>>  at 
>> org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
>>  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
>>  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
>>  at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
>>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>  at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>  at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>  at java.lang.reflect.Method.invoke(Method.java:597)
>>  at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>>  at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>>  at hudson.maven.agent.Main.launch(Main.java:185)
>>  at hudson.maven.MavenBuilder.call(MavenBuilder.java:153)
>>  at hudson.maven.Maven2Builder.call(Maven2Builder.java:79)
>>  at hudson.maven.Maven2Builder.call(Maven2Builder.java:55)
>>  at hudson.remoting.UserRequest.perform(UserRequest.java:118)
>>  at hudson.remoting.UserRequest.perform(UserRequest.java:48)
>>  at hudson.remoting.Request$2.run(Request.java:326)
>>  at 
>> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
>>  at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>>  at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>>  at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>  at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>  at java.lang.Thread.run(Thread.java:662)
>> Caused by: org.apache.maven.plugin.MojoFailureException: Unable to commit 
>> files
>> Provider message:
>> The svn command failed.
>> Command output:
>> Host key verification failed.
>> svn: Commit failed (details follow):
>> svn: To better debug SSH connection problems, remove the -q option from 
>> 'ssh' in the [tunnels] section of your Subversion configuration file.
>> svn: Network connection closed unexpectedly
>>
>>  at 
>> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:

How to do paremeterized bbuild through mail comander plugin

2013-01-04 Thread Subodh Konhor
Hi,

I have configured the mail commander plugin but I am unable to trigger 
parameterised build for the build.

Below is the subject that I use

build rel4.0-Patch -p TOBUILD_PATCHES=tcpproxy -p RELEASE=auto -p BUILDNUM=auto 
-p TOBUILD_PACKAGE=cae

Thanks,
Subodh



Re: Jenkins svn ssh / host key verification problems

2013-01-04 Thread teilo
I have completely to opposite experience, native svn+ssh is so much simpler 
than all other options!

The provider also says it only works with http/https so may not even be 
much use (but then again documentation could just be out of date)

On Friday, 4 January 2013 14:32:35 UTC, domi wrote:
>
> We had lots of issues when using the cli subversion client for release 
> builds, therefore we moved to the svnjava provider and have no issues 
> anymore:
> http://code.google.com/a/apache-extras.org/p/maven-scm-provider-svnjava/
> /Domi
>
> On 04.01.2013, at 15:19, Bjørn Water > 
> wrote:
>
> So i am trying to use the M2-release plugin to release my project and push 
> it to my nexus.
> I can do svn checkout and i can even tag my build and see it in my repo 
> but when i try to do mvn release:prepare after a succesfull build i get an 
> error
>
> [ERROR] BUILD FAILURE[INFO] 
> 
> [INFO] Unable to commit files
> Provider message:
> The svn command failed.
> Command output:
> Host key verification failed.
> svn: Commit failed (details follow):
> svn: To better debug SSH connection problems, remove the -q option from 'ssh' 
> in the [tunnels] section of your Subversion configuration file.
> svn: Network connection closed unexpectedly
>
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.BuildFailureException: Unable to commit files
> Provider message:
> The svn command failed.
> Command output:
> Host key verification failed.
> svn: Commit failed (details follow):
> svn: To better debug SSH connection problems, remove the -q option from 'ssh' 
> in the [tunnels] section of your Subversion configuration file.
> svn: Network connection closed unexpectedly
>
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
>   at 
> org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:597)
>   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>   at hudson.maven.agent.Main.launch(Main.java:185)
>   at hudson.maven.MavenBuilder.call(MavenBuilder.java:153)
>   at hudson.maven.Maven2Builder.call(Maven2Builder.java:79)
>   at hudson.maven.Maven2Builder.call(Maven2Builder.java:55)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:118)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:48)
>   at hudson.remoting.Request$2.run(Request.java:326)
>   at 
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
>   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>   at java.lang.Thread.run(Thread.java:662)
> Caused by: org.apache.maven.plugin.MojoFailureException: Unable to commit 
> files
> Provider message:
> The svn command failed.
> Command output:
> Host key verification failed.
> svn: Commit failed (details follow):
> svn: To better debug SSH connection problems, remove the -q option from 'ssh' 
> in the [tunnels] section of your Subversion configuration file.
> svn: Network connection closed unexpectedly
>
>   at 
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:287)
>   at 
> org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:237)
>   at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> 

Re: Jenkins svn ssh / host key verification problems

2013-01-04 Thread domi
We had lots of issues when using the cli subversion client for release builds, 
therefore we moved to the svnjava provider and have no issues anymore:
http://code.google.com/a/apache-extras.org/p/maven-scm-provider-svnjava/
/Domi

On 04.01.2013, at 15:19, Bjørn Water  wrote:

> So i am trying to use the M2-release plugin to release my project and push it 
> to my nexus.
> I can do svn checkout and i can even tag my build and see it in my repo 
> but when i try to do mvn release:prepare after a succesfull build i get an 
> error
> 
> [ERROR] BUILD FAILURE
> [INFO] 
> 
> [INFO] Unable to commit files
> Provider message:
> The svn command failed.
> Command output:
> Host key verification failed.
> svn: Commit failed (details follow):
> svn: To better debug SSH connection problems, remove the -q option from 'ssh' 
> in the [tunnels] section of your Subversion configuration file.
> svn: Network connection closed unexpectedly
> 
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.BuildFailureException: Unable to commit files
> Provider message:
> The svn command failed.
> Command output:
> Host key verification failed.
> svn: Commit failed (details follow):
> svn: To better debug SSH connection problems, remove the -q option from 'ssh' 
> in the [tunnels] section of your Subversion configuration file.
> svn: Network connection closed unexpectedly
> 
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
>   at 
> org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:597)
>   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>   at hudson.maven.agent.Main.launch(Main.java:185)
>   at hudson.maven.MavenBuilder.call(MavenBuilder.java:153)
>   at hudson.maven.Maven2Builder.call(Maven2Builder.java:79)
>   at hudson.maven.Maven2Builder.call(Maven2Builder.java:55)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:118)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:48)
>   at hudson.remoting.Request$2.run(Request.java:326)
>   at 
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
>   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>   at java.lang.Thread.run(Thread.java:662)
> Caused by: org.apache.maven.plugin.MojoFailureException: Unable to commit 
> files
> Provider message:
> The svn command failed.
> Command output:
> Host key verification failed.
> svn: Commit failed (details follow):
> svn: To better debug SSH connection problems, remove the -q option from 'ssh' 
> in the [tunnels] section of your Subversion configuration file.
> svn: Network connection closed unexpectedly
> 
>   at 
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:287)
>   at 
> org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:237)
>   at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
>   at 
> hudson.maven.agent.PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:182)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
>   ... 28 more
> Caused by: org.apache.maven.shared.release.scm.ReleaseScmCommandException

Re: Jenkins svn ssh / host key verification problems

2013-01-04 Thread teilo


Hi Bjørn

 As the jenkins user on the slave ssh to the svn server and accept its key.

 Depending on your ssh clinet it may override the entry stored in 
~/.ssh/known_hosts or may not.  (if not then remove the entry manually from 
this file and retry with the ssh command)

That should get it working

 /James

On Friday, 4 January 2013 14:19:31 UTC, Bjørn Water wrote:
>
> So i am trying to use the M2-release plugin to release my project and push 
> it to my nexus.
> I can do svn checkout and i can even tag my build and see it in my repo 
> but when i try to do mvn release:prepare after a succesfull build i get an 
> error
>
> [ERROR] BUILD FAILURE[INFO] 
> 
> [INFO] Unable to commit files
> Provider message:
> The svn command failed.
> Command output:
> Host key verification failed.
> svn: Commit failed (details follow):
> svn: To better debug SSH connection problems, remove the -q option from 'ssh' 
> in the [tunnels] section of your Subversion configuration file.
> svn: Network connection closed unexpectedly
>
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.BuildFailureException: Unable to commit files
> Provider message:
> The svn command failed.
> Command output:
> Host key verification failed.
> svn: Commit failed (details follow):
> svn: To better debug SSH connection problems, remove the -q option from 'ssh' 
> in the [tunnels] section of your Subversion configuration file.
> svn: Network connection closed unexpectedly
>
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
>   at 
> org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:597)
>   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>   at hudson.maven.agent.Main.launch(Main.java:185)
>   at hudson.maven.MavenBuilder.call(MavenBuilder.java:153)
>   at hudson.maven.Maven2Builder.call(Maven2Builder.java:79)
>   at hudson.maven.Maven2Builder.call(Maven2Builder.java:55)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:118)
>   at hudson.remoting.UserRequest.perform(UserRequest.java:48)
>   at hudson.remoting.Request$2.run(Request.java:326)
>   at 
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
>   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>   at java.lang.Thread.run(Thread.java:662)
> Caused by: org.apache.maven.plugin.MojoFailureException: Unable to commit 
> files
> Provider message:
> The svn command failed.
> Command output:
> Host key verification failed.
> svn: Commit failed (details follow):
> svn: To better debug SSH connection problems, remove the -q option from 'ssh' 
> in the [tunnels] section of your Subversion configuration file.
> svn: Network connection closed unexpectedly
>
>   at 
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:287)
>   at 
> org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:237)
>   at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
>   at 
> hudson.maven.agent.PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:182)
>   at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
>

Jenkins svn ssh / host key verification problems

2013-01-04 Thread Bjørn Water
So i am trying to use the M2-release plugin to release my project and push 
it to my nexus.
I can do svn checkout and i can even tag my build and see it in my repo 
but when i try to do mvn release:prepare after a succesfull build i get an 
error

[ERROR] BUILD FAILURE[INFO] 

[INFO] Unable to commit files
Provider message:
The svn command failed.
Command output:
Host key verification failed.
svn: Commit failed (details follow):
svn: To better debug SSH connection problems, remove the -q option from 'ssh' 
in the [tunnels] section of your Subversion configuration file.
svn: Network connection closed unexpectedly

[INFO] 
[INFO] Trace
org.apache.maven.BuildFailureException: Unable to commit files
Provider message:
The svn command failed.
Command output:
Host key verification failed.
svn: Commit failed (details follow):
svn: To better debug SSH connection problems, remove the -q option from 'ssh' 
in the [tunnels] section of your Subversion configuration file.
svn: Network connection closed unexpectedly

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at 
org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at hudson.maven.agent.Main.launch(Main.java:185)
at hudson.maven.MavenBuilder.call(MavenBuilder.java:153)
at hudson.maven.Maven2Builder.call(Maven2Builder.java:79)
at hudson.maven.Maven2Builder.call(Maven2Builder.java:55)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.apache.maven.plugin.MojoFailureException: Unable to commit files
Provider message:
The svn command failed.
Command output:
Host key verification failed.
svn: Commit failed (details follow):
svn: To better debug SSH connection problems, remove the -q option from 'ssh' 
in the [tunnels] section of your Subversion configuration file.
svn: Network connection closed unexpectedly

at 
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:287)
at 
org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:237)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at 
hudson.maven.agent.PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:182)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 28 more
Caused by: org.apache.maven.shared.release.scm.ReleaseScmCommandException: 
Unable to commit files
Provider message:
The svn command failed.
Command output:
Host key verification failed.
svn: Commit failed (details follow):
svn: To better debug SSH connection problems, remove the -q option from 'ssh' 
in the [tunnels] section of your Subversion configuration file.
svn: Network connection closed unexpectedly

at 
org.apache.maven.shared.release.phase.AbstractScmCo

AW: SCM polling stopped to work

2013-01-04 Thread Knuplesch , Jürgen
Hello,

I have the same challenge.
I use Jenkins 1.480.1
The only thing that helps so far is a Jenkins restart.

It happens now and then, but I can not figure out why.
It seems the complete polling is not working anymore.

Juergen




Von: jenkinsci-users@googlegroups.com [mailto:jenkinsci-users@googlegroups.com] 
Im Auftrag von aldaris
Gesendet: Dienstag, 4. September 2012 09:57
An: jenkinsci-users@googlegroups.com
Betreff: SCM polling stopped to work


Hi,



recently I'm having problems with a Jenkins 1.424.6 deployment, for some reason 
after a while Jenkins stops to poll the SCM (the svn polling log seems to 
contain the last _successful_ check and that's all), also periodic building 
seem to suffer from the same problem. Are you aware of any known issues that 
could cause this problem? Where should I look for possible causes? (in my setup 
I have several slave nodes, but the vast majority of the jobs are being built 
on the master node)



Any help would be appreciated,

Peter


maven property as argument to post install script

2013-01-04 Thread ashutosh.kumar17
I want to invokde a post install shell script with developent environment 
(dev/qa/prod) as argument to it. How can I pass this property to script?



Thanks

Ashutosh


Exception running on slaves

2013-01-04 Thread Jorge Costa
Hi,

I get this exception sometimes in random dumb agents.

[CloneExtTSProjects] $ sscm.exe cc / -d20130104012439:20130104044329 -y+ 
-zA-SeapineEXT8:4900 -bTSProjects -pTSProjects\Construsoft -r
FATAL: Unable to call join. Invalid object ID 
44680java.lang.IllegalStateException 
:
 Unable to call join. Invalid object ID 44680
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:269)
 

at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:256)
 

at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:215)
 

at hudson.remoting.UserRequest.perform(UserRequest.java:118) 

at hudson.remoting.UserRequest.perform(UserRequest.java:48) 

at hudson.remoting.Request$2.run(Request.java:326) 

at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
 

at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at hudson.remoting.Engine$1$1.run(Engine.java:60)
at java.lang.Thread.run(Unknown Source)



Any idea how can i figure out what is going on


Thanks in advance


Jorge Costa



Re: Git question...

2013-01-04 Thread Michaël Pailloncy
Hi,

We've faced with the same problem in our company.

Do you used an automatic installation for git in the global configuration ?

It seems that, the Git plugin uses the first Git installation found in
Jenkins global configuration (see
https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/UserRemoteConfig.java#L73
).
So, If the first git installation found used automatic installation, it
seems that Jenkins doesn't download/install git before doing the
git ls-remote (because your Jenkins master doesn't make any
build), resulting in :
*Failed to connect to repository : Error performing command:  ls-remote -h
gitolite@mygitrepo:/myproject.git HEAD*
*
*
The git executable isn't found here, otherwise we would have :
*Failed to connect to repository : Error performing command: git ls-remote
-h gitolite@mygitrepo:/myproject.git HEAD*

To solve this problem, I have declared a local git installation for the
master (not installed automatically) and set it in first in the global
configuration.

I hope this will help you.

Michaël Pailloncy
*
*


2013/1/4 Jeff 

> Thanks for the tips...I'll try and poke around with it tomorrow.  I'm
> finding Git to be a pain compared to SVNugh...likely loose nut behind
> the keyboard.
>
> My Jenkins server has 4GB of RAM and 2.5 GB is dedicated to tomcat running
> Jenkins but I will triple check the settings as well.  We actually have 2
> Jenkins masters now experiencing the issue that are identically configured
> (cloned VM).  One is running 40 jobs (3 Git, 37 SVN) on 3 slaves (no jobs
> run on master).  The other running only one Git job on the master (no
> slaves).
>
>
>
> On Thu, Jan 3, 2013 at 8:02 PM, Mark Waite  wrote:
>
>> There was a report of the same error message in late November that was
>> due to insufficient memory being available for the Jenkins process.  Refer
>> to
>> http://jenkins.361315.n4.nabble.com/Jenkins-GIT-ls-remote-error-td4646903.htmlfor
>>  more details on it.  I suspect that is not your issue, but it should be
>> easy to check if it is the problem.
>>
>> You could also try configuring a git repository without using gitolite
>> (for instance, use apt-get to install the git server, publish the
>> repository to /var/cache/git/repo_name, touch git-daemon-export-ok in that
>> directory, and then create a job which uses git://yourserver/git/repo_name
>> to checkout.  That idea is suggested in
>> http://stackoverflow.com/questions/12614771/configure-git-repository-in-jenkins.
>>   I don't think that is likely your problem either, but trying the fix may
>> expose the real problem to you.
>>
>> Mark Waite
>>
>>
>>
>>   --
>> *From:* Jeff 
>> *To:* jenkinsci-users@googlegroups.com
>> *Sent:* Thursday, January 3, 2013 5:22 PM
>> *Subject:* Re: Git question...
>>
>> I didn't even realize those options existed...ack!
>>
>> I checked and "Fast remote polling" is NOT set.  I have not set any other
>> options beyond the repo URL.  Did I possibly miss something?
>>
>>
>>
>> On Thu, Jan 3, 2013 at 5:17 PM, Mark Waite  wrote:
>>
>> I thought that I had seen that failure when I enabled "fast remote
>> polling" and had not yet cloned  the git repository.
>>
>> My quick web search did not show that as a bug, so I may be wrong, but it
>> won't hurt to try disabling fast remote polling (it is in the Advanced
>> section of the git plugin settings for your job).  I tried to duplicate the
>> problem myself and was unable to duplicate it, so I'm probably not using
>> exactly the steps you are using.
>>
>> Mark Waite
>>
>>   --
>> *From:* Jeff 
>> *To:* jenkinsci-users@googlegroups.com
>> *Sent:* Thursday, January 3, 2013 1:35 PM
>> *Subject:* Git question...
>>
>> I have some Git projects (internal gitolite repository) that I'm
>> configuring and when I put the git repo URL in, it shows this error below
>> field:
>>
>> *Failed to connect to repository : Error performing command:  ls-remote
>> -h gitolite@mygitrepo:/myproject.git HEAD*
>>
>> If I login as the user that Jenkins is running as (tomcat7 on Ubuntu
>> 12.10) and type the same command, I don't get an error, but I also don't
>> see any output of any kind.
>>
>> If I leave off the "HEAD" option, I get a response like:
>>
>> 6156c0bd163a1b9e3a878e889be53c5b80f48c36refs/heads/master
>>
>> Am I doing something wrong?  If I just save the job, it seems to clone
>> and build just fine but I haven't tried any Maven releases yet so I don't
>> know if that works.
>>
>> I can't see in any logs what the specific error might be.  Thoughts?
>>
>> --
>> Jeff Vincent
>> predato...@gmail.com
>> See my LinkedIn profile at:
>> http://www.linkedin.com/in/rjeffreyvincent
>> I ♥ DropBox  !!
>>
>>
>>
>>
>>
>> --
>> Jeff Vincent
>> predato...@gmail.com
>> See my LinkedIn profile at:
>> http://www.linkedin.com/in/rjeffreyvincent
>> I ♥ DropBox  !!
>>
>>
>>
>
>
> --
> Jeff Vincent
> predato...@gmail.com
>