Re: Parameterized Build and SVN

[Ed Young]

Thanks for the snappy reply.

Works great!

Thanks again.


On Thu, May 29, 2014 at 3:03 PM, Daniel Beck  wrote:

> That parameter is provided by the Subversion plugin.
>
> It simply allows you to select a branch (or tag, or any folder really)
> from Subversion as job argument. It doesn't check it out, that's what
> selecting the Subversion SCM further down in the job config is for. A bit
> like the "Choice Parameter", but with a list initialized from SVN.
>
> What you need do is you rename the parameter to something simpler, like
> "RCBranch". Then you configure Subversion SCM to check out the URL "
> http://evc.io.comcast.net/chimps/branches/$RCBranch";. Use the same
> credentials. If there's a validation error ("$RCBranch" doesn't exist")
> ignore it and/or configure Subversion SCM in global config to validate only
> up to first '$' character. Done.
>
> On 29.05.2014, at 22:22, Ed Young  wrote:
>
> >
> >
> > I'm trying to build a selectable subversion branch. When I select the
> branch from the dropdown, and kick off the build it fails because it hasn't
> actually pulled the code from svn and so the workspace is empty.
> >
> > This seems like the simplest use case, so I don't understand why it
> doesn't work.
> >
> > Jenkins 1.532.1
> >
> >
> > if I check "This build is parameterized" I get options for subversion
> (and other)
> > 
> > ​The plugin correctly displays the branches in the drop down list, but
> when I kick off the build, it fails because nothing is pulled from SVN and
> the workspace is empty.
> >
> > Building in workspace
> /var/lib/jenkins/jobs/chimps-stag-tc-01-deploy/workspace
> >
> > [workspace] $
> /var/lib/jenkins/jobs/chimps-stag-tc-01-deploy/workspace/grailsw "-DChimps
> release candidate branches=3.5.1-S10-RC"
> -Dgrails.work.dir=/var/lib/jenkins/jobs/chimps-stag-tc-01-deploy/workspace//target
> -Dgrails.project.work.dir=target clean --non-interactive --plain-output
> > FATAL: command execution failed
> >
> > java.io.IOException
> > : Cannot run program
> "/var/lib/jenkins/jobs/chimps-stag-tc-01-deploy/workspace/grailsw" (in
> directory "/var/lib/jenkins/jobs/chimps-stag-tc-01-deploy/workspace"):
> error=2, No such file or directory
> >   at
> > java.lang.ProcessBuilder.start(ProcessBuilder.java:1041)
> >
> >   at
> > hudson.Proc$LocalProc.(Proc.java:244)
> >
> >   at
> > hudson.Proc$LocalProc.(Proc.java:216)
> >
> >   at
> > hudson.Launcher$LocalLauncher.launch(Launcher.java:773)
> >
> >   at
> > hudson.Launcher$ProcStarter.start(Launcher.java:353)
> >
> >   at
> > hudson.Launcher$ProcStarter.join(Launcher.java:360)
> >
> >   at
> > com.g2one.hudson.grails.GrailsBuilder.perform(GrailsBuilder.java:266)
> >
> >   at
> > hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
> >
> >   at
> >
> hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:781)
> >
> >   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:562)
> >
> >   at
> > hudson.model.Run.execute(Run.java:1665)
> >
> >   at
> > hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
> >
> >   at
> > hudson.model.ResourceController.execute(ResourceController.java:88)
> >
> >   at
> > hudson.model.Executor.run(Executor.java:246)
> >
> > Caused by:
> > java.io.IOException
> > : error=2, No such file or directory
> >   at java.lang.UNIXProcess.forkAndExec(Native Method)
> >   at java.lang.UNIXProcess.(UNIXProcess.java:135)
> >   at java.lang.ProcessImpl.start(ProcessImpl.java:130)
> >   at java.lang.ProcessBuilder.start(ProcessBuilder.java:1022)
> >   ... 15 more
> > Build step 'Build With Grails' marked build as failure
> >
> >
> > I also have the subversion plugin installed, but I don't believe it's
> necessary since this feature seems to advertise it can pull from SVN.
> >
> > What am I doing wrong?
> >
> >
> >
> >
> >
> > --
> > - Ed
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Jenkins 

Parameterized Build and SVN

[Ed Young]

I'm trying to build a selectable subversion branch. When I select the
branch from the dropdown, and kick off the build it fails because it hasn't
actually pulled the code from svn and so the workspace is empty.

This seems like the simplest use case, so I don't understand why it doesn't
work.

Jenkins 1.532.1


if I check "This build is parameterized" I get options for subversion (and
other)

​The plugin correctly displays the branches in the drop down list, but when
I kick off the build, it fails because nothing is pulled from SVN and the
workspace is empty.

Building in workspace
/var/lib/jenkins/jobs/chimps-stag-tc-01-deploy/workspace[workspace] $
/var/lib/jenkins/jobs/chimps-stag-tc-01-deploy/workspace/grailsw
"-DChimps release candidate branches=3.5.1-S10-RC"
-Dgrails.work.dir=/var/lib/jenkins/jobs/chimps-stag-tc-01-deploy/workspace//target
-Dgrails.project.work.dir=target clean --non-interactive
--plain-output
FATAL: command execution failedjava.io.IOException
:
Cannot run program
"/var/lib/jenkins/jobs/chimps-stag-tc-01-deploy/workspace/grailsw" (in
directory "/var/lib/jenkins/jobs/chimps-stag-tc-01-deploy/workspace"):
error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1041)

at hudson.Proc$LocalProc.(Proc.java:244)

at hudson.Proc$LocalProc.(Proc.java:216)

at hudson.Launcher$LocalLauncher.launch(Launcher.java:773)

at hudson.Launcher$ProcStarter.start(Launcher.java:353)

at hudson.Launcher$ProcStarter.join(Launcher.java:360)

at com.g2one.hudson.grails.GrailsBuilder.perform(GrailsBuilder.java:266)

at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)

at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:781)

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:562)

at hudson.model.Run.execute(Run.java:1665)

at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)

at hudson.model.ResourceController.execute(ResourceController.java:88)

at hudson.model.Executor.run(Executor.java:246)

Caused by: java.io.IOException
:
error=2, No such file or directory
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.(UNIXProcess.java:135)
at java.lang.ProcessImpl.start(ProcessImpl.java:130)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1022)
... 15 more
Build step 'Build With Grails' marked build as failure


I also have the subversion plugin installed, but I don't believe it's
necessary since this feature seems to advertise it can pull from SVN.

What am I doing wrong?





-- 
- Ed

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Resolved: deploy to Spring Insight server?

[Ed Young]

I don't know what made me think that the embedded Tomcat server was Tomcat
7.0, but when I configured Jenkins to deploy to a Tomcat 6.0 server, that
deployment worked just like every other Tomcat 6.0 instance I've ever set
up.

I burned more than a few hours barking up the wrong tree, but in the
meantime I learned how to set up and run hyperic agent and hyperic server
which will likely prove valuable.

On Wed, Sep 26, 2012 at 5:09 AM, Ed Young  wrote:

>
> I'm trying unsuccessfully  to deploy from jenkins to the Spring Insight
> server (embedded tomcat 7)  using the Jenkins Deploy to Container plugin
> https://wiki.jenkins-ci.org/display/JENKINS/Deploy+Plugin
>
> Is this the right plugin or is there another for Spring Insight?
>
> I've used it to deploy successfully to Tomcat 6.0 and to Tomcat 7.0 app
> servers in the past. I believe the embedded tomcat server is a Tomcat 7.0
> instance so I've configured the plugin so it deploys to Tomcat 7.0 and I've
> configured the embedded Tomcat tomcat-users.xml with
> roles="admin-gui,manager-gui,manager-script" as prescribed for Tomcst 7.0.
>
> The app is the ROOT.war app so the context is /.
>
> I've set the tomcat url to http://lite-dev.cable.company.com/manager/htmland 
> to
> http://lite-dev.cable.company.com and to
> http://lite-dev.cable.company.com/ in desperate attempts to have some
> success but so far no luck.
>



-- 
- Ed

Re: deploy to Spring Insight server?

[Ed Young]

I should probably mention that this is Spring Insight version VMware
vFabric tc Runtime 2.7.1.RELEASE/6.0.35.B.RELEASE.

On Wed, Sep 26, 2012 at 5:09 AM, Ed Young  wrote:

>
> I'm trying unsuccessfully  to deploy from jenkins to the Spring Insight
> server (embedded tomcat 7)  using the Jenkins Deploy to Container plugin
> https://wiki.jenkins-ci.org/display/JENKINS/Deploy+Plugin
>
> Is this the right plugin or is there another for Spring Insight?
>
> I've used it to deploy successfully to Tomcat 6.0 and to Tomcat 7.0 app
> servers in the past. I believe the embedded tomcat server is a Tomcat 7.0
> instance so I've configured the plugin so it deploys to Tomcat 7.0 and I've
> configured the embedded Tomcat tomcat-users.xml with
> roles="admin-gui,manager-gui,manager-script" as prescribed for Tomcst 7.0.
>
> The app is the ROOT.war app so the context is /.
>
> I've set the tomcat url to http://lite-dev.cable.company.com/manager/htmland 
> to
> http://lite-dev.cable.company.com and to
> http://lite-dev.cable.company.com/ in desperate attempts to have some
> success but so far no luck.
>



-- 
- Ed

deploy to Spring Insight server?

[Ed Young]

I'm trying unsuccessfully  to deploy from jenkins to the Spring Insight
server (embedded tomcat 7)  using the Jenkins Deploy to Container plugin
https://wiki.jenkins-ci.org/display/JENKINS/Deploy+Plugin

Is this the right plugin or is there another for Spring Insight?

I've used it to deploy successfully to Tomcat 6.0 and to Tomcat 7.0 app
servers in the past. I believe the embedded tomcat server is a Tomcat 7.0
instance so I've configured the plugin so it deploys to Tomcat 7.0 and I've
configured the embedded Tomcat tomcat-users.xml with
roles="admin-gui,manager-gui,manager-script" as prescribed for Tomcst 7.0.

The app is the ROOT.war app so the context is /.

I've set the tomcat url to http://lite-dev.cable.company.com/manager/htmland to
http://lite-dev.cable.company.com and to
http://lite-dev.cable.company.com/in desperate attempts to have some
success but so far no luck.

Re: Will reducing the Max # of builds to keep automatically delete old builds?

[Ed Young]

Excellent. I'd forgotten about the (groovy) console. Thanks!

On Mon, Sep 17, 2012 at 10:12 AM,  wrote:

> FYI, 
>
> You can also force log rotation (i.e. old build purging) to occur for all
> jobs by running this in the script console:
>
> ** **
>
> jenkins.model.Jenkins.instance.items.each { it.logRotate() }
>
> ** **
>
> ** **
>
> *-Chris*
>
> * *
>
> ** **
>
> *From:* jenkinsci-users@googlegroups.com [mailto:
> jenkinsci-users@googlegroups.com] *On Behalf Of *Scott Evans
> *Sent:* Thursday, September 13, 2012 4:34 PM
> *To:* jenkinsci-users@googlegroups.com
> *Subject:* Re: Will reducing the Max # of builds to keep automatically
> delete old builds?
>
> ** **
>
> Ed,
>
> Based on my experience, it will purge old builds (by date or quantity)
> only when a new build of that type completes.  In your case, once you run
> one, it'll should automatically delete the 91 "extra" builds which are no
> longer within the retention policies for that build type.  Note that it
> will keep the last successful build, no matter how many failures you have,
> so it should always keep the most recent successful build, no matter how
> old.
>
> Note that this might not occur properly with multiconfiguration builds, as
> I've seen them not clean up properly, but don't know if that's fixed
> recently or not.
>
> Scott
>
> On Thu, Sep 13, 2012 at 4:03 PM, Ed Young  wrote:
>
> I need to clear out some drive space on our build machine by deleting
> old builds, but manually selecting each one and deleting it is too
> painful.
>
> If I change Max # of builds to keep from 100 to 10, will Jenkins
> automatically delete the 90 that I no longer want, or do I need to
> delete them by hand?
>
> ** **
>



-- 
- Ed

Re: retry build upon failure?

[Ed Young]

I can, but not till tomorrow. Thanks for looking into it with me. -Ed

On Sun, Sep 16, 2012 at 10:29 PM, Mark Waite  wrote:

> I see that you've already submitted Jenkins-15184.  Can you investigate if
> your failure mode is the same failure mode as the one I describe below?
>
> If it is the same, then you can attach this information to the bug report
> (and you can use it as a work around).
>
> If it is not the same, then I can submit a bug report for this problem in
> addition to your problem.
>
> Thanks,
> Mark Waite
>
>   --
> *From:* Mark Waite 
> *To:* "jenkinsci-users@googlegroups.com" 
>
> *Sent:* Sunday, September 16, 2012 10:26 PM
>
> *Subject:* Re: retry build upon failure?
>
> I further simplified my configuration by removing Jenkins and its
> configuration files completely from a test computer, then I installed
> Jenkins 1.466.2, installed the Naginator plugin, and confirmed it was the
> only plugin installed.  I created a new Jenkins job with a shell command
> "exit 1" and set it to retry up to twice on failed builds.
>
> The /var/log/jenkins.log file again included the following stack trace:
>
> Sep 16, 2012 10:15:51 PM hudson.model.Run run
> INFO: Naginator-Retry #1 main build action completed: FAILURE
> Sep 16, 2012 10:15:51 PM hudson.model.Executor run
> SEVERE: Executor threw an exception
> java.lang.NullPointerException
> at
> com.chikli.hudson.plugin.naginator.NaginatorListener.onCompleted(NaginatorListener.java:65)
> at
> com.chikli.hudson.plugin.naginator.NaginatorListener.onCompleted(NaginatorListener.java:20)
> at
> hudson.model.listeners.RunListener.fireCompleted(RunListener.java:178)
> at hudson.model.Run.run(Run.java:1488)
> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
> at
> hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:239)
>
> Looking at the source code, it appears the plugin wants a delay value.  I
> had not set a delay value, since it was optional in the user interface.
>  When I set the delay value to a fixed 2 second delay, then the job retried
> after first failure (and no null pointer exception in the log file).  I was
> able to confirm that it would retry up to 4 times after a failed build.
>
> You might consider setting a delay value to see if that helps your case
> like it helped mine.
>
> You might also consider watching the log file to see if there are any
> further hints in what you're doing.
>
> I'll file the bug report with the results of my investigation.
>
> Mark Waite
>
>   --
> *From:* Mark Waite 
> *To:* "jenkinsci-users@googlegroups.com" 
>
> *Sent:* Sunday, September 16, 2012 10:09 PM
> *Subject:* Re: retry build upon failure?
>
> I think you've found a bug.  At least, my initial experiments seem to
> confirm the same results you reported.
>
> I had never experimented with the Naginator plugin before.  I installed it
> into a Jenkins 1.466.2 installation and created a new free style project
> with a single build step, a shell with the one line command "exit 1" and a
> single post build action, retry failed build.
>
> I configured the retry post build action to rebuild up to two times.
>
> The first time that job ran, the jenkins log file contained the following
> report:
>
> INFO: Failure-Test #1 main build action completed: FAILURE
> Sep 16, 2012 9:56:54 PM hudson.model.Executor run
> SEVERE: Executor threw an exception
> java.lang.NullPointerException
> at
> com.chikli.hudson.plugin.naginator.NaginatorListener.onCompleted(NaginatorListener.java:65)
> at
> com.chikli.hudson.plugin.naginator.NaginatorListener.onCompleted(NaginatorListener.java:20)
> at
> hudson.model.listeners.RunListener.fireCompleted(RunListener.java:178)
> at hudson.model.Run.run(Run.java:1488)
> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
> at
> hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:239)
>
> The job did not retry.
>
> Can you submit a bug against the Naginator plugin?
>
> Thanks,
> Mark Waite
>
>   --
> *From:* Ed Young 
> *To:* jenkinsci-users@googlegroups.com
> *Sent:* Sunday, September 16, 2012 8:56 PM
> *Subject:* Re: retry build upon failure?
>
> Sounds like we have some terminology differences. These are test
> failures, which I consider a failed builds. I've experimented with the
> configuration in many different way

Re: retry build upon failure?

[Ed Young]

done:
https://issues.jenkins-ci.org/browse/JENKINS-15184

I'll do some more investigating, as well.

Thanks,

Ed


On Sun, Sep 16, 2012 at 10:09 PM, Mark Waite  wrote:

> I think you've found a bug.  At least, my initial experiments seem to
> confirm the same results you reported.
>
> I had never experimented with the Naginator plugin before.  I installed it
> into a Jenkins 1.466.2 installation and created a new free style project
> with a single build step, a shell with the one line command "exit 1" and a
> single post build action, retry failed build.
>
> I configured the retry post build action to rebuild up to two times.
>
> The first time that job ran, the jenkins log file contained the following
> report:
>
> INFO: Failure-Test #1 main build action completed: FAILURE
> Sep 16, 2012 9:56:54 PM hudson.model.Executor run
> SEVERE: Executor threw an exception
> java.lang.NullPointerException
> at
> com.chikli.hudson.plugin.naginator.NaginatorListener.onCompleted(NaginatorListener.java:65)
> at
> com.chikli.hudson.plugin.naginator.NaginatorListener.onCompleted(NaginatorListener.java:20)
> at
> hudson.model.listeners.RunListener.fireCompleted(RunListener.java:178)
> at hudson.model.Run.run(Run.java:1488)
> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
> at
> hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:239)
>
> The job did not retry.
>
> Can you submit a bug against the Naginator plugin?
>
> Thanks,
> Mark Waite
>
>   --
> *From:* Ed Young 
> *To:* jenkinsci-users@googlegroups.com
> *Sent:* Sunday, September 16, 2012 8:56 PM
>
> *Subject:* Re: retry build upon failure?
>
> Sounds like we have some terminology differences. These are test
> failures, which I consider a failed builds. I've experimented with the
> configuration in many different ways and it never results in a retry,
> even when I set it to retry after "unstable" builds (test failure I
> guess)
>
> If the build passes all tests, it's a pass and "blue". If it fails any
> tests at all it's "red" which I call a "hard failure", but others may
> not, I reckon. In any case, our policy is that if it fails with test
> failures, it's a failed build.
>
> So I set it to retry upon "unstable" builds and it still does not retry.
>
> These are grails builds, and we're using the spock test framework.
>
> Here's the relevant sections of the build config:
>   
>   
>   false  <-- original setting
>   false
>   
> 1
>   
>   3
> 
>
> 
>
> 
>   
>   true  < retry on unstable
>   false
>   2
> 
>
> -
>
> In no cases does it retry.
>
> Here is the end of an example build that fails due to test failures.
>
> ...
> Running 342 spock tests... 188 of 342
> | Completed 342 spock tests, 3 failed in 865846ms
> | Compiling 1 source files
> | Compiling 1 source files.
> | Compiling 1 source files..
> | Tests FAILED  - view reports in
>
> /opt/comcast/data/jenkins/jobs/chimps-geb-grails-lb-test/workspace/target/test-reports
> Build step 'Build With Grails' marked build as failure
>
> Still didn't retry even after specifying retry after an "unstable" build.
>
>
>
>
> On Sun, Sep 16, 2012 at 2:56 PM, Mark Waite  wrote:
> > When Ed says the build is a"hard failure", I assumed that meant the build
> > status was "Failed" and would be marked red.  However, in parentheses he
> > says "(test failures)".  Typically, test failures mark the build as
> > "unstable", not as "failed".  If the build is unstable, I would not
> expect a
> > "retry on fail" to be invoked, since "unstable" is not "failed".
> >
> > Can you clarify?  Was the build red (failed) or yellow (unstable)?
> >
> > Mark Waite
> >
> > 
> > From: Sami Tikka 
> > To: "jenkinsci-users@googlegroups.com"  >
> > Sent: Sunday, September 16, 2012 11:08 AM
> >
> > Subject: Re: retry build upon failure?
> >
> > Could you post exactly what you see in the console log of the failed
> build?
> > Also, it might help if you could post your job config.xml or put in
> > pastebin/gist so we could take a look.
> >
> > -- Sami
> >
> > Ed Young  kirjoitti 14.9.2012 kello 22.38:
> >
> >> I ins

Re: retry build upon failure?

[Ed Young]

Sounds like we have some terminology differences. These are test
failures, which I consider a failed builds. I've experimented with the
configuration in many different ways and it never results in a retry,
even when I set it to retry after "unstable" builds (test failure I
guess)

If the build passes all tests, it's a pass and "blue". If it fails any
tests at all it's "red" which I call a "hard failure", but others may
not, I reckon. In any case, our policy is that if it fails with test
failures, it's a failed build.

So I set it to retry upon "unstable" builds and it still does not retry.

These are grails builds, and we're using the spock test framework.

Here's the relevant sections of the build config:
  
  
  false   <-- original setting
  false
  
1
  
  3




 
  
  true  < retry on unstable
  false
  2


-

In no cases does it retry.

Here is the end of an example build that fails due to test failures.

...
Running 342 spock tests... 188 of 342
| Completed 342 spock tests, 3 failed in 865846ms
| Compiling 1 source files
| Compiling 1 source files.
| Compiling 1 source files..
| Tests FAILED  - view reports in
/opt/comcast/data/jenkins/jobs/chimps-geb-grails-lb-test/workspace/target/test-reports
Build step 'Build With Grails' marked build as failure

Still didn't retry even after specifying retry after an "unstable" build.




On Sun, Sep 16, 2012 at 2:56 PM, Mark Waite  wrote:
> When Ed says the build is a"hard failure", I assumed that meant the build
> status was "Failed" and would be marked red.  However, in parentheses he
> says "(test failures)".  Typically, test failures mark the build as
> "unstable", not as "failed".  If the build is unstable, I would not expect a
> "retry on fail" to be invoked, since "unstable" is not "failed".
>
> Can you clarify?  Was the build red (failed) or yellow (unstable)?
>
> Mark Waite
>
> 
> From: Sami Tikka 
> To: "jenkinsci-users@googlegroups.com" 
> Sent: Sunday, September 16, 2012 11:08 AM
>
> Subject: Re: retry build upon failure?
>
> Could you post exactly what you see in the console log of the failed build?
> Also, it might help if you could post your job config.xml or put in
> pastebin/gist so we could take a look.
>
> -- Sami
>
> Ed Young  kirjoitti 14.9.2012 kello 22.38:
>
>> I installed the Naginator Plugin (v1.8) because the retry failed build
>> plugin indicated that it was deprecated in favor of the Naginatore
>> plugin.
>>
>> It doesn't seem to be working the way I expect it to however. I
>> configured it to simply
>>
>> Retry build after failure up to 3 times, with all other defaults, but
>> after a failure there is no retry. I configured it for a  fixed delay
>> and it still did not retry.
>>
>> It seems like a very simple configuration and the build is a hard
>> failure (test failures) so I can't tell where I'm going wrong.
>> Using Jenkins 1.436.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Sep 14, 2012 at 5:59 AM, William Soula
>>  wrote:
>>> Or https://wiki.jenkins-ci.org/display/JENKINS/Retry+Failed+Builds+Plugin
>>>
>>>
>>>
>>>
>>>
>>> From: jenkinsci-users@googlegroups.com
>>> [mailto:jenkinsci-users@googlegroups.com] On Behalf Of nicolas de loof
>>> Sent: Friday, September 14, 2012 6:16 AM
>>> To: jenkinsci-users@googlegroups.com
>>> Subject: Re: retry build upon failure?
>>>
>>>
>>>
>>> see http://wiki.jenkins-ci.org/display/JENKINS/Naginator+Plugin
>>>
>>> 2012/9/14 Ed Young 
>>>
>>> Is it possible to retry a build upon a failure? Maybe with a retry count?
>>>
>>>
>>
>>
>>
>> --
>> - Ed
>
>



-- 
- Ed

Re: retry build upon failure?

[Ed Young]

I installed the Naginator Plugin (v1.8) because the retry failed build
plugin indicated that it was deprecated in favor of the Naginatore
plugin.

It doesn't seem to be working the way I expect it to however. I
configured it to simply

Retry build after failure up to 3 times, with all other defaults, but
after a failure there is no retry. I configured it for a  fixed delay
and it still did not retry.

It seems like a very simple configuration and the build is a hard
failure (test failures) so I can't tell where I'm going wrong.
Using Jenkins 1.436.











On Fri, Sep 14, 2012 at 5:59 AM, William Soula
 wrote:
> Or https://wiki.jenkins-ci.org/display/JENKINS/Retry+Failed+Builds+Plugin
>
>
>
>
>
> From: jenkinsci-users@googlegroups.com
> [mailto:jenkinsci-users@googlegroups.com] On Behalf Of nicolas de loof
> Sent: Friday, September 14, 2012 6:16 AM
> To: jenkinsci-users@googlegroups.com
> Subject: Re: retry build upon failure?
>
>
>
> see http://wiki.jenkins-ci.org/display/JENKINS/Naginator+Plugin
>
> 2012/9/14 Ed Young 
>
> Is it possible to retry a build upon a failure? Maybe with a retry count?
>
>



-- 
- Ed

Re: Will reducing the Max # of builds to keep automatically delete old builds?

[Ed Young]

the disk usage plugin is installed and is what I've been using to
determine which projects (mine) are the biggest disk hogs.

One of my builds uses 18 GB of space. The next largest one is 1GB. The
reason it uses so much space is because I want keep 50 old builds
behind so that if I notice that test coverage has dropped, for
example, I can go back and see where that happened. I'm not sure of
any other way to track this kind of thing without keeping a large
number of builds.


On Fri, Sep 14, 2012 at 6:11 AM, Lars Nordin  wrote:
> -Original Message-----
> From: Ed Young
>
> Scott, kicking off the build seems to have  deleted the old builds, although 
> I'm not seeing the diskspace usage go down the way I'm hoping. I have a lot 
> of builds to reconfigure and kick off though so this make some time.
> -Original Message-
>
> You might want to install the disk usage plug-in and it help you find what 
> jobs and builds are consuming the most disk space.
> https://wiki.jenkins-ci.org/display/JENKINS/Disk+Usage+Plugin
>



-- 
- Ed

retry build upon failure?

[Ed Young]

Is it possible to retry a build upon a failure? Maybe with a retry count?

Re: Will reducing the Max # of builds to keep automatically delete old builds?

[Ed Young]

Scott, kicking off the build seems to have  deleted the old builds,
although I'm not seeing the diskspace usage go down the way I'm
hoping. I have a lot of builds to reconfigure and kick off though so
this make some time.

What do you mean by multiconfiguration builds?

On Thu, Sep 13, 2012 at 3:33 PM, Scott Evans  wrote:
> Ed,
>
> Based on my experience, it will purge old builds (by date or quantity) only
> when a new build of that type completes.  In your case, once you run one,
> it'll should automatically delete the 91 "extra" builds which are no longer
> within the retention policies for that build type.  Note that it will keep
> the last successful build, no matter how many failures you have, so it
> should always keep the most recent successful build, no matter how old.
>
> Note that this might not occur properly with multiconfiguration builds, as
> I've seen them not clean up properly, but don't know if that's fixed
> recently or not.
>
> Scott
>
>
> On Thu, Sep 13, 2012 at 4:03 PM, Ed Young  wrote:
>>
>> I need to clear out some drive space on our build machine by deleting
>> old builds, but manually selecting each one and deleting it is too
>> painful.
>>
>> If I change Max # of builds to keep from 100 to 10, will Jenkins
>> automatically delete the 90 that I no longer want, or do I need to
>> delete them by hand?
>
>



-- 
- Ed

Will reducing the Max # of builds to keep automatically delete old builds?

[Ed Young]

I need to clear out some drive space on our build machine by deleting
old builds, but manually selecting each one and deleting it is too
painful.

If I change Max # of builds to keep from 100 to 10, will Jenkins
automatically delete the 90 that I no longer want, or do I need to
delete them by hand?