Re: Start into maintenance mode

2014-02-24 Thread Daniel Beck
That page is incomplete.

Use http://release-notes.cloudbees.com/ for the complete reference (it's the 
"CloudBees Quiet Start Plugin").

On 24.02.2014, at 23:12, Michael Rumpf  wrote:

> http://www.cloudbees.com/jenkins-enterprise-by-cloudbees-available-plugins.cb
> 

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


Re: PR for rubyMetrics plugin

2014-02-24 Thread Mike Dillon
Checking in again. Please let me know there's anything else I can do to
help the process along.

-md
On Feb 18, 2014 11:25 AM, "Mike Dillon"  wrote:

> Hello again-
>
> Just wanted to bump this thread.
>
> It's looking like I'm going to need to merge and release this myself,
> which I'm willing to do.
>
> My username is "md5" on both github.com and jenkins-ci.org.
>
> -md
> On Feb 12, 2014 10:34 AM, "Mike Dillon"  wrote:
>
>> Hi all-
>>
>> I was wondering whether anyone could take a quick look at this PR:
>> https://github.com/jenkinsci/rubymetrics-plugin/pull/14
>>
>> The PR changes the loading of RcovFileResult objects to avoid holding the
>> source code of every file in the coverage report in memory, instead loading
>> the source code only on demand when a request is made to view it.
>>
>> -md
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Jenkins Developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/jenkinsci-dev/pERxDC9Iaho/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> jenkinsci-dev+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>

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


Re: Start into maintenance mode

2014-02-24 Thread Michael Rumpf
I find no trace of it on the Cloudbees page:
http://www.cloudbees.com/jenkins-enterprise-by-cloudbees-available-plugins.cb

However, I will download a trial version and have a look.

Thanks,
 Michael

On Monday, February 24, 2014 11:00:15 PM UTC+1, Jesse Glick wrote:
>
> On Mon, Feb 24, 2014 at 4:23 PM, Michael Rumpf 
> > 
> wrote: 
> > It would be of great benefit to have a flag which starts Jenkins right 
> into 
> > "Prepare for shutdown" mode so that no new builds start running. 
>
> FYI, there is a proprietary plugin in Jenkins Enterprise by CloudBees 
> for this purpose. 
>

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


Re: Start into maintenance mode

2014-02-24 Thread Michael Rumpf
Thanks for the hint, this will definitely be of help for our purpose.

On Monday, February 24, 2014 10:48:45 PM UTC+1, Geoff Cummings wrote:
>
> There are instructions at the following page for getting jenkins to start 
> in maintenance mode:
>
> https://wiki.jenkins-ci.org/display/JENKINS/Post-initialization+script
>
>
> You can create a Groovy script file as $JENKINS_HOME/init.groovy
> With the following contents:
>
>
> import jenkins.model.*;
>
> // start in the state that doesn't do any build.
> Jenkins.instance.doQuietDown();
>
>
>
>
> On a related note, I would like to be able to manually trigger and allow 
> some maintenance jobs to run when Jenkins is in maintenance mode...
>
> Hope this helps,
> Geoff
>
>
>
> On Mon, Feb 24, 2014 at 9:28 PM, Bruno Meneguello 
> 
> > wrote:
>
>> I do agree. Jenkins should stay in the maintenance mode until requested 
>> to cancel by an administrator
>> Em 24/02/2014 18:23, "Michael Rumpf" > 
>> escreveu:
>>
>> Hi,
>>>
>>> the usual way to restart Jenkins for maintenance is to activate "Prepare 
>>> for shutdown", to wait until all running tasks are completed and restart 
>>> Jenkins.
>>> In the past we had many situations where we needed a second restart but 
>>> because Jenkins starts looking for SCM changes right after the start a new 
>>> set of builds are already running.
>>>
>>> It would be of great benefit to have a flag which starts Jenkins right 
>>> into "Prepare for shutdown" mode so that no new builds start running.
>>>
>>> The easiest part would be to look for a certain file, e.g. 
>>> jenkins.maintenance, if that is present, Jenkins goes into maintenance 
>>> mode. When the file is deleted, Jenkins goes back to normal mode.
>>>
>>> How do you think about such a feature?
>>>
>>> Kind regards,
>>>  Michael
>>>
>>>
>>>  -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to jenkinsci-de...@googlegroups.com .
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-de...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

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


Re: Start into maintenance mode

2014-02-24 Thread Jesse Glick
On Mon, Feb 24, 2014 at 4:23 PM, Michael Rumpf  wrote:
> It would be of great benefit to have a flag which starts Jenkins right into
> "Prepare for shutdown" mode so that no new builds start running.

FYI, there is a proprietary plugin in Jenkins Enterprise by CloudBees
for this purpose.

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


Re: Start into maintenance mode

2014-02-24 Thread Geoff Cummings
There are instructions at the following page for getting jenkins to start
in maintenance mode:

https://wiki.jenkins-ci.org/display/JENKINS/Post-initialization+script


You can create a Groovy script file as $JENKINS_HOME/init.groovy
With the following contents:


import jenkins.model.*;

// start in the state that doesn't do any build.
Jenkins.instance.doQuietDown();




On a related note, I would like to be able to manually trigger and allow
some maintenance jobs to run when Jenkins is in maintenance mode...

Hope this helps,
Geoff



On Mon, Feb 24, 2014 at 9:28 PM, Bruno Meneguello wrote:

> I do agree. Jenkins should stay in the maintenance mode until requested to
> cancel by an administrator
> Em 24/02/2014 18:23, "Michael Rumpf"  escreveu:
>
> Hi,
>>
>> the usual way to restart Jenkins for maintenance is to activate "Prepare
>> for shutdown", to wait until all running tasks are completed and restart
>> Jenkins.
>> In the past we had many situations where we needed a second restart but
>> because Jenkins starts looking for SCM changes right after the start a new
>> set of builds are already running.
>>
>> It would be of great benefit to have a flag which starts Jenkins right
>> into "Prepare for shutdown" mode so that no new builds start running.
>>
>> The easiest part would be to look for a certain file, e.g.
>> jenkins.maintenance, if that is present, Jenkins goes into maintenance
>> mode. When the file is deleted, Jenkins goes back to normal mode.
>>
>> How do you think about such a feature?
>>
>> Kind regards,
>>  Michael
>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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


Re: Start into maintenance mode

2014-02-24 Thread Bruno Meneguello
I do agree. Jenkins should stay in the maintenance mode until requested to
cancel by an administrator
Em 24/02/2014 18:23, "Michael Rumpf"  escreveu:

> Hi,
>
> the usual way to restart Jenkins for maintenance is to activate "Prepare
> for shutdown", to wait until all running tasks are completed and restart
> Jenkins.
> In the past we had many situations where we needed a second restart but
> because Jenkins starts looking for SCM changes right after the start a new
> set of builds are already running.
>
> It would be of great benefit to have a flag which starts Jenkins right
> into "Prepare for shutdown" mode so that no new builds start running.
>
> The easiest part would be to look for a certain file, e.g.
> jenkins.maintenance, if that is present, Jenkins goes into maintenance
> mode. When the file is deleted, Jenkins goes back to normal mode.
>
> How do you think about such a feature?
>
> Kind regards,
>  Michael
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>

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


Start into maintenance mode

2014-02-24 Thread Michael Rumpf
Hi,

the usual way to restart Jenkins for maintenance is to activate "Prepare 
for shutdown", to wait until all running tasks are completed and restart 
Jenkins.
In the past we had many situations where we needed a second restart but 
because Jenkins starts looking for SCM changes right after the start a new 
set of builds are already running.

It would be of great benefit to have a flag which starts Jenkins right into 
"Prepare for shutdown" mode so that no new builds start running.

The easiest part would be to look for a certain file, e.g. 
jenkins.maintenance, if that is present, Jenkins goes into maintenance 
mode. When the file is deleted, Jenkins goes back to normal mode.

How do you think about such a feature?

Kind regards,
 Michael


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


Re: Need a help on ViewProperty extension point

2014-02-24 Thread swastb
Bruno thanks again for the reply. The invisibleEntry worked for me very 
well when I added a JobPropertyDescriptor , however the same thing is not 
working for me in ViewPropertyDescriptor. 

Here is my ViewPropertyDescriptor.java

public class ViewProjectProperties extends ViewProperty{

 public final String myID;

@DataBoundConstructor
public ViewProjectProperties(final String myID) {
//store it in a file
}

@Extension
public static class DescriptorImpl extends ViewPropertyDescriptor {

@Override
public String getDisplayName() {
return "My Id";
}

@Override
public boolean isEnabledFor(View view) {
return true;
}   
   
}
public String getMyID() {

return myID;
}

}


the config jelly present in ViewProjectProperties folder



 




Im sure I have have done some stupid mistake. Because this same thing is 
working fine for JobPropertyDescriptor .

On Monday, 24 February 2014 17:27:26 UTC+5:30, Bruno Kühnen Meneguello 
wrote:
>
>  I've used the invisibleEntry 
> here.
>  
> For me it worked very well.
>
> On Mon 24 Feb 2014 03:25:34 AM BRT, swastb wrote:
>
>
> Hi Bruno,
>
> thanks a lot for reply.I tried as you have sugested, but still could 
> not make it as a hidden one. By default the ViewPropertyDescriptor is 
> coming as an checkbox in the view.
>
> On Thursday, 20 February 2014 18:36:11 UTC+5:30, Bruno Kühnen 
> Meneguello wrote:
>
> Hi.
>
> Use a plain 
>
> On Thu 20 Feb 2014 09:13:03 AM BRT, swastb wrote:
> > Hi all,
> >
> > Can someone please help me on this?
> >
> > On Friday, 7 February 2014 10:34:57 UTC+5:30, swastb wrote:
> >
> > Hi All,
> >
> > We want to extend the ViewProperty and add an hidden
> variable as
> > part of View. But by default the variable present in the
> > ViewProperty extension is coming as a checkbox in the view.
> Is it
> > expected behavior? Is there a way to make the variable as
> hidden
> > variable in view screen? we tried with adding
> f:invisibleEntry in
> > the corresonding config.jelly file but it didn't help. is there
> > any other way?
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Jenkins Developers" group.
> > To unsubscribe from this group and stop receiving emails from
> it, send
> > an email to jenkinsci-de...@googlegroups.com .
> > For more options, visit https://groups.google.com/groups/opt_out
> 
> .
>
> -- 
> You received this message because you are subscribed to the Google 
> Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to jenkinsci-de...@googlegroups.com .
> For more options, visit https://groups.google.com/groups/opt_out.
>
> 

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


Re: PermGen issues running `mvn -Plight-test install` with core

2014-02-24 Thread Dominik Bartholdi
Tyler,

as the test cases get forked, you might have to set the values on the surefire 
plugin, e.g.:
http://draptik.wordpress.com/2009/05/22/maven2-heap-overflow-in-junit-test-cases-howto-increase-memory/

regards Domi


On 24.02.2014, at 18:23, R. Tyler Croy  wrote:

> 
> I'm trying to test a dependency change with Jenkins core on FreeBSD running
> OpenJDK 7, and I cannot seem to get the full `install` target to complete
> without hitting PermGen space issues.
> 
> In my cursory Google searching, I changed my invocation to:
> 
>[9:20:39] tyler:jenkins git:(master*) $ MAVEN_OPTS="-Xmx512m 
> -XX:MaxPermSize=512m" mvn -Plight-test install
> 
> 
> Unfortunately even this doesn't fix the issue:
> 
>Failed tests: 
>DefaultConfidentialStoreTest.roundtrip:46 assert (new 
> FilePath(tmp).mode()&0777) == 0700 // should be read only
>||| |  |
>||16804 420false
>|
> /usr/home/tyler/source/github/jenkins/core/target/hudson2699586074721172730tmp
>
> /usr/home/tyler/source/github/jenkins/core/target/hudson2699586074721172730tmp
>TarArchiverTest.permission:77 expected:<33261> but was:<33188>
> 
>Tests in error: 
>ProcessTreeTest.testRemoting » NoSuchElement
>SuiteResultTest.testSuiteResultPersistence:128->parseOne:56 » OutOfMemory 
> Perm...
>SuiteResultTest.testSuiteStdioTrimmingSurefire:211->parseOne:56 » 
> OutOfMemory ...
>SuiteResultTest.testErrorDetails:118->parseOne:56 » OutOfMemory PermGen 
> space
>SuiteResultTest.testParseNestedTestSuites:240->parseSuites:62 » 
> OutOfMemory Pe...
>SuiteResultTest.testSuiteStdioTrimming » OutOfMemory PermGen space
>SuiteResultTest.testErrorInTestInitialization » OutOfMemory PermGen space
>SuiteResultTest.testIssue1233 » OutOfMemory PermGen space
>SuiteResultTest.testIssue1463 » OutOfMemory PermGen space
>SuiteResultTest.testIssue1472 » OutOfMemory PermGen space
>SuiteResultTest.testIssue2874 » OutOfMemory PermGen space
>
> ClassResultTest.testFindCorrespondingResultWhereClassResultNameIsLastInCaseResultName
>  » OutOfMemory
>
> ClassResultTest.testFindCorrespondingResultWhereClassResultNameIsNotSubstring 
> » OutOfMemory
>ClassResultTest.testFindCorrespondingResult » OutOfMemory PermGen space
>TestResultTest.initializationError » OutOfMemory PermGen space
>CaseResultTest.initializationError » OutOfMemory PermGen space
>SearchTest.initializationError » OutOfMemory PermGen space
> 
>Tests run: 3309, Failures: 2, Errors: 17, Skipped: 2
> 
>[INFO] 
> 
>[INFO] Reactor Summary:
>[INFO] 
>[INFO] Jenkins main module ... SUCCESS [3.833s]
>[INFO] Jenkins CLI ... SUCCESS 
> [10.372s]
>[INFO] Jenkins core .. FAILURE 
> [1:08:54.771s]
>[INFO] Jenkins war ... SKIPPED
>[INFO] Test harness for Jenkins and plugins .. SKIPPED
>[INFO] Jenkins plugin POM  SKIPPED
>[INFO] 
> 
>[INFO] BUILD FAILURE
>[INFO] 
> 
>[INFO] Total time: 1:09:13.599s
>[INFO] Finished at: Sun Feb 23 17:24:32 PST 2014
>[INFO] Final Memory: 33M/232M
>[INFO] 
> 
>[ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.16:test (default-test) on 
> project jenkins-core:che.maven.plugins:maven-surefire-plugin:2.16:test 
> failed: The forked VM terminated without saying properly goodbye. VM crash or
>[ERROR] Command was/bin/sh -c cd 
> /usr/home/tyler/source/github/jenkins/core && 
> /usr/local/openjdk7/jre/bin/java 
> -XX:MaxPermSizeb/jenkins/core/target/surefire/surefirebooter629552637286265440.jar
>  
> /usr/home/tyler/source/github/jenkins/core/target/surefire/e/tyler/source/github/jenkins/core/target/surefire/surefire_0990672825413254055tmp
>[ERROR] -> [Help 1]
>[ERROR] 
>[ERROR] To see the full stack trace of the errors, re-run Maven with the 
> -e switch.
>[ERROR] Re-run Maven using the -X switch to enable full debug logging.
>[ERROR] 
>[ERROR] For more information about the errors and possible solutions, 
> please read the following articles:
>[ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
>[ERROR] 
>[ERROR] After correcting the problems, you can resume the build with the 
> command
>[ERROR]   mvn  -rf :jenkins-core
>[8:41:06] tyler:jenkins git:(master*) $
> 
> 
> 
> I'm hoping I'm just not setting the right values correctly, any suggestions? 
> :/
> 
> 
> - R. Tyler 

PermGen issues running `mvn -Plight-test install` with core

2014-02-24 Thread R. Tyler Croy

I'm trying to test a dependency change with Jenkins core on FreeBSD running
OpenJDK 7, and I cannot seem to get the full `install` target to complete
without hitting PermGen space issues.

In my cursory Google searching, I changed my invocation to:

[9:20:39] tyler:jenkins git:(master*) $ MAVEN_OPTS="-Xmx512m 
-XX:MaxPermSize=512m" mvn -Plight-test install


Unfortunately even this doesn't fix the issue:

Failed tests: 
DefaultConfidentialStoreTest.roundtrip:46 assert (new 
FilePath(tmp).mode()&0777) == 0700 // should be read only
||| |  |
||16804 420false
|
/usr/home/tyler/source/github/jenkins/core/target/hudson2699586074721172730tmp

/usr/home/tyler/source/github/jenkins/core/target/hudson2699586074721172730tmp
TarArchiverTest.permission:77 expected:<33261> but was:<33188>

Tests in error: 
ProcessTreeTest.testRemoting » NoSuchElement
SuiteResultTest.testSuiteResultPersistence:128->parseOne:56 » OutOfMemory 
Perm...
SuiteResultTest.testSuiteStdioTrimmingSurefire:211->parseOne:56 » 
OutOfMemory ...
SuiteResultTest.testErrorDetails:118->parseOne:56 » OutOfMemory PermGen 
space
SuiteResultTest.testParseNestedTestSuites:240->parseSuites:62 » 
OutOfMemory Pe...
SuiteResultTest.testSuiteStdioTrimming » OutOfMemory PermGen space
SuiteResultTest.testErrorInTestInitialization » OutOfMemory PermGen space
SuiteResultTest.testIssue1233 » OutOfMemory PermGen space
SuiteResultTest.testIssue1463 » OutOfMemory PermGen space
SuiteResultTest.testIssue1472 » OutOfMemory PermGen space
SuiteResultTest.testIssue2874 » OutOfMemory PermGen space

ClassResultTest.testFindCorrespondingResultWhereClassResultNameIsLastInCaseResultName
 » OutOfMemory

ClassResultTest.testFindCorrespondingResultWhereClassResultNameIsNotSubstring 
» OutOfMemory
ClassResultTest.testFindCorrespondingResult » OutOfMemory PermGen space
TestResultTest.initializationError » OutOfMemory PermGen space
CaseResultTest.initializationError » OutOfMemory PermGen space
SearchTest.initializationError » OutOfMemory PermGen space

Tests run: 3309, Failures: 2, Errors: 17, Skipped: 2

[INFO] 

[INFO] Reactor Summary:
[INFO] 
[INFO] Jenkins main module ... SUCCESS [3.833s]
[INFO] Jenkins CLI ... SUCCESS [10.372s]
[INFO] Jenkins core .. FAILURE 
[1:08:54.771s]
[INFO] Jenkins war ... SKIPPED
[INFO] Test harness for Jenkins and plugins .. SKIPPED
[INFO] Jenkins plugin POM  SKIPPED
[INFO] 

[INFO] BUILD FAILURE
[INFO] 

[INFO] Total time: 1:09:13.599s
[INFO] Finished at: Sun Feb 23 17:24:32 PST 2014
[INFO] Final Memory: 33M/232M
[INFO] 

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.16:test (default-test) on 
project jenkins-core:che.maven.plugins:maven-surefire-plugin:2.16:test failed: 
The forked VM terminated without saying properly goodbye. VM crash or
[ERROR] Command was/bin/sh -c cd /usr/home/tyler/source/github/jenkins/core 
&& /usr/local/openjdk7/jre/bin/java 
-XX:MaxPermSizeb/jenkins/core/target/surefire/surefirebooter629552637286265440.jar
 
/usr/home/tyler/source/github/jenkins/core/target/surefire/e/tyler/source/github/jenkins/core/target/surefire/surefire_0990672825413254055tmp
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, 
please read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the 
command
[ERROR]   mvn  -rf :jenkins-core
[8:41:06] tyler:jenkins git:(master*) $



I'm hoping I'm just not setting the right values correctly, any suggestions? :/


- R. Tyler Croy

--
 Code: 
  Chatter: 

  % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
--


pgpZ8b3hOXEcS.pgp
Description: PGP signature


Random HtmlUnit-related test failures

2014-02-24 Thread Jesse Glick
Recently (the past couple of weeks?) the CI builders on
https://jenkins.ci.cloudbees.com/job/core/ have been giving occasional
test failures in tests which use HtmlUnit (via
HudsonTestCase/JenkinsRule.WebClient). For unknown reasons the root
cause (Throwable.cause) was not being captured in Surefire results, so
I patched the test harness to print it explicitly. Here it is:

java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)
at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)
at 
org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116)
at 
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1413)
at 
org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)
at 
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)
at 
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1098)
at 
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
at 
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
at 
com.gargoylesoftware.htmlunit.HttpWebConnection.getResponse(HttpWebConnection.java:101)
at 
com.gargoylesoftware.htmlunit.WebClient.loadWebResponseFromWebConnection(WebClient.java:1456)
at com.gargoylesoftware.htmlunit.WebClient.loadWebResponse(WebClient.java:1387)
at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:328)
at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:389)
at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:374)
at org.jvnet.hudson.test.HudsonTestCase$WebClient.goTo(HudsonTestCase.java:1820)
at org.jvnet.hudson.test.HudsonTestCase$WebClient.goTo(HudsonTestCase.java:1809)
at 

There is no unusual error output preceding this point, and there is
nothing obviously wrong in the accompanying thread dump:

https://jenkins.ci.cloudbees.com/job/core/job/jenkins-core/223/testReport/jenkins.model/JenkinsTest/testUnprotectedRootAction/

It seems that about one minute elapses from the test Jenkins being up
and running until the test case halts, which makes me think that the
socket read is simply hitting a 60s timeout. But what would cause
that? I would expect there to be some Jetty request handler thread
open and blocked on something.

Anyone have a clue how to go further with diagnosis?

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


Re: overriding Project.upstreamProjects

2014-02-24 Thread Jesse Glick
On Mon, Feb 24, 2014 at 3:00 AM, James Nord (jnord)  wrote:
> No workspace --> no artifacts --> no fingerprints.

Possibly the flow job type needs to be able to record artifacts from
another build that it is referring to somehow.

> // get the latest stable build of project X, project Y and project Z

Since effectively you are doing something with those artifacts here.

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


Re: Git Plugin: detect and build tags from only one specific branch

2014-02-24 Thread Kevin Fleming (BLOOMBERG/ 731 LEXIN)
In Git, tags are in no way associated with branches, so there's no such thing 
as 'tags from a specific branch'. It's possible to analyze all new tags that 
are seen and determine if every commit reachable from a tag is also reachable 
from that specific branch, but this is certainly not something that the Git 
plugin already knows how to do. If the tags in question also don't have any 
consistent naming pattern, then you have no efficient way to find them and 
trigger builds when they appear.

The simplest solution (by far) for this is to have the users who are creating 
the tags put them into a specific namespace in the repository; instead of 
putting them into refs/tags, have them put into refs/tags/for-ci or 
refs/tags/from- or something else. If you do that, it's a simple matter 
to setup the refspec in your Jenkins job to fetch only those tags, and trigger 
builds when new tags appear.

- Original Message -
From: jenkinsci-dev@googlegroups.com
To: jenkinsci-dev@googlegroups.com
At: Feb 23 2014 08:11:20

The proposed solution is to create on local working copy a (pseudo)-branch per 
remote tag, using a custom refspec, then set branch specifier to select them. 
Looks a reasonable solution.
 

2014-02-23 13:55 GMT+01:00 Vlad Aginsky :


Hi all,
 I want to detect and build tags from only one specific branch, and I don't 
know exactly what the tag string will look like.
 Do you know how to configure git plugin for this?
 I read this:
http://erics-notes.blogspot.co.il/2013/05/jenkins-build-latest-git-tag.html
It gives a solution for "automatically build the latest tag in a git 
repository", not limited to specific branch. It can be easily adopted to look 
for tags meeting some regular expression, unfortunately I don't have a reliable 
way to predict what future tags will look like.-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


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

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


Re: Jenkins static analysis on Coverity Scan

2014-02-24 Thread Jesse Glick
On Sun, Feb 23, 2014 at 4:48 PM, Oleg Nenashev  wrote:
> Seems that Coverity has discovered new issues (compared to FindBugs)

I looked through a few dozen examples and saw little it was catching
that FindBugs would not also pick up. Since we have made no serious
effort to address the numerous issues that FB is already warning us
of, I see little point in adding a proprietary tool to the mix, with
the implied overhead of keeping it licensed and running.

FWIW I keep a FindBugs plugin running in my IDE so that its warnings
show up automatically in the editor. This helps me usually keep any
new code I write clean of common FB warnings, and sometimes I will fix
up important-looking violations in code related to things I am
patching. But you hardly need spend much time looking for bugs to fix
in Jenkins; I do not know of anyone consistently triaging incoming
JIRA reports, so picking over minor static analysis warnings seems a
low priority.

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


Re: Need a help on ViewProperty extension point

2014-02-24 Thread Bruno Kühnen Meneguello
I've used the invisibleEntry here 
. 
For me it worked very well.


On Mon 24 Feb 2014 03:25:34 AM BRT, swastb wrote:


Hi Bruno,

thanks a lot for reply.I tried as you have sugested, but still could
not make it as a hidden one. By default the ViewPropertyDescriptor is
coming as an checkbox in the view.

On Thursday, 20 February 2014 18:36:11 UTC+5:30, Bruno Kühnen
Meneguello wrote:

Hi.

Use a plain 

On Thu 20 Feb 2014 09:13:03 AM BRT, swastb wrote:
> Hi all,
>
> Can someone please help me on this?
>
> On Friday, 7 February 2014 10:34:57 UTC+5:30, swastb wrote:
>
> Hi All,
>
> We want to extend the ViewProperty and add an hidden
variable as
> part of View. But by default the variable present in the
> ViewProperty extension is coming as a checkbox in the view.
Is it
> expected behavior? Is there a way to make the variable as
hidden
> variable in view screen? we tried with adding
f:invisibleEntry in
> the corresonding config.jelly file but it didn't help. is there
> any other way?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from
it, send
> an email to jenkinsci-de...@googlegroups.com .
> For more options, visit https://groups.google.com/groups/opt_out
.

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


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


Re: Understanding extension point for plugin

2014-02-24 Thread Fabio Farronato

HI All,
   thanks for all answers.

@oliver I'll look at [2]
Untitled Document
@bruno I need to notify to Polarion the start of a job. I need to manage 
a custom workflow, so I need of a custom plugin.


Thanks again you have been a great help.

__
*Fabio Farronato*
Configuration Management / Architetture, Tecnologie e Quality Management 
/ Project Management e Tecnologie Applicative


Tel:   +39 02 39331 862
Mobile:  +39 335 7404702

*Lombardia Informatica S.p.A.*
Via Taramelli, 26
20124 - Milano - ITALY
www.lispa.it
__
Le informazioni contenute in questo messaggio e ogni documento o file ad 
esso allegato sono riservati e confidenziali. Il loro utilizzo è 
consentito esclusivamente al destinatario del messaggio o a diversa 
persona da questo autorizzata, per le finalità indicate nel messaggio 
medesimo. Qualora Lei non fosse la persona cui il presente messaggio è 
destinato, La invitiamo a eliminarlo dal Suo Sistema e a distruggere le 
varie copie o stampe, dandocene gentilmente comunicazione. Ogni utilizzo 
improprio è contrario ai principi del D.Lgs. 196/03 e alla legislazione 
europea (Direttiva 2002/58/CE). Lombardia Informatica S.p.A. opera in 
conformità al D.Lgs. 196/2003 citato. Per qualsiasi informazione a 
riguardo si prega di contattare la nostra Società al seguente indirizzo 
e-mail: i...@lispa.it


The information contained in this message, as well as any attached 
file(s), is private and confidential and is only intended for the person 
to whom it is addressed. If the reader of this message is not the 
intended recipient or the employee or agent responsible for delivering 
the message to the intended recipient, or you have received this 
communication in error, please be aware that any dissemination, 
distribution or duplication is strictly prohibited, and may be illegal. 
Please notify us immediately and delete all copies from your mailbox and 
other archives. Thank you.


Il 21/02/2014 18:36, oliver gondža ha scritto:

Hi,

If you want to be notified about all started builds see 
RunListener[1], if only for explicitly configured jobs see 
BuildWrapper[2].


[1] 
http://javadoc.jenkins-ci.org/?hudson/model/listeners/RunListener.html

[2] http://javadoc.jenkins-ci.org/?hudson/tasks/BuildWrapper.html



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

RE: overriding Project.upstreamProjects

2014-02-24 Thread James Nord (jnord)
> > there is no workspace and hence no upstream projects.
> 
> Not sure what you mean. Upstream/downstream project relationships have
> nothing to do with workspaces.

No workspace --> no artifacts --> no fingerprints.

> > it (and many other things) seem to be based around the assumption of
> > fingerprints
> 
> Rightly so. Why do you need to fake anything? Just make sure that whatever
> information is passed from build to build is properly fingerprinted, and the
> causal relationship will fall out of that automatically.

But when you don't directly consume artifacts there is nothing to fingerprint.

For example

commit build   --(triggers)-> flow build

flow build is // pseudo code
// get the latest stable build of project X, project Y and project Z
// add them to RunParamters
Build(testA, parameters)
Parallel( build(testB, parameters), build(testC,parameters))

SO the flow runs multiple tests - and should aggregate these results so you 
only need to look at the "Flow" to see the test results - not have to drill 
into each project.

On top of that - there is no point showing all the combined test results if you 
can't tell in the flow what changed from Run X to Run Y without having to drill 
into logs, and then search up and around in Jenkins.

That is I want to be able to look at the "flow build" job and see all tests and 
dependency changes by just looking at the "job/flow_build"  page.


Hope that clarifies what I am attempting to achieve.

/James

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