[JIRA] (JENKINS-13133) "Permission denied" due to wrong file system permissions upon update/checkout.
[ https://issues.jenkins-ci.org/browse/JENKINS-13133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163536#comment-163536 ] Jose Sa commented on JENKINS-13133: --- I also had this problem with subversion plugin v1.39. After a workspace wipeout all files checked out had permissions "-x" (001). After upgrading jenkins to 1.467 and plugin 1.40 now all files have the same permission "-rwxrwxr-x" (775) regardless if they had the property set for execution or not. This however didn't show in all build slaves, only in the master, where i recently changed from java 1.6 to 1.7 and added the flag -d64 in order to use 64-bit data model and allocate more memory for max-heap. After more testing I got to the conclusion that this problem doesn't occur if the flag "-d64" isn't passed to java starting options. > "Permission denied" due to wrong file system permissions upon update/checkout. > -- > > Key: JENKINS-13133 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13133 > Project: Jenkins > Issue Type: Bug > Components: subversion >Affects Versions: current > Environment: Jenkins 1.455 - bunch of plugins > Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) > Java version: 1.6.0_22, vendor: Sun Microsystems Inc. > Default locale: en_US, platform encoding: ISO8859-15 > OS name: "sunos", version: "5.10", arch: "sparc", family: "unix" >Reporter: Myron n/a > Labels: exception, permissions, plugin, subversion > > Currently we are using subversion plugin v1.32 - everything works fine. > But after upgrading to the latest v1.39 we encounter some weird behavior: > Upon SVN update i often see a "permission denied" exception. > (well, update works, but the compiler plugin afterwards reports the > "permission denied") > The updated file has not the (chmod 664) permission as supposed to be, it > only has execute rights (chmod 001)?! > I dunno when this happens or how to get more SVN logging to narrow this down. > Or what changes from .32 to .39 could be the culprit (svnkit upgrade?) > But reverting back to .32 solves this problem immediately -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13378) XML API Logs Too Much Information When Invalid Char is Present
[ https://issues.jenkins-ci.org/browse/JENKINS-13378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163535#comment-163535 ] SCM/JIRA link daemon commented on JENKINS-13378: Code changed in jenkins User: Thomas Van Doren Path: changelog.html http://jenkins-ci.org/commit/jenkins/752a7c7b8bd357f2962c0b361eef465b1fd1c83f Log: [JENKINS-13378] Update changelog.html with fix. > XML API Logs Too Much Information When Invalid Char is Present > -- > > Key: JENKINS-13378 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13378 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current >Reporter: Thomas Van Doren >Assignee: Thomas Van Doren > Labels: api, exception, jenkins > > When an XPath error occurs when calling the /api/xml API, the entire xml > string writer object is included as part of the exception. While this could > be useful in some circumstances, it poses a problem when there is a > significant amount of xml (i.e. tens or hundreds of megabytes). > Recently I saw this in my jenkins installation. One of the chrome extensions > calls "/api/xml?depth=2&xpath=/*/job/lastBuild&wrapper=hudson" to get > information every minute or two. I was seeing 150MB of log data every time > that call was made because there was a stack trace followed by: > Caused by: hudson.util.IOException2: Failed to do XPath/wrapper handling. XML > is as > follows:0... > [150MB of xml] > at hudson.model.Api.doXml(Api.java:142) > ... 63 more > Caused by: org.dom4j.DocumentException: Error on line 2170 of document : An > invalid XML character (Unicode: 0x10) was found in the element content of the > document. Nested exception: An invalid XML character (Unicode: 0x10) was > found in the element content of the document. > at org.dom4j.io.SAXReader.read(SAXReader.java:482) > at org.dom4j.io.SAXReader.read(SAXReader.java:365) > at hudson.model.Api.doXml(Api.java:100) > ... 63 more > Caused by: org.xml.sax.SAXParseException: An invalid XML character (Unicode: > 0x10) was found in the element content of the document. > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195) > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:174) > at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:388) > at > com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1414) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2894) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) > at > com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) > at > com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) > at > com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) > at org.dom4j.io.SAXReader.read(SAXReader.java:465) > ... 65 more > It didn't take very long for the log file to consume all of the available > disk space on the server and thereby halt the jenkins service. > Clearly there is something wrong with the XML document or XPath requests, but > the log file shouldn't cripple my system as a result. > I marked this as Major because it can halt the jenkins service. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13378) XML API Logs Too Much Information When Invalid Char is Present
[ https://issues.jenkins-ci.org/browse/JENKINS-13378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-13378. Resolution: Fixed > XML API Logs Too Much Information When Invalid Char is Present > -- > > Key: JENKINS-13378 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13378 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current >Reporter: Thomas Van Doren >Assignee: Thomas Van Doren > Labels: api, exception, jenkins > > When an XPath error occurs when calling the /api/xml API, the entire xml > string writer object is included as part of the exception. While this could > be useful in some circumstances, it poses a problem when there is a > significant amount of xml (i.e. tens or hundreds of megabytes). > Recently I saw this in my jenkins installation. One of the chrome extensions > calls "/api/xml?depth=2&xpath=/*/job/lastBuild&wrapper=hudson" to get > information every minute or two. I was seeing 150MB of log data every time > that call was made because there was a stack trace followed by: > Caused by: hudson.util.IOException2: Failed to do XPath/wrapper handling. XML > is as > follows:0... > [150MB of xml] > at hudson.model.Api.doXml(Api.java:142) > ... 63 more > Caused by: org.dom4j.DocumentException: Error on line 2170 of document : An > invalid XML character (Unicode: 0x10) was found in the element content of the > document. Nested exception: An invalid XML character (Unicode: 0x10) was > found in the element content of the document. > at org.dom4j.io.SAXReader.read(SAXReader.java:482) > at org.dom4j.io.SAXReader.read(SAXReader.java:365) > at hudson.model.Api.doXml(Api.java:100) > ... 63 more > Caused by: org.xml.sax.SAXParseException: An invalid XML character (Unicode: > 0x10) was found in the element content of the document. > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195) > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:174) > at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:388) > at > com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1414) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2894) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) > at > com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) > at > com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) > at > com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) > at org.dom4j.io.SAXReader.read(SAXReader.java:465) > ... 65 more > It didn't take very long for the log file to consume all of the available > disk space on the server and thereby halt the jenkins service. > Clearly there is something wrong with the XML document or XPath requests, but > the log file shouldn't cripple my system as a result. > I marked this as Major because it can halt the jenkins service. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13378) XML API Logs Too Much Information When Invalid Char is Present
[ https://issues.jenkins-ci.org/browse/JENKINS-13378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163534#comment-163534 ] SCM/JIRA link daemon commented on JENKINS-13378: Code changed in jenkins User: Thomas Van Doren Path: core/src/main/java/hudson/model/Api.java http://jenkins-ci.org/commit/jenkins/e1a1d3f098d938fb9c4690cd283653a91a496ae6 Log: [JENKINS-13378] Add FINER logging of XML when XPath handling fails. > XML API Logs Too Much Information When Invalid Char is Present > -- > > Key: JENKINS-13378 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13378 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current >Reporter: Thomas Van Doren >Assignee: Thomas Van Doren > Labels: api, exception, jenkins > > When an XPath error occurs when calling the /api/xml API, the entire xml > string writer object is included as part of the exception. While this could > be useful in some circumstances, it poses a problem when there is a > significant amount of xml (i.e. tens or hundreds of megabytes). > Recently I saw this in my jenkins installation. One of the chrome extensions > calls "/api/xml?depth=2&xpath=/*/job/lastBuild&wrapper=hudson" to get > information every minute or two. I was seeing 150MB of log data every time > that call was made because there was a stack trace followed by: > Caused by: hudson.util.IOException2: Failed to do XPath/wrapper handling. XML > is as > follows:0... > [150MB of xml] > at hudson.model.Api.doXml(Api.java:142) > ... 63 more > Caused by: org.dom4j.DocumentException: Error on line 2170 of document : An > invalid XML character (Unicode: 0x10) was found in the element content of the > document. Nested exception: An invalid XML character (Unicode: 0x10) was > found in the element content of the document. > at org.dom4j.io.SAXReader.read(SAXReader.java:482) > at org.dom4j.io.SAXReader.read(SAXReader.java:365) > at hudson.model.Api.doXml(Api.java:100) > ... 63 more > Caused by: org.xml.sax.SAXParseException: An invalid XML character (Unicode: > 0x10) was found in the element content of the document. > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195) > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:174) > at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:388) > at > com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1414) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2894) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) > at > com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) > at > com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) > at > com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) > at org.dom4j.io.SAXReader.read(SAXReader.java:465) > ... 65 more > It didn't take very long for the log file to consume all of the available > disk space on the server and thereby halt the jenkins service. > Clearly there is something wrong with the XML document or XPath requests, but > the log file shouldn't cripple my system as a result. > I marked this as Major because it can halt the jenkins service. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13378) XML API Logs Too Much Information When Invalid Char is Present
[ https://issues.jenkins-ci.org/browse/JENKINS-13378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163533#comment-163533 ] SCM/JIRA link daemon commented on JENKINS-13378: Code changed in jenkins User: Thomas Van Doren Path: core/src/main/java/hudson/model/Api.java http://jenkins-ci.org/commit/jenkins/668a0cc4dc786dc1b6a726b17db74e9974afa82a Log: [FIXED JENKINS-13378] Remove XML string writer from IOException2 when XPath error occurs. Remove XML string writer from IOException2 message when XPath error occurs in /api/xml request. The XML string writer has the potential to be very large (many megabytes or even gigabytes) and these exceptions will be logged to the default jenkins logfile by winstone. This has the potential to quickly use all available disk space if, for example, a jenkins poller (i.e. a chrome extension) makes frequent calls to the API that cause errors. > XML API Logs Too Much Information When Invalid Char is Present > -- > > Key: JENKINS-13378 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13378 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current >Reporter: Thomas Van Doren >Assignee: Thomas Van Doren > Labels: api, exception, jenkins > > When an XPath error occurs when calling the /api/xml API, the entire xml > string writer object is included as part of the exception. While this could > be useful in some circumstances, it poses a problem when there is a > significant amount of xml (i.e. tens or hundreds of megabytes). > Recently I saw this in my jenkins installation. One of the chrome extensions > calls "/api/xml?depth=2&xpath=/*/job/lastBuild&wrapper=hudson" to get > information every minute or two. I was seeing 150MB of log data every time > that call was made because there was a stack trace followed by: > Caused by: hudson.util.IOException2: Failed to do XPath/wrapper handling. XML > is as > follows:0... > [150MB of xml] > at hudson.model.Api.doXml(Api.java:142) > ... 63 more > Caused by: org.dom4j.DocumentException: Error on line 2170 of document : An > invalid XML character (Unicode: 0x10) was found in the element content of the > document. Nested exception: An invalid XML character (Unicode: 0x10) was > found in the element content of the document. > at org.dom4j.io.SAXReader.read(SAXReader.java:482) > at org.dom4j.io.SAXReader.read(SAXReader.java:365) > at hudson.model.Api.doXml(Api.java:100) > ... 63 more > Caused by: org.xml.sax.SAXParseException: An invalid XML character (Unicode: > 0x10) was found in the element content of the document. > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195) > at > com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.fatalError(ErrorHandlerWrapper.java:174) > at > com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:388) > at > com.sun.org.apache.xerces.internal.impl.XMLScanner.reportFatalError(XMLScanner.java:1414) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2894) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) > at > com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) > at > com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205) > at > com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522) > at org.dom4j.io.SAXReader.read(SAXReader.java:465) > ... 65 more > It didn't take very long for the log file to consume all of the available > disk space on the server and thereby halt the jenkins service. > Clearly there is something wrong with the XML document or XPath requests, but > the log file shouldn't cripple my system as a result. > I marked this as Major because it can halt the jenkins service. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrat
[JIRA] (JENKINS-12480) Build step that runs multiple jobs in parallel, and blocks until all are complete
[ https://issues.jenkins-ci.org/browse/JENKINS-12480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163532#comment-163532 ] Greg Temchenko commented on JENKINS-12480: -- I've got the same troubles recently. We also use ""Parameterized Trigger" + "Run condition" + "Conditional build step"", but I tried to disable run-condition and conditional-buildstep, but the problem still persists. Jacob, did you try to disable plugins? Also I use 1.464 and I tried to downgrade to 1.460. > Build step that runs multiple jobs in parallel, and blocks until all are > complete > - > > Key: JENKINS-12480 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12480 > Project: Jenkins > Issue Type: Improvement > Components: parameterized-trigger >Reporter: giuliano carlini >Assignee: huybrechts > > We would like to kick off multiple test jobs as build steps, and block > waiting for them all to finish. Currently the execute serially. But we have > lots of available resources to run them, so it would be so nice to run them > in parallel, and get the results in 1 hour, rather than many. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14026) git plugin doesn't support branch name contains slash ("/")
Yi Wen created JENKINS-14026:
Summary: git plugin doesn't support branch name contains slash
("/")
Key: JENKINS-14026
URL: https://issues.jenkins-ci.org/browse/JENKINS-14026
Project: Jenkins
Issue Type: Bug
Components: git
Reporter: Yi Wen
When a branch contains slash (/), if we try to specify such a branch in "Branch
Name" field, it will not be able to fetch such branches. If we leave branch
name as **, the job can fetch branch name containing slash without problem.
I am not a Java person, but this method looks suspicious in Branch.java, just
trying to help debug
private static String strip(String name) {
return name.substring(name.indexOf('/', 5) + 1);
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13742) Field validation does not pass required query parameters when some fields are specified in a nested Describable
[
https://issues.jenkins-ci.org/browse/JENKINS-13742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163531#comment-163531
]
Kohsuke Kawaguchi commented on JENKINS-13742:
-
Thanks for doing the detective work and the patch, and my apologies for
introducing the problem in the first place.
See https://github.com/jenkinsci/jenkins/pull/487 for how we fixed this. More
specifically,
https://github.com/jenkinsci/jenkins/commit/99b11d0df29ba6428a64486a8335a8f55a2c3d27
contains the UI sample for how to use this.
In this case, parameters in CollabNetApp.fromStapler would each need
@RelativePath("connectionFactory")
> Field validation does not pass required query parameters when some fields are
> specified in a nested Describable
> ---
>
> Key: JENKINS-13742
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13742
> Project: Jenkins
> Issue Type: Bug
> Components: collabnet, core, validating-string-parameter
>Affects Versions: current
> Environment: Problem is not environment dependent, but testing was on
> Ubuntu 10.04 using Firefox 11 as client.
>Reporter: John McNally
>Assignee: whsu
> Labels: jenkins
> Attachments: findNearBy.patch
>
>
> The collabnet plugin was updated/modernized a couple years ago to include
> code like the following:
> CNDocumentUploader.java DescriptorImpl
> {code:java}
> /**
> * Form validation for upload path.
> */
> public FormValidation doCheckUploadPath(CollabNetApp app, @QueryParameter
> String project, @QueryParameter String value)
> {code}
> CollabNetApp.java
> {code:java}
> public static CollabNetApp fromStapler(@QueryParameter boolean
> overrideAuth, @QueryParameter String url,
>@QueryParameter String username,
> @QueryParameter String password)
> {code}
> config.jelly
> {code:xml}
>
> ...
>
>
>
> {code}
> ConnectionFactory has url, username, and password properties
> The generated field validation javascript then uses the 'nearBy' function
> when passing query parameters to the checkUploadPath backend in order to find
> values of url, username, and password. However uploadPath has a parent
> element with name 'publisher', while the direct parent of url, username, and
> password is a div has name 'connectionFactory'. 'publisher' is then a
> grandparent of url, username, and password and because of this, the needed
> query parameters are not included.
> One might argue that the collabnet plugin should avoid this design, since it
> does not work, but the changes came from Kohsuke, so attempting find a fix
> which preserves the current design.
> A patch to the findNearBy function in hudson-behavior.js is attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14025) HipChat / Jenkins Plugin not notifying rooms
Jared Griffith created JENKINS-14025: Summary: HipChat / Jenkins Plugin not notifying rooms Key: JENKINS-14025 URL: https://issues.jenkins-ci.org/browse/JENKINS-14025 Project: Jenkins Issue Type: Bug Components: plugin Affects Versions: current Environment: CentOS 6 Reporter: Jared Griffith The HipChat plugin is failing to notify any rooms, and also looks like it's using the old HipChat API. https://wiki.jenkins-ci.org/display/JENKINS/HipChat+Plugin -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13647) Environment variables from EnvInject plugin are not inherited/parsed by batch tasks
[ https://issues.jenkins-ci.org/browse/JENKINS-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gregory Boissinot resolved JENKINS-13647. - Resolution: Fixed > Environment variables from EnvInject plugin are not inherited/parsed by batch > tasks > --- > > Key: JENKINS-13647 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13647 > Project: Jenkins > Issue Type: Bug > Components: batch-task >Affects Versions: current >Reporter: tsondergaard >Assignee: Gregory Boissinot > Attachments: config.xml > > > Environment variables set for a job with the "Prepare an environment for the > run" and not processed/used for batch tasks. This is very similar to bug > JENKINS-5580 reported for batch tasks and the now deprecated setenv plugin -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13742) Field validation does not pass required query parameters when some fields are specified in a nested Describable
[
https://issues.jenkins-ci.org/browse/JENKINS-13742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kohsuke Kawaguchi updated JENKINS-13742:
Description:
The collabnet plugin was updated/modernized a couple years ago to include code
like the following:
CNDocumentUploader.java DescriptorImpl
{code:java}
/**
* Form validation for upload path.
*/
public FormValidation doCheckUploadPath(CollabNetApp app, @QueryParameter
String project, @QueryParameter String value)
{code}
CollabNetApp.java
{code:java}
public static CollabNetApp fromStapler(@QueryParameter boolean
overrideAuth, @QueryParameter String url,
@QueryParameter String username,
@QueryParameter String password)
{code}
config.jelly
{code:xml}
...
{code}
ConnectionFactory has url, username, and password properties
The generated field validation javascript then uses the 'nearBy' function when
passing query parameters to the checkUploadPath backend in order to find values
of url, username, and password. However uploadPath has a parent element with
name 'publisher', while the direct parent of url, username, and password is a
div has name 'connectionFactory'. 'publisher' is then a grandparent of url,
username, and password and because of this, the needed query parameters are not
included.
One might argue that the collabnet plugin should avoid this design, since it
does not work, but the changes came from Kohsuke, so attempting find a fix
which preserves the current design.
A patch to the findNearBy function in hudson-behavior.js is attached.
was:
The collabnet plugin was updated/modernized a couple years ago to include code
like the following:
CNDocumentUploader.java DescriptorImpl
/**
* Form validation for upload path.
*/
public FormValidation doCheckUploadPath(CollabNetApp app, @QueryParameter
String project, @QueryParameter String value)
CollabNetApp.java
public static CollabNetApp fromStapler(@QueryParameter boolean
overrideAuth, @QueryParameter String url,
@QueryParameter String username,
@QueryParameter String password)
config.jelly
...
ConnectionFactory has url, username, and password properties
The generated field validation javascript then uses the 'nearBy' function when
passing query parameters to the checkUploadPath backend in order to find values
of url, username, and password. However uploadPath has a parent element with
name 'publisher', while the direct parent of url, username, and password is a
div has name 'connectionFactory'. 'publisher' is then a grandparent of url,
username, and password and because of this, the needed query parameters are not
included.
One might argue that the collabnet plugin should avoid this design, since it
does not work, but the changes came from Kohsuke, so attempting find a fix
which preserves the current design.
A patch to the findNearBy function in hudson-behavior.js is attached.
> Field validation does not pass required query parameters when some fields are
> specified in a nested Describable
> ---
>
> Key: JENKINS-13742
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13742
> Project: Jenkins
> Issue Type: Bug
> Components: collabnet, core, validating-string-parameter
>Affects Versions: current
> Environment: Problem is not environment dependent, but testing was on
> Ubuntu 10.04 using Firefox 11 as client.
>Reporter: John McNally
>Assignee: whsu
> Labels: jenkins
> Attachments: findNearBy.patch
>
>
> The collabnet plugin was updated/modernized a couple years ago to include
> code like the following:
> CNDocumentUploader.java DescriptorImpl
> {code:java}
> /**
> * Form validation for upload path.
> */
> public FormValidation doCheckUploadPath(CollabNetApp app, @QueryParameter
> String project, @QueryParameter String value)
> {code}
> CollabNetApp.java
> {code:java}
> public static CollabNetApp fromStapler(@QueryParameter boolean
> overrideAuth, @QueryParameter String url,
>@QueryParameter String username,
> @QueryParameter String password)
> {code}
> config.jelly
> {code:xml}
>
> ...
>
>
>
> {code}
> ConnectionFactory has url, username, and password properties
> The generated field validation javascript then uses the 'nearBy' function
> when passing query parameters to the checkUploadPath backend in order to find
> values of url, username, and password. However uploadPath has a parent
> element with name 'publisher', while the direct parent of url, username, and
> password is a div has name 'connectionFactory'. 'publisher' is then a
> grandparent
[JIRA] (JENKINS-13647) Environment variables from EnvInject plugin are not inherited/parsed by batch tasks
[ https://issues.jenkins-ci.org/browse/JENKINS-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163530#comment-163530 ] SCM/JIRA link daemon commented on JENKINS-13647: Code changed in jenkins User: Gregory Boissinot Path: src/main/java/com/sonyericsson/rebuild/RebuildAction.java http://jenkins-ci.org/commit/rebuild-plugin/82498435502a5529998a0859d24ed6a14a53e992 Log: Fix for JENKINS-13647 Rewrite getURL() to fix a NullPointerException > Environment variables from EnvInject plugin are not inherited/parsed by batch > tasks > --- > > Key: JENKINS-13647 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13647 > Project: Jenkins > Issue Type: Bug > Components: batch-task >Affects Versions: current >Reporter: tsondergaard >Assignee: Gregory Boissinot > Attachments: config.xml > > > Environment variables set for a job with the "Prepare an environment for the > run" and not processed/used for batch tasks. This is very similar to bug > JENKINS-5580 reported for batch tasks and the now deprecated setenv plugin -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-8440) subversion plugin incorrectly reports 'no changes' if previous checkout/update fails
[
https://issues.jenkins-ci.org/browse/JENKINS-8440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163529#comment-163529
]
Valerie Wagner commented on JENKINS-8440:
-
We had a random Subversion update fail, and it also reported as no changes
since previous build and continued to build the job without failing. This is
major because we were unaware that the HEAD was having problems because Jenkins
was continuously building an old checkout. Please fix asap.
Jenkins version: 1.464
Subversion plugin: 1.40
Output:
Updating https://our-url.com/trunk
ERROR: Failed to update https://our-url.com/trunk
org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT
/svn/desertowl/!svn/vcc/default failed
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:304)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:289)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:277)
at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:696)
at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:328)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1289)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:837)
at
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:557)
at
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:414)
at
org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:324)
at
org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27)
at
org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11)
at
org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at
org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292)
at
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:315)
at
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:295)
at
org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:391)
at
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:136)
at
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
at hudson.FilePath.act(FilePath.java:839)
at hudson.FilePath.act(FilePath.java:821)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1218)
at
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475)
at hudson.model.Run.run(Run.java:1434)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:239)
Caused by: svn: E175002: REPORT /svn/desertowl/!svn/vcc/default failed
at
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
at
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
... 34 more
no change for https://our-url.com/trunk since the previous build
> subversion plugin incorrectly reports 'no changes' if previous
> checkout/update fails
>
>
> Key: JENKINS-8440
> URL: https://issues.jenkins-ci.org/browse/JENKINS-8440
> Project: Jenkins
> Issue Type: Bug
> Components: subversion
>Affects Versions: current
>Reporter: apostasia
>
> this is what happened:
> in build #x, the update failed because I changed credentials:
> {code}
> ERROR: Failed to update https://xxx
> org.tmatesoft.svn.core.SVNCancelException: svn: No credential to try.
> Authentication failed at
> {code}
> in build #x+1, I updated credentials and the build succeeds. However the
> Subversion plugin reports it as having no changes:
> {code}
> Fetching 'https://xxx' at -1 into 'D:\.hudson
[JIRA] (JENKINS-12176) Unable to delete a job that has a fstrigger
[ https://issues.jenkins-ci.org/browse/JENKINS-12176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163528#comment-163528 ] Jim Searle commented on JENKINS-12176: -- It's a UNIX thing, there is a directory in /proc for each process id, and /proc//fd contains a list of all files opened by that . Sorry, I don't know OSX at all... I was following the instructions here: https://wiki.jenkins-ci.org/display/JENKINS/I'm+getting+too+many+open+files+error Can you see anything in the code where if a job is disabled it might not close the file? > Unable to delete a job that has a fstrigger > --- > > Key: JENKINS-12176 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12176 > Project: Jenkins > Issue Type: Bug > Components: fstrigger >Reporter: Jim Searle >Assignee: Gregory Boissinot > > I have a fstrigger that polls every minute, and most of the time when I try > to delete the job I get an error: > java.io.IOException: Unable to delete /some/path/.nfs018e26ca00236d2f > so I look at that file, and it contains the fstrigger polling log. > If I disable the fstrigger, then I am able to delete the job. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12176) Unable to delete a job that has a fstrigger
[ https://issues.jenkins-ci.org/browse/JENKINS-12176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163527#comment-163527 ] Gregory Boissinot commented on JENKINS-12176: - I am on a MacOSX system. What is /proc? > Unable to delete a job that has a fstrigger > --- > > Key: JENKINS-12176 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12176 > Project: Jenkins > Issue Type: Bug > Components: fstrigger >Reporter: Jim Searle >Assignee: Gregory Boissinot > > I have a fstrigger that polls every minute, and most of the time when I try > to delete the job I get an error: > java.io.IOException: Unable to delete /some/path/.nfs018e26ca00236d2f > so I look at that file, and it contains the fstrigger polling log. > If I disable the fstrigger, then I am able to delete the job. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13967) Xunit don't recognize cppunit report with time execution
[ https://issues.jenkins-ci.org/browse/JENKINS-13967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gregory Boissinot updated JENKINS-13967: Issue Type: New Feature (was: Bug) Priority: Minor (was: Major) > Xunit don't recognize cppunit report with time execution > > > Key: JENKINS-13967 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13967 > Project: Jenkins > Issue Type: New Feature > Components: xunit >Affects Versions: current > Environment: Ubuntu Desktop 12.04 64 bits with Jenkins 1.466 with > tomcat7 (from ubuntu package) > cppunit -1.12.1-4 (from ubuntu package) >Reporter: Nicolas JAN >Assignee: Gregory Boissinot >Priority: Minor > Attachments: cppunit-report.xml > > > Hi, > Since I have added the clocker plugin to my cppunit code(It is a cppunit > plugin which permit to have the time execution, available into the samples of > the cppunit archive), xunit don't reconize the format of the cppunit report. > In fact, jenkins says that : > [xUnit] [INFO] - Starting to record. > [xUnit] [INFO] - Processing CppUnit-1.12.1 (default) > [xUnit] [INFO] - [CppUnit-1.12.1 (default)] - 1 test report file(s) were > found with the pattern 'report/cppunit-report.xml' relative to > '/home/nicolas/jenkins/workspace/ProjectA' for the testing framework > 'CppUnit-1.12.1 (default)'. > [xUnit] [ERROR] - The result file > '/home/nicolas/jenkins/workspace/ProjectA/report/cppunit-report.xml' for the > metric 'CppUnit' is not valid. The result file has been skipped. > [xUnit] [INFO] - Setting the build status to FAILURE > [xUnit] [INFO] - Stopping recording. > Build step 'Publish xUnit test result report' changed build result to FAILURE -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13967) Xunit don't recognize cppunit report with time execution
[ https://issues.jenkins-ci.org/browse/JENKINS-13967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163526#comment-163526 ] Gregory Boissinot commented on JENKINS-13967: - Sure, this is the expected behavior at the moment because for this metric, a value of 0 is hardcoded. The XSL transformation file has to take care of this. Any contributions are welcome. Change to 'New Feature' for now. > Xunit don't recognize cppunit report with time execution > > > Key: JENKINS-13967 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13967 > Project: Jenkins > Issue Type: Bug > Components: xunit >Affects Versions: current > Environment: Ubuntu Desktop 12.04 64 bits with Jenkins 1.466 with > tomcat7 (from ubuntu package) > cppunit -1.12.1-4 (from ubuntu package) >Reporter: Nicolas JAN >Assignee: Gregory Boissinot > Attachments: cppunit-report.xml > > > Hi, > Since I have added the clocker plugin to my cppunit code(It is a cppunit > plugin which permit to have the time execution, available into the samples of > the cppunit archive), xunit don't reconize the format of the cppunit report. > In fact, jenkins says that : > [xUnit] [INFO] - Starting to record. > [xUnit] [INFO] - Processing CppUnit-1.12.1 (default) > [xUnit] [INFO] - [CppUnit-1.12.1 (default)] - 1 test report file(s) were > found with the pattern 'report/cppunit-report.xml' relative to > '/home/nicolas/jenkins/workspace/ProjectA' for the testing framework > 'CppUnit-1.12.1 (default)'. > [xUnit] [ERROR] - The result file > '/home/nicolas/jenkins/workspace/ProjectA/report/cppunit-report.xml' for the > metric 'CppUnit' is not valid. The result file has been skipped. > [xUnit] [INFO] - Setting the build status to FAILURE > [xUnit] [INFO] - Stopping recording. > Build step 'Publish xUnit test result report' changed build result to FAILURE -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13904) EnvInject Plugin: option to replace invalid characters in env var names with underscores
[
https://issues.jenkins-ci.org/browse/JENKINS-13904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gregory Boissinot updated JENKINS-13904:
Component/s: core
(was: envinject)
In my opinion, EnvInject plugin has not to be in charge of this concern.
EnvInject doesn't have to include logic transformation of environment variables.
For now, I change issue component to Jenkins core.
> EnvInject Plugin: option to replace invalid characters in env var names with
> underscores
>
>
> Key: JENKINS-13904
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13904
> Project: Jenkins
> Issue Type: New Feature
> Components: core
>Reporter: Chris Fraser
>Assignee: Gregory Boissinot
> Attachments: application.properties, envinject-with-new-option.jpg,
> injected-environment-variables.jpg
>
>
> I've got a Java properties file (example attached), which I don't have the
> ability to modify, that I'm sourcing via EnvInject and this file contains
> keys which are dot delimited (ex: app.version). EnvInject correctly pulls
> these in as I've verified on the "Injected environment variables" screen, but
> they are unresolvable when trying to use them in the job.
> For instance, when trying to use ${app.version} w/the Git plugin to tag a
> build, I get: "Tag ${app.version}.4 does not exist...", and when I try to use
> it when executing a shell, I get: "${app.version}: bad substitution". Keys
> without dots from this same properties file work just fine... unfortunately I
> need access to the ones w/the dots.
> After doing a bit of research, I understand why this is happening.
> 1st of all, you have posted JIRA issues where kohsuke says that env vars
> w/dots will not be expanded in Jenkins:
> https://issues.jenkins-ci.org/browse/JENKINS-7180
> Then, by doing a quick google search, you'll see that dots in env vars are
> not supported in most shells and people say to just stay away from them.
> With that in mind, I think a great feature to add to the EnvInject plugin
> would be to give users the option to replace the dots (and actually any other
> which are invalid in env var names) that appear in environment variable names
> with an underscore. If you look at this issue that was opened against the
> SharedObjects plugin, you'll see that, "...environment variables from tool
> names replaces a space, a
> dash or a dot to by a underscore."
> https://issues.jenkins-ci.org/browse/JENKINS-13673
> Please see attached properties files and screenshots.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10025) Calling rebuildDependencyGraph() in cycle
[ https://issues.jenkins-ci.org/browse/JENKINS-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163524#comment-163524 ] Timothy Bingaman commented on JENKINS-10025: Hey guys, apologies for not responding sooner. I'm afraid my time to work on this project these days is pretty much nonexistent. Gregory Boissinot has taken over general maintenance (gboissinot). This particular issue is in the old Ivy trigger code as well, which is from before I took over the project a number of years ago. All my effort was focused on creating and maintaining the Ivy project type. I'm not sure how many people are using the trigger vs the project type, but the trigger hasn't been actively maintained for a fair while. That said, it may well be quite a simple fix to resolve this issue, but I'm afraid I'm not going to have time to look into it. -Timo > Calling rebuildDependencyGraph() in cycle > - > > Key: JENKINS-10025 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10025 > Project: Jenkins > Issue Type: Bug > Components: ivy >Reporter: vjuranek >Assignee: abayer >Priority: Blocker > > There probably possible cycle call of rebuildDependencyGraph(), > Ivy calls > Hudson.getInstance().rebuildDependencyGraph(); > which starts following cycle: > getModuleDescriptor() -> recomputeModuleDescriptor() -> setModuleDescriptor() > -> hudson.model.Hudson.rebuildDependencyGraph() > which results into StackOverflowError, for whole exception, see > http://groups.google.com/group/jenkinsci-users/browse_thread/thread/3c6b67b448c98379# -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12176) Unable to delete a job that has a fstrigger
[ https://issues.jenkins-ci.org/browse/JENKINS-12176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163523#comment-163523 ] Jim Searle commented on JENKINS-12176: -- What about: lsof | grep 'trigger-polling-files.log' But that doesn't show anything for me either... But this currently shows 603 lines for me: ls -la /proc/5498/fd | grep trigger-polling-files.log where 5498 is the jenkins process id, and I don't have 603 jobs using fstrigger. I see a duplicates for some jobs. Actually, I was looking at the duplicates, I didn't look at every one, but those that I did look at, the job is disabled! The trigger-polling-files.log says: "The job is not buildable. Activate it to poll again." Hopefully that will help you debug? Sorry my responses are slow, but for some reason jira is not notifying me of comments, so I have to keep checking. > Unable to delete a job that has a fstrigger > --- > > Key: JENKINS-12176 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12176 > Project: Jenkins > Issue Type: Bug > Components: fstrigger >Reporter: Jim Searle >Assignee: Gregory Boissinot > > I have a fstrigger that polls every minute, and most of the time when I try > to delete the job I get an error: > java.io.IOException: Unable to delete /some/path/.nfs018e26ca00236d2f > so I look at that file, and it contains the fstrigger polling log. > If I disable the fstrigger, then I am able to delete the job. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14024) Disable resolving relative to absolute paths
Kevin Neal created JENKINS-14024: Summary: Disable resolving relative to absolute paths Key: JENKINS-14024 URL: https://issues.jenkins-ci.org/browse/JENKINS-14024 Project: Jenkins Issue Type: New Feature Components: analysis-core, warnings Environment: Jenkins 1.412 Static Analysis Utilities 1.41 Warnings 3.16 Reporter: Kevin Neal Assignee: Ulli Hafner Priority: Minor When the Warnings plugin finds warnings, I want to disable any attempt to turn relative paths into absolute paths. It's just takes too much time for my job. We have a workspace with over 100K files in it. The build and tests take about an hour, but I noticed that each build would hang for many minutes after parsing the warnings. The monitoring plugin showed that the build thread was doing directory recursion for most of that time, so I turned off the warnings plugin for a couple jobs. This saved 10-30 minutes off the build time (with between 20 and 100 warnings). This issue is similar to JENKINS-9090. I expect the latest version of the Warnings plugin will reduce the processing time (due to changes for JENKINS-9090). I updated to Warnings 4.5 last night, but each job's Configure page was broken until I reverted back to 3.16 (Static Analysis Utilities did update to 1.41 and still works, but I can't afford to update core at this point in the production cycle). I still search for warnings in a nightly job, since I mostly want to know when somebody has significantly increased the warnings (and be able to see the warning text with relative path). I am highly interested in any changes in number of warnings between continuous builds (along with text for each warning). There is some value in finding the absolute path and having a link from the dashboard, but I prefer to disable it if it takes more than a minute. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14023) System.exit (13) in a groovy script causes Jenkins shutdown
[
https://issues.jenkins-ci.org/browse/JENKINS-14023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
vjuranek resolved JENKINS-14023.
Resolution: Not A Defect
Hi, system groovy scripts (which also is groovy scripts called via CLI) run in
same JVM as Jenkins master, so there's no surprise that System.exit() kills
your Jenkins master - it's expected behavior. Throwing an exception is
definitely better approach how to announce some problem in the script. Closing
as No a bug.
> System.exit (13) in a groovy script causes Jenkins shutdown
> ---
>
> Key: JENKINS-14023
> URL: https://issues.jenkins-ci.org/browse/JENKINS-14023
> Project: Jenkins
> Issue Type: Bug
> Components: groovy
>Affects Versions: current
> Environment: Solaris
>Reporter: pan berecik
>Assignee: vjuranek
>
> I want to return an error from my groovy script and used for it
> System.exit(13).It caused shutdown of jenkins.
> The script was startet using jenkins-cli.
> ...
> if(args.length < 2){
>System.exit(13)
> }
> ...
> Finally I found a workaround and use RuntimeException in my script and the
> job finished as expected as failed. But jenkins cann still continue his work
> :)
> ...
> if(args.length < 2){
> throw new RuntimeException("Mandatory Parameter BRANCH_NAME is missing!
> Operation ist aborted!")
> }
> ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10025) Calling rebuildDependencyGraph() in cycle
[ https://issues.jenkins-ci.org/browse/JENKINS-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] eguess74 updated JENKINS-10025: --- Assignee: abayer (was: Timothy Bingaman) Andrew, I took freedom to reassign it to you hoping that you know somebody who could take a look at the problem described, as it seems that Timothy having no time to deal with it. Thanks in advance! > Calling rebuildDependencyGraph() in cycle > - > > Key: JENKINS-10025 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10025 > Project: Jenkins > Issue Type: Bug > Components: ivy >Reporter: vjuranek >Assignee: abayer >Priority: Blocker > > There probably possible cycle call of rebuildDependencyGraph(), > Ivy calls > Hudson.getInstance().rebuildDependencyGraph(); > which starts following cycle: > getModuleDescriptor() -> recomputeModuleDescriptor() -> setModuleDescriptor() > -> hudson.model.Hudson.rebuildDependencyGraph() > which results into StackOverflowError, for whole exception, see > http://groups.google.com/group/jenkinsci-users/browse_thread/thread/3c6b67b448c98379# -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13967) Xunit don't recognize cppunit report with time execution
[ https://issues.jenkins-ci.org/browse/JENKINS-13967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas JAN reopened JENKINS-13967: --- XUnit parse the XML report without error. But the time execution of tests in xunit are always 0 ms. > Xunit don't recognize cppunit report with time execution > > > Key: JENKINS-13967 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13967 > Project: Jenkins > Issue Type: Bug > Components: xunit >Affects Versions: current > Environment: Ubuntu Desktop 12.04 64 bits with Jenkins 1.466 with > tomcat7 (from ubuntu package) > cppunit -1.12.1-4 (from ubuntu package) >Reporter: Nicolas JAN >Assignee: Gregory Boissinot > Attachments: cppunit-report.xml > > > Hi, > Since I have added the clocker plugin to my cppunit code(It is a cppunit > plugin which permit to have the time execution, available into the samples of > the cppunit archive), xunit don't reconize the format of the cppunit report. > In fact, jenkins says that : > [xUnit] [INFO] - Starting to record. > [xUnit] [INFO] - Processing CppUnit-1.12.1 (default) > [xUnit] [INFO] - [CppUnit-1.12.1 (default)] - 1 test report file(s) were > found with the pattern 'report/cppunit-report.xml' relative to > '/home/nicolas/jenkins/workspace/ProjectA' for the testing framework > 'CppUnit-1.12.1 (default)'. > [xUnit] [ERROR] - The result file > '/home/nicolas/jenkins/workspace/ProjectA/report/cppunit-report.xml' for the > metric 'CppUnit' is not valid. The result file has been skipped. > [xUnit] [INFO] - Setting the build status to FAILURE > [xUnit] [INFO] - Stopping recording. > Build step 'Publish xUnit test result report' changed build result to FAILURE -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12176) Unable to delete a job that has a fstrigger
[ https://issues.jenkins-ci.org/browse/JENKINS-12176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gregory Boissinot updated JENKINS-12176: Component/s: fstrigger (was: xtrigger) > Unable to delete a job that has a fstrigger > --- > > Key: JENKINS-12176 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12176 > Project: Jenkins > Issue Type: Bug > Components: fstrigger >Reporter: Jim Searle >Assignee: Gregory Boissinot > > I have a fstrigger that polls every minute, and most of the time when I try > to delete the job I get an error: > java.io.IOException: Unable to delete /some/path/.nfs018e26ca00236d2f > so I look at that file, and it contains the fstrigger polling log. > If I disable the fstrigger, then I am able to delete the job. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13413) Git icon(git-48x48.png) missing in job page.
[ https://issues.jenkins-ci.org/browse/JENKINS-13413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163519#comment-163519 ] sogabe commented on JENKINS-13413: -- Not released yet. > Git icon(git-48x48.png) missing in job page. > - > > Key: JENKINS-13413 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13413 > Project: Jenkins > Issue Type: Bug > Components: git > Environment: Git Plugin 1.1.17 > Tomcat 7 >Reporter: sogabe >Assignee: sogabe >Priority: Minor > Attachments: git-icon_missing.png > > > After updating to Git Plugin 1.1.17, Git icon is missing in job page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12176) Unable to delete a job that has a fstrigger
[ https://issues.jenkins-ci.org/browse/JENKINS-12176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163518#comment-163518 ] Gregory Boissinot commented on JENKINS-12176: - I'm afraid I can't reproduce. I did in my environment lsof | grep 'trigger-polling-folder.log' and nothing appends. Maybe it occurs for special use cases when there are problems. Do you have other input in order I try to reproduce it? > Unable to delete a job that has a fstrigger > --- > > Key: JENKINS-12176 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12176 > Project: Jenkins > Issue Type: Bug > Components: xtrigger >Reporter: Jim Searle >Assignee: Gregory Boissinot > > I have a fstrigger that polls every minute, and most of the time when I try > to delete the job I get an error: > java.io.IOException: Unable to delete /some/path/.nfs018e26ca00236d2f > so I look at that file, and it contains the fstrigger polling log. > If I disable the fstrigger, then I am able to delete the job. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12176) Unable to delete a job that has a fstrigger
[ https://issues.jenkins-ci.org/browse/JENKINS-12176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163515#comment-163515 ] Jim Searle edited comment on JENKINS-12176 at 6/5/12 7:57 PM: -- The file handles plugin reports that it is coming from xtrigger: #4 $JENKINS_HOM/jobs/$JOB_NAME/trigger-polling-files.log by thread:Jenkins cron thread on Mon Jun 04 17:25:00 PDT 2012 at java.io.FileOutputStream.(FileOutputStream.java:181) at java.io.FileOutputStream.(FileOutputStream.java:131) at hudson.util.StreamTaskListener.(StreamTaskListener.java:97) at hudson.util.StreamTaskListener.(StreamTaskListener.java:90) at org.jenkinsci.lib.xtrigger.AbstractTrigger.run(AbstractTrigger.java:130) at hudson.triggers.Trigger.checkTriggers(Trigger.java:259) at hudson.triggers.Trigger$Cron.doRun(Trigger.java:207) at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:54) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) was (Author: jimsearle): The file handles plugin reports that it is coming from xtrigger: #4 /projects/brcm/bcg/jenkins/jobs/chip-import-cycloneA0-mem-memory_isb/trigger-polling-files.log by thread:Jenkins cron thread on Mon Jun 04 17:25:00 PDT 2012 at java.io.FileOutputStream.(FileOutputStream.java:181) at java.io.FileOutputStream.(FileOutputStream.java:131) at hudson.util.StreamTaskListener.(StreamTaskListener.java:97) at hudson.util.StreamTaskListener.(StreamTaskListener.java:90) at org.jenkinsci.lib.xtrigger.AbstractTrigger.run(AbstractTrigger.java:130) at hudson.triggers.Trigger.checkTriggers(Trigger.java:259) at hudson.triggers.Trigger$Cron.doRun(Trigger.java:207) at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:54) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) > Unable to delete a job that has a fstrigger > --- > > Key: JENKINS-12176 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12176 > Project: Jenkins > Issue Type: Bug > Components: xtrigger >Reporter: Jim Searle >Assignee: Gregory Boissinot > > I have a fstrigger that polls every minute, and most of the time when I try > to delete the job I get an error: > java.io.IOException: Unable to delete /some/path/.nfs018e26ca00236d2f > so I look at that file, and it contains the fstrigger polling log. > If I disable the fstrigger, then I am able to delete the job. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13413) Git icon(git-48x48.png) missing in job page.
[
https://issues.jenkins-ci.org/browse/JENKINS-13413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163517#comment-163517
]
Joe Hansche commented on JENKINS-13413:
---
This appears to still be happening, except now it's duplicating the cacheable
"static//" part:
{code}{code}
The image exists at "{{/static/1d072716/plugin/git/icons/git-48x48.png}}", but
the prefix is being added twice, so it's still a 404.
> Git icon(git-48x48.png) missing in job page.
> -
>
> Key: JENKINS-13413
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13413
> Project: Jenkins
> Issue Type: Bug
> Components: git
> Environment: Git Plugin 1.1.17
> Tomcat 7
>Reporter: sogabe
>Assignee: sogabe
>Priority: Minor
> Attachments: git-icon_missing.png
>
>
> After updating to Git Plugin 1.1.17, Git icon is missing in job page.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13957) Matrix builds disappear after Jenkins upgrade
[ https://issues.jenkins-ci.org/browse/JENKINS-13957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163516#comment-163516 ] Antonios Chalkiopoulos commented on JENKINS-13957: -- Same behaviour on Debian > Matrix builds disappear after Jenkins upgrade > - > > Key: JENKINS-13957 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13957 > Project: Jenkins > Issue Type: Bug > Components: matrix > Environment: Jenkins 1.458, Tomcat 6, Ubuntu 10.4 >Reporter: Johannes Spohr > > I'm currently stuck with Jenkins 1.458, because whenever I upgrade to any > version after that one, most previous matrix builds are no longer accessible. > On every matrix job's page, the configuration table shows all configurations > as "Pending" or "Skipped". When I select a "Skipped" configuration, Jenkins > opens a build that's about 2 months old. All builds before that date are > accessible, but newer ones have vanished. I can't tell which version I used > back then, maybe there was a change in respect to matrix build configurations? > When I select a build node, its build history shows no matrix builds at all, > only matrix parent builds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12176) Unable to delete a job that has a fstrigger
[ https://issues.jenkins-ci.org/browse/JENKINS-12176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Searle updated JENKINS-12176: - Component/s: xtrigger (was: fstrigger) > Unable to delete a job that has a fstrigger > --- > > Key: JENKINS-12176 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12176 > Project: Jenkins > Issue Type: Bug > Components: xtrigger >Reporter: Jim Searle >Assignee: Gregory Boissinot > > I have a fstrigger that polls every minute, and most of the time when I try > to delete the job I get an error: > java.io.IOException: Unable to delete /some/path/.nfs018e26ca00236d2f > so I look at that file, and it contains the fstrigger polling log. > If I disable the fstrigger, then I am able to delete the job. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12176) Unable to delete a job that has a fstrigger
[ https://issues.jenkins-ci.org/browse/JENKINS-12176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Searle reopened JENKINS-12176: -- The file handles plugin reports that it is coming from xtrigger: #4 /projects/brcm/bcg/jenkins/jobs/chip-import-cycloneA0-mem-memory_isb/trigger-polling-files.log by thread:Jenkins cron thread on Mon Jun 04 17:25:00 PDT 2012 at java.io.FileOutputStream.(FileOutputStream.java:181) at java.io.FileOutputStream.(FileOutputStream.java:131) at hudson.util.StreamTaskListener.(StreamTaskListener.java:97) at hudson.util.StreamTaskListener.(StreamTaskListener.java:90) at org.jenkinsci.lib.xtrigger.AbstractTrigger.run(AbstractTrigger.java:130) at hudson.triggers.Trigger.checkTriggers(Trigger.java:259) at hudson.triggers.Trigger$Cron.doRun(Trigger.java:207) at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:54) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) > Unable to delete a job that has a fstrigger > --- > > Key: JENKINS-12176 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12176 > Project: Jenkins > Issue Type: Bug > Components: fstrigger >Reporter: Jim Searle >Assignee: Gregory Boissinot > > I have a fstrigger that polls every minute, and most of the time when I try > to delete the job I get an error: > java.io.IOException: Unable to delete /some/path/.nfs018e26ca00236d2f > so I look at that file, and it contains the fstrigger polling log. > If I disable the fstrigger, then I am able to delete the job. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13970) Build variable CC_BASELINE not populated with used baseline
[
https://issues.jenkins-ci.org/browse/JENKINS-13970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163513#comment-163513
]
Christian Wolfgang commented on JENKINS-13970:
--
I have identified the problem. I will try to solve it tomorrow.
Are you still experiencing the environment variable not be populated correctly?
> Build variable CC_BASELINE not populated with used baseline
> ---
>
> Key: JENKINS-13970
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13970
> Project: Jenkins
> Issue Type: Bug
> Components: clearcase-ucm
>Affects Versions: current
> Environment: Microsoft Windows Server 2003, Standard x64 Edition,
> Service Pack 2
>Reporter: Tim Pillsbury
>Assignee: Christian Wolfgang
> Labels: clearcase, clearcase-ucm
>
> CCUCM says it is using the latest baseline, but the CC_BASELINE build
> variable is not always set to it.
> The problem seems to occur after "Updating view using all modules" if CCUCM
> finds activities and versions involved.
> {panel:title=Console Output|titleBGColor=#E7D6C1|bgColor=#CE}
> [CCUCM] Retrieved 28 baselines:
> [CCUCM] + WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 11:26:15 EDT 2012)
> [CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 15:18:01 EDT
> 2012)
> [CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_19_12_CLR(Sat May 19 17:14:54 EDT
> 2012)
> [CCUCM] ...
> [CCUCM] + _*WRKB_RLS_2012_06_00_ECM_jenkins_0529_0925(Tue May 29 09:25:52 EDT
> 2012)*_(n)
> [CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_29_12_CLR(Tue May 29 14:22:09 EDT
> 2012)
> [CCUCM] + WRKB_RLS_2012_06_00_ECM_5_29_12.1(Tue May 29 15:12:08 EDT 2012)
> [CCUCM] *Using* *baseline:WRKB_RLS_2012_06_00_ECM_5_29_12.1@\WRKB_PVOB*(y)
> [CCUCM] View root: E:\Jenkins\jobs\Workbench Build 2012 June All except
> CPF\workspace\view
> [CCUCM] View tag : CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC
> [CCUCM] Reusing view root
> [CCUCM] Determine if view tag exists
> [CCUCM] Reusing view tag
> [CCUCM] UUID resulted in
> CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC
> [CCUCM] Getting snapshotview
> [CCUCM] Rebasing development stream
> (CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC) against parent
> stream (WRKB_RLS_2012_06_00_ECM) Done
> [CCUCM] Updating view using all modules
> [CCUCM] _*Found 3 activities. 20 versions involved*_(i)
> {panel}
> But then Injected environment variable CC_BASELINE is incorrect
> {panel:title=Injected environment
> variables|titleBGColor=#E7D6C1|bgColor=#CE}
> |CC_BASELINE|_*baseline:WRKB_RLS_2012_06_00_ECM_jenkins_0529_0925@\WRKB_PVOB*_|(n)|
> {panel}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13970) Build variable CC_BASELINE not populated with used baseline
[
https://issues.jenkins-ci.org/browse/JENKINS-13970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163514#comment-163514
]
Christian Wolfgang commented on JENKINS-13970:
--
Are you still experiencing the environment variable not being populated
correctly?
> Build variable CC_BASELINE not populated with used baseline
> ---
>
> Key: JENKINS-13970
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13970
> Project: Jenkins
> Issue Type: Bug
> Components: clearcase-ucm
>Affects Versions: current
> Environment: Microsoft Windows Server 2003, Standard x64 Edition,
> Service Pack 2
>Reporter: Tim Pillsbury
>Assignee: Christian Wolfgang
> Labels: clearcase, clearcase-ucm
>
> CCUCM says it is using the latest baseline, but the CC_BASELINE build
> variable is not always set to it.
> The problem seems to occur after "Updating view using all modules" if CCUCM
> finds activities and versions involved.
> {panel:title=Console Output|titleBGColor=#E7D6C1|bgColor=#CE}
> [CCUCM] Retrieved 28 baselines:
> [CCUCM] + WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 11:26:15 EDT 2012)
> [CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 15:18:01 EDT
> 2012)
> [CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_19_12_CLR(Sat May 19 17:14:54 EDT
> 2012)
> [CCUCM] ...
> [CCUCM] + _*WRKB_RLS_2012_06_00_ECM_jenkins_0529_0925(Tue May 29 09:25:52 EDT
> 2012)*_(n)
> [CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_29_12_CLR(Tue May 29 14:22:09 EDT
> 2012)
> [CCUCM] + WRKB_RLS_2012_06_00_ECM_5_29_12.1(Tue May 29 15:12:08 EDT 2012)
> [CCUCM] *Using* *baseline:WRKB_RLS_2012_06_00_ECM_5_29_12.1@\WRKB_PVOB*(y)
> [CCUCM] View root: E:\Jenkins\jobs\Workbench Build 2012 June All except
> CPF\workspace\view
> [CCUCM] View tag : CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC
> [CCUCM] Reusing view root
> [CCUCM] Determine if view tag exists
> [CCUCM] Reusing view tag
> [CCUCM] UUID resulted in
> CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC
> [CCUCM] Getting snapshotview
> [CCUCM] Rebasing development stream
> (CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC) against parent
> stream (WRKB_RLS_2012_06_00_ECM) Done
> [CCUCM] Updating view using all modules
> [CCUCM] _*Found 3 activities. 20 versions involved*_(i)
> {panel}
> But then Injected environment variable CC_BASELINE is incorrect
> {panel:title=Injected environment
> variables|titleBGColor=#E7D6C1|bgColor=#CE}
> |CC_BASELINE|_*baseline:WRKB_RLS_2012_06_00_ECM_jenkins_0529_0925@\WRKB_PVOB*_|(n)|
> {panel}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13241) Artifact archiving from remote slave fails
[ https://issues.jenkins-ci.org/browse/JENKINS-13241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Walker reopened JENKINS-13241: -- HP and AIX platforms fail to archive artifacts (even though they claim SUCCESS) This has been broken for months - I created a job to monitor this bug on March 25. > Artifact archiving from remote slave fails > -- > > Key: JENKINS-13241 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13241 > Project: Jenkins > Issue Type: Bug > Components: core >Reporter: Vyacheslav Karpukhin > > Since 1.456 jenkins stopped archiving artifacts from remote slave. This > affects both 1.456 and 1.457, works correctly with 1.455. > ERROR: Failed to archive artifacts: build/Release/*.app/**/* > hudson.util.IOException2: hudson.util.IOException2: Failed to extract > /var/jenkins/workspace/NGB_Queues/build/Release/*.app/**/* > at hudson.FilePath.readFromTar(FilePath.java:1817) > at hudson.FilePath.copyRecursiveTo(FilePath.java:1729) > at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) > at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656) > at hudson.model.Build$RunnerImpl.post2(Build.java:162) > at > hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625) > at hudson.model.Run.run(Run.java:1435) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:238) > Caused by: java.io.IOException: Failed to chmod > /mnt/storage/.jenkins/jobs/NGB_Queues/builds/2012-03-27_03-11-27/archive/build/Release/NGB > > Queues.app/Contents/Frameworks/BWToolkitFramework.framework/BWToolkitFramework > : No such file or directory > at hudson.FilePath._chmod(FilePath.java:1248) > at hudson.FilePath.readFromTar(FilePath.java:1813) > ... 12 more > at hudson.FilePath.copyRecursiveTo(FilePath.java:1736) > at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) > at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656) > at hudson.model.Build$RunnerImpl.post2(Build.java:162) > at > hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625) > at hudson.model.Run.run(Run.java:1435) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:238) > Caused by: java.util.concurrent.ExecutionException: java.io.IOException: Pipe > is already closed > at hudson.remoting.Channel$2.adapt(Channel.java:714) > at hudson.remoting.Channel$2.adapt(Channel.java:709) > at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59) > at hudson.FilePath.copyRecursiveTo(FilePath.java:1732) > ... 11 more > Caused by: java.io.IOException: Pipe is already closed > at hudson.remoting.PipeWindow.checkDeath(PipeWindow.java:83) > at hudson.remoting.PipeWindow$Real.get(PipeWindow.java:171) > at hudson.remoting.ProxyOutputStream._write(ProxyOutputStream.java:118) > at hudson.remoting.ProxyOutputStream.write(ProxyOutputStream.java:103) > at > java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65) > at java.io.BufferedOutputStream.write(BufferedOutputStream.java:109) > at > java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:161) > at > java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:118) > at java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java:72) > at java.io.BufferedOutputStream.write(BufferedOutputStream.java:105) > at org.apache.tools.tar.TarBuffer.writeBlock(TarBuffer.java:410) > at org.apache.tools.tar.TarBuffer.writeRecord(TarBuffer.java:351) > at > hudson.org.apache.tools.tar.TarOutputStream.writeEOFRecord(TarOutputStream.java:356) > at > hudson.org.apache.tools.tar.TarOutputStream.finish(TarOutputStream.java:137) > at > hudson.org.apache.tools.tar.TarOutputStream.close(TarOutputStream.java:149) > at hudson.util.io.TarArchiver.clos
[JIRA] (JENKINS-13241) Artifact archiving from remote slave fails
[ https://issues.jenkins-ci.org/browse/JENKINS-13241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163511#comment-163511 ] Richard Walker commented on JENKINS-13241: -- This is not fixed, as of Jenkins 1.466. HP (risc) and AIX (5.3) are still broken. I've been monitoring this for many weeks now. 08:00:29 Deleting project workspace... done 08:00:29 08:00:31 [pkg_hprisc64] $ /bin/sh -xe /var/tmp/hudson404729494805962.sh 08:00:31 + 1> env.txt 08:00:31 + tar cf test-pkg_hprisc64.tar env.txt 08:00:31 + gzip test-pkg_hprisc64.tar 08:00:32 Archiving artifacts 08:01:05 ERROR: Failed to archive artifacts: test-* 08:01:05 hudson.util.IOException2: java.lang.UnsupportedOperationException 08:01:05at hudson.FilePath.copyRecursiveTo(FilePath.java:1768) 08:01:05at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) 08:01:05at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) 08:01:05at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710) 08:01:05at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:685) 08:01:05at hudson.model.Build$RunnerImpl.post2(Build.java:162) 08:01:05at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:632) 08:01:05at hudson.model.Run.run(Run.java:1463) 08:01:05at hudson.matrix.MatrixRun.run(MatrixRun.java:146) 08:01:05at hudson.model.ResourceController.execute(ResourceController.java:88) 08:01:05at hudson.model.Executor.run(Executor.java:239) 08:01:05 Caused by: java.util.concurrent.ExecutionException: java.lang.UnsupportedOperationException 08:01:05at hudson.remoting.Channel$3.adapt(Channel.java:679) 08:01:05at hudson.remoting.Channel$3.adapt(Channel.java:674) 08:01:05at hudson.remoting.FutureAdapter.get(FutureAdapter.java:55) 08:01:05at hudson.FilePath.copyRecursiveTo(FilePath.java:1766) 08:01:05... 10 more 08:01:05 Caused by: java.lang.UnsupportedOperationException 08:01:05at hudson.os.PosixAPI$1.getCurrentWorkingDirectory(PosixAPI.java:59) 08:01:05at org.jruby.ext.posix.util.ExecIt.run(ExecIt.java:59) 08:01:05at org.jruby.ext.posix.util.ExecIt.runAndWait(ExecIt.java:51) 08:01:05at org.jruby.ext.posix.JavaLibCHelper.readlink(JavaLibCHelper.java:196) 08:01:05at org.jruby.ext.posix.JavaPOSIX.readlink(JavaPOSIX.java:160) 08:01:05at hudson.Util.resolveSymlink(Util.java:1067) 08:01:05at hudson.Util.resolveSymlink(Util.java:1030) 08:01:05at hudson.util.DirScanner$Glob.scan(DirScanner.java:115) 08:01:05at hudson.FilePath.writeToTar(FilePath.java:1804) 08:01:05at hudson.FilePath.access$1000(FilePath.java:166) 08:01:05at hudson.FilePath$36.invoke(FilePath.java:1745) 08:01:05at hudson.FilePath$36.invoke(FilePath.java:1742) 08:01:05at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2177) 08:01:05at hudson.remoting.UserRequest.perform(UserRequest.java:118) 08:01:05at hudson.remoting.UserRequest.perform(UserRequest.java:48) 08:01:05at hudson.remoting.Request$2.run(Request.java:287) 08:01:05at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) 08:01:05at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) 08:01:05at java.util.concurrent.FutureTask.run(FutureTask.java:123) 08:01:05at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651) 08:01:05at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676) 08:01:05at java.lang.Thread.run(Thread.java:637) 08:01:05 Finished: SUCCESS > Artifact archiving from remote slave fails > -- > > Key: JENKINS-13241 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13241 > Project: Jenkins > Issue Type: Bug > Components: core >Reporter: Vyacheslav Karpukhin > > Since 1.456 jenkins stopped archiving artifacts from remote slave. This > affects both 1.456 and 1.457, works correctly with 1.455. > ERROR: Failed to archive artifacts: build/Release/*.app/**/* > hudson.util.IOException2: hudson.util.IOException2: Failed to extract > /var/jenkins/workspace/NGB_Queues/build/Release/*.app/**/* > at hudson.FilePath.readFromTar(FilePath.java:1817) > at hudson.FilePath.copyRecursiveTo(FilePath.java:1729) > at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) > at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(Abst
[JIRA] (JENKINS-14023) System.exit (13) in a groovy script causes Jenkins shutdown
pan berecik created JENKINS-14023:
-
Summary: System.exit (13) in a groovy script causes Jenkins
shutdown
Key: JENKINS-14023
URL: https://issues.jenkins-ci.org/browse/JENKINS-14023
Project: Jenkins
Issue Type: Bug
Components: groovy
Affects Versions: current
Environment: Solaris
Reporter: pan berecik
Assignee: vjuranek
I want to return an error from my groovy script and used for it
System.exit(13).It caused shutdown of jenkins.
The script was startet using jenkins-cli.
...
if(args.length < 2){
System.exit(13)
}
...
Finally I found a workaround and use RuntimeException in my script and the job
finished as expected as failed. But jenkins cann still continue his work :)
...
if(args.length < 2){
throw new RuntimeException("Mandatory Parameter BRANCH_NAME is missing!
Operation ist aborted!")
}
...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12251) Maven3 with 'builds' directory in a separate location tries to create folders with colons in the module name which is not allowed on windows.
[
https://issues.jenkins-ci.org/browse/JENKINS-12251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163510#comment-163510
]
jean-baptiste renaux commented on JENKINS-12251:
Hi,
I also have this problem on Windows 7 with Jenkins 1.466.
Is there a solution or any way to bypass it ?
Thanks
> Maven3 with 'builds' directory in a separate location tries to create folders
> with colons in the module name which is not allowed on windows.
> -
>
> Key: JENKINS-12251
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12251
> Project: Jenkins
> Issue Type: Bug
> Components: core
>Affects Versions: current
> Environment: Windows Server 2008 R2 64bit
> Java 1.6.0_26
> Winstone (windows install)
> Jenkins 1.444
>Reporter: Samuel Webber
> Labels: build, exception, jenkins, maven, windows
>
> We are using Jenkins on windows and set our workspaces and builds to be a
> separate directory to the standard jenkins install directory on windows.
> This all works fine for our ant builds with our build artefacts stored in
> U:\jenkins\builds
> However we have recently added some maven3 builds.
> These work fine if you have the Build Record Root Directory set to the
> default as: ${ITEM_ROOTDIR}/builds
> And the build folders exists as: C:\Program Files (x86)\Jenkins\jobs\ name>\modules\$
> However changing the Build Record Root Directory to
> u:/jenkins/builds/${ITEM_FULLNAME} it then tries to create the directory with
> a colon rather than a dollar in the directory name, this fails on windows.
> e.g.
> u:\jenkins\builds\\:
> I can confirm running jenkins on linux the same occurs, however the colon is
> not a problem (as its an allowed character).
> Started by user Sam Webber
> Building on master
> Updating
> http://svnserver/svn/ss/platform/branches/wc/wc_maven_migration/core/ss-core
> At revision 181408
> no revision recorded for
> http://svnserver/svn/ss/platform/branches/wc/wc_maven_migration/core/ss-core
> in the previous build
> Parsing POMs
> Modules changed, recalculating dependency graph
> ERROR: Failed to parse POMs
> java.io.FileNotFoundException:
> u:\jenkins\builds\wc.ss-core\com.ss:ss-core\2011-12-23_19-09-32\log (The
> filename, directory name, or volume label syntax is incorrect)
> at java.io.FileOutputStream.open(Native Method)
> at java.io.FileOutputStream.(Unknown Source)
> at java.io.FileOutputStream.(Unknown Source)
> at hudson.maven.MavenBuild$ProxyImpl2.(MavenBuild.java:474)
> at
> hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:686)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:462)
> at hudson.model.Run.run(Run.java:1404)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
> FATAL: Failed to create a temporary file in
> u:\jenkins\builds\wc.ss-core\com.ss:ss-core\2011-12-23_19-09-32
> hudson.util.IOException2: Failed to create a temporary file in
> u:\jenkins\builds\wc.ss-core\com.ss:ss-core\2011-12-23_19-09-32
> at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:67)
> at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:54)
> at hudson.XmlFile.write(XmlFile.java:170)
> at hudson.model.Run.save(Run.java:1540)
> at
> hudson.maven.MavenModuleSetBuild$RunnerImpl.post2(MavenModuleSetBuild.java:1011)
> at
> hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:614)
> at hudson.model.Run.run(Run.java:1429)
> at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:238)
> Caused by: java.io.IOException: The filename, directory name, or volume label
> syntax is incorrect
> at java.io.WinNTFileSystem.createFileExclusively(Native Method)
> at java.io.File.checkAndCreate(Unknown Source)
> at java.io.File.createTempFile(Unknown Source)
> at hudson.util.AtomicFileWriter.(AtomicFileWriter.java:65)
> ... 9 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13970) Build variable CC_BASELINE not populated with used baseline
[
https://issues.jenkins-ci.org/browse/JENKINS-13970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163509#comment-163509
]
Christian Wolfgang commented on JENKINS-13970:
--
Ok, I have been able to reproduce the problem. So far so good...
> Build variable CC_BASELINE not populated with used baseline
> ---
>
> Key: JENKINS-13970
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13970
> Project: Jenkins
> Issue Type: Bug
> Components: clearcase-ucm
>Affects Versions: current
> Environment: Microsoft Windows Server 2003, Standard x64 Edition,
> Service Pack 2
>Reporter: Tim Pillsbury
>Assignee: Christian Wolfgang
> Labels: clearcase, clearcase-ucm
>
> CCUCM says it is using the latest baseline, but the CC_BASELINE build
> variable is not always set to it.
> The problem seems to occur after "Updating view using all modules" if CCUCM
> finds activities and versions involved.
> {panel:title=Console Output|titleBGColor=#E7D6C1|bgColor=#CE}
> [CCUCM] Retrieved 28 baselines:
> [CCUCM] + WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 11:26:15 EDT 2012)
> [CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_18_12.1(Fri May 18 15:18:01 EDT
> 2012)
> [CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_19_12_CLR(Sat May 19 17:14:54 EDT
> 2012)
> [CCUCM] ...
> [CCUCM] + _*WRKB_RLS_2012_06_00_ECM_jenkins_0529_0925(Tue May 29 09:25:52 EDT
> 2012)*_(n)
> [CCUCM] + WRKB_CL_WRKB_RLS_2012_06_00_ECM_5_29_12_CLR(Tue May 29 14:22:09 EDT
> 2012)
> [CCUCM] + WRKB_RLS_2012_06_00_ECM_5_29_12.1(Tue May 29 15:12:08 EDT 2012)
> [CCUCM] *Using* *baseline:WRKB_RLS_2012_06_00_ECM_5_29_12.1@\WRKB_PVOB*(y)
> [CCUCM] View root: E:\Jenkins\jobs\Workbench Build 2012 June All except
> CPF\workspace\view
> [CCUCM] View tag : CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC
> [CCUCM] Reusing view root
> [CCUCM] Determine if view tag exists
> [CCUCM] Reusing view tag
> [CCUCM] UUID resulted in
> CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC
> [CCUCM] Getting snapshotview
> [CCUCM] Rebasing development stream
> (CCUCM_Workbench_Build_2012_June_All_except_CPF_XB57KDC) against parent
> stream (WRKB_RLS_2012_06_00_ECM) Done
> [CCUCM] Updating view using all modules
> [CCUCM] _*Found 3 activities. 20 versions involved*_(i)
> {panel}
> But then Injected environment variable CC_BASELINE is incorrect
> {panel:title=Injected environment
> variables|titleBGColor=#E7D6C1|bgColor=#CE}
> |CC_BASELINE|_*baseline:WRKB_RLS_2012_06_00_ECM_jenkins_0529_0925@\WRKB_PVOB*_|(n)|
> {panel}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14021) readlink not working on HP Itanium
[ https://issues.jenkins-ci.org/browse/JENKINS-14021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fulvio Cavarretta updated JENKINS-14021: Environment: Jenkins ver. 1.467. slave running on HP Itaniunm B.11.23 U ia64 with java 1.6 was:slave running on HP Itaniunm B.11.23 U ia64 with java 1.6 > readlink not working on HP Itanium > -- > > Key: JENKINS-14021 > URL: https://issues.jenkins-ci.org/browse/JENKINS-14021 > Project: Jenkins > Issue Type: Bug > Components: build-publisher >Affects Versions: current > Environment: Jenkins ver. 1.467. > slave running on HP Itaniunm B.11.23 U ia64 with java 1.6 >Reporter: Fulvio Cavarretta >Assignee: vjuranek > Labels: hpitanium, slave, symlink > > We have a slave running on an HP Itanium host (ver. HP-UX unknown B.11.23 U > ia64) where the readlink command does not exists. So when trying to resolve > symlinks, slave agent fails with the following error: > hudson.util.IOException2: java.io.IOException: Cannot run program "readlink" > (in directory "/misc/home_tmp_dstk110/."): readlink: not found > at hudson.FilePath.copyRecursiveTo(FilePath.java:1771) > at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) > at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:711) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:686) > at hudson.model.Build$RunnerImpl.post2(Build.java:162) > at > hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:633) > at hudson.model.Run.run(Run.java:1463) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:239) > Caused by: java.util.concurrent.ExecutionException: java.io.IOException: > Cannot run program "readlink" (in directory "/misc/home_tmp_dstk110/."): > readlink: not found > at hudson.remoting.Channel$3.adapt(Channel.java:679) > at hudson.remoting.Channel$3.adapt(Channel.java:674) > at hudson.remoting.FutureAdapter.get(FutureAdapter.java:55) > at hudson.FilePath.copyRecursiveTo(FilePath.java:1769) > ... 10 more > Caused by: java.io.IOException: Cannot run program "readlink" (in directory > "/misc/home_tmp_dstk110/."): readlink: not found > at java.lang.ProcessBuilder.start(ProcessBuilder.java:459) > at java.lang.Runtime.exec(Runtime.java:593) > at org.jruby.ext.posix.util.ExecIt.run(ExecIt.java:61) > at org.jruby.ext.posix.util.ExecIt.runAndWait(ExecIt.java:51) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13446) Dependency graph points to localhost:8080
[ https://issues.jenkins-ci.org/browse/JENKINS-13446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163508#comment-163508 ] Andreyev Melo commented on JENKINS-13446: - I don't know if it make any sense, but in our Enterprise instance it's works fine. It shows on footer "Jenkins ver. 1.424.6.1" so I guess that it is a kind of LTS, then it's equivalent to an "old" and free version. BTW, there are no occurrences to hostname or URL in config.xml or any file in JENKINS_HOME. In these instance we installed version 0.2 of this plugin. > Dependency graph points to localhost:8080 > - > > Key: JENKINS-13446 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13446 > Project: Jenkins > Issue Type: Bug > Components: depgraph-view >Reporter: Tim Landscheidt >Assignee: wolfs >Priority: Trivial > > When looking at > https://integration.mediawiki.org/ci/view/All/job/MediaWiki-postgres-phpunit/depgraph-view/? > with Konqueror, Firefox or Chrome, the link in the graph points to > http://localhost:8080/ci/view/All/job/MediaWiki-postgres-phpunit/. I haven't > confirmed whether this bug actually lies with Jenkins and/or which plugin, > but "depgraph-view" soundn't familiar :-). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14022) job-exporter not working
regis gerard created JENKINS-14022: -- Summary: job-exporter not working Key: JENKINS-14022 URL: https://issues.jenkins-ci.org/browse/JENKINS-14022 Project: Jenkins Issue Type: Bug Components: job-exporter Affects Versions: current Environment: MACHTYPE=x86_64-suse-linux, LANG=fr_FR.UTF-8, java.runtime.version=1.6.0_30-b12 Reporter: regis gerard Attachments: tracebuild.txt I am french and my english is not good ! Sorry On a plateform, i used job-exporter version 0.4 (https://wiki.jenkins-ci.org/display/JENKINS/Job+Exporter+Plugin) plugin with Jenkins v1.444 (java version=1.6.0_27) and it worked fine. On a other plateform, i used job-exporter version 0.4 (https://wiki.jenkins-ci.org/display/JENKINS/Job+Exporter+Plugin) plugin with Jenkins v1.446 and it did not work. No execution trace and no file hudsonBuild.properties created What can be the cause of the problem? you have an idea ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14021) readlink not working on HP Itanium
Fulvio Cavarretta created JENKINS-14021: --- Summary: readlink not working on HP Itanium Key: JENKINS-14021 URL: https://issues.jenkins-ci.org/browse/JENKINS-14021 Project: Jenkins Issue Type: Bug Components: build-publisher Affects Versions: current Environment: slave running on HP Itaniunm B.11.23 U ia64 with java 1.6 Reporter: Fulvio Cavarretta Assignee: vjuranek We have a slave running on an HP Itanium host (ver. HP-UX unknown B.11.23 U ia64) where the readlink command does not exists. So when trying to resolve symlinks, slave agent fails with the following error: hudson.util.IOException2: java.io.IOException: Cannot run program "readlink" (in directory "/misc/home_tmp_dstk110/."): readlink: not found at hudson.FilePath.copyRecursiveTo(FilePath.java:1771) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:711) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:686) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:633) at hudson.model.Run.run(Run.java:1463) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Caused by: java.util.concurrent.ExecutionException: java.io.IOException: Cannot run program "readlink" (in directory "/misc/home_tmp_dstk110/."): readlink: not found at hudson.remoting.Channel$3.adapt(Channel.java:679) at hudson.remoting.Channel$3.adapt(Channel.java:674) at hudson.remoting.FutureAdapter.get(FutureAdapter.java:55) at hudson.FilePath.copyRecursiveTo(FilePath.java:1769) ... 10 more Caused by: java.io.IOException: Cannot run program "readlink" (in directory "/misc/home_tmp_dstk110/."): readlink: not found at java.lang.ProcessBuilder.start(ProcessBuilder.java:459) at java.lang.Runtime.exec(Runtime.java:593) at org.jruby.ext.posix.util.ExecIt.run(ExecIt.java:61) at org.jruby.ext.posix.util.ExecIt.runAndWait(ExecIt.java:51) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13514) Matrix Reloaded should trigger the same combination in downstream matrix job
[ https://issues.jenkins-ci.org/browse/JENKINS-13514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Wolfgang resolved JENKINS-13514. -- Resolution: Fixed > Matrix Reloaded should trigger the same combination in downstream matrix job > > > Key: JENKINS-13514 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13514 > Project: Jenkins > Issue Type: Improvement > Components: matrix-reloaded >Affects Versions: current >Reporter: Dirk Haun >Assignee: Christian Wolfgang >Priority: Minor > Attachments: 01-jobA.png, 02-jobB.png > > > When rebuilding parts of a matrix job (using the matrix reloaded plugin), the > build will then trigger all downstream jobs. In our case, the downstream jobs > are also matrix jobs and we would like that in this case, the downstream jobs > are also "reloaded", i.e. only the parts that were rebuilt in the upstream > job should be built there as well. > To reproduce, I've used a setup that somewhat resembles what we have: > - 2 matrix jobs, jobA and jobB > - jobA has jobB as its downstream job > - each job consists of a 3x3 matrix with the axis labelled "compiler" and > "os" respectively > - the compiler axis has values FORTE, GCC, MSC > - the os axis has values solaris, linux, windows > - the build step is just a echo "hello world" > We're using the Parameterized Build plugin, > http://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin, to > trigger downstream builds but this can also be reproduced with the standard > "Build other projects" option. > The two screenshots show the matrix and which parts are supposed to be > rebuild. The second screenshot shows that jobB, when triggered by rebuilding > only parts of the jobA matrix, is actually building all 9 combinations, not > just the 2 of the upstream job. > P.S. I mentioned this problem at the Jenkins User Conference in Paris, in > case you remember :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13647) Environment variables from EnvInject plugin are not inherited/parsed by batch tasks
[ https://issues.jenkins-ci.org/browse/JENKINS-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Carsique reassigned JENKINS-13647: - Assignee: Gregory Boissinot (was: Kohsuke Kawaguchi) > Environment variables from EnvInject plugin are not inherited/parsed by batch > tasks > --- > > Key: JENKINS-13647 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13647 > Project: Jenkins > Issue Type: Bug > Components: batch-task >Affects Versions: current >Reporter: tsondergaard >Assignee: Gregory Boissinot > Attachments: config.xml > > > Environment variables set for a job with the "Prepare an environment for the > run" and not processed/used for batch tasks. This is very similar to bug > JENKINS-5580 reported for batch tasks and the now deprecated setenv plugin -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13647) Environment variables from EnvInject plugin are not inherited/parsed by batch tasks
[
https://issues.jenkins-ci.org/browse/JENKINS-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julien Carsique reopened JENKINS-13647:
---
Still got the issue with Jenkins 1.465, batch task plugin 1.16, rebuild plugin
1.11:
{code}
hudson.model.Executor run
SEVERE: Executor threw an exception
java.lang.NullPointerException: Current Project is null
at
com.sonyericsson.rebuild.RebuildAction.getProject(RebuildAction.java:121)
at
com.sonyericsson.rebuild.RebuildAction.getUrlName(RebuildAction.java:153)
at
org.jenkinsci.lib.envinject.service.EnvInjectActionRetriever.getEnvInjectAction(EnvInjectActionRetriever.java:32)
at
org.jenkinsci.lib.envinject.service.EnvVarsResolver.getEnVars(EnvVarsResolver.java:51)
at hudson.plugins.batch_task.BatchRun.run(BatchRun.java:224)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:239)
{code}
> Environment variables from EnvInject plugin are not inherited/parsed by batch
> tasks
> ---
>
> Key: JENKINS-13647
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13647
> Project: Jenkins
> Issue Type: Bug
> Components: batch-task
>Affects Versions: current
>Reporter: tsondergaard
>Assignee: Kohsuke Kawaguchi
> Attachments: config.xml
>
>
> Environment variables set for a job with the "Prepare an environment for the
> run" and not processed/used for batch tasks. This is very similar to bug
> JENKINS-5580 reported for batch tasks and the now deprecated setenv plugin
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[ https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Villanueva reopened JENKINS-11381: -- It is not resolved > Subversion Plugin does not support Subversion 1.7 > - > > Key: JENKINS-11381 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11381 > Project: Jenkins > Issue Type: Improvement > Components: subversion >Reporter: soundworker >Assignee: Kohsuke Kawaguchi >Priority: Blocker > Attachments: subversion.hpi, subversion.hpi, subversion.hpi > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11933) Subversion plugin doesn't probably work correctly with svn server version 1.7.1
[ https://issues.jenkins-ci.org/browse/JENKINS-11933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Villanueva reopened JENKINS-11933: -- it is not resolved > Subversion plugin doesn't probably work correctly with svn server version > 1.7.1 > --- > > Key: JENKINS-11933 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11933 > Project: Jenkins > Issue Type: Bug > Components: subversion >Affects Versions: current > Environment: svn server 1.7.1 > ubuntu >Reporter: Nikita Aznauryan >Assignee: Kohsuke Kawaguchi >Priority: Blocker > Labels: plugin > Attachments: 0001-imported-1.3.7.patch, > 0002-Adjust-version-number-in-pom.patch, > 0003-update-version-and-add-second-maven-repository-to-ge.patch, > 0005_subversion_plugin_svnkit_1_3_7.patch, subversion-svnkit-1.7.4.hpi, > subversion.hpi > > > I use usernames in my svn path like: > svn+ssh://jenkins@somepath > but I get a warning "... doesn't exist in the repository" > I think it started after svn server has been updated to 1.7.1 version > It worked fine before. > Subversion pooling log : > Started on Nov 30, 2011 8:11:31 PM > Location 'svn+ssh://jenkins@path' does not exist > One or more repository locations do not exist anymore for > hudson.model.FreeStyleProject@3937bf4[], project will be disabled. > Done. Took 1.3 sec > No changes -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
[ https://issues.jenkins-ci.org/browse/JENKINS-11381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Villanueva updated JENKINS-11381: - It is not resolved > Subversion Plugin does not support Subversion 1.7 > - > > Key: JENKINS-11381 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11381 > Project: Jenkins > Issue Type: Improvement > Components: subversion >Reporter: soundworker >Assignee: Kohsuke Kawaguchi >Priority: Blocker > Attachments: subversion.hpi, subversion.hpi, subversion.hpi > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13670) Use Action instead of state object
[ https://issues.jenkins-ci.org/browse/JENKINS-13670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-13670 started by Christian Wolfgang. > Use Action instead of state object > -- > > Key: JENKINS-13670 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13670 > Project: Jenkins > Issue Type: New Feature > Components: matrix-reloaded >Reporter: Christian Wolfgang >Assignee: Christian Wolfgang > Labels: action, matrix > > Currently, the plugin communicates with a global state object, this should be > done with Actions -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13670) Use Action instead of state object
[ https://issues.jenkins-ci.org/browse/JENKINS-13670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Wolfgang resolved JENKINS-13670. -- Resolution: Fixed > Use Action instead of state object > -- > > Key: JENKINS-13670 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13670 > Project: Jenkins > Issue Type: New Feature > Components: matrix-reloaded >Reporter: Christian Wolfgang >Assignee: Christian Wolfgang > Labels: action, matrix > > Currently, the plugin communicates with a global state object, this should be > done with Actions -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11598) Updating Plugins from plugins mirror and own update-center.json does not work
[ https://issues.jenkins-ci.org/browse/JENKINS-11598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163503#comment-163503 ] cforce commented on JENKINS-11598: -- I think i found the cause Jun 5, 2012 8:35:35 AM hudson.model.UpdateSite doPostBack SEVERE: Digest mismatch: Q+ejIVBw/42JwLVOxctt7TC38cw= vs jccSvBIyYEZqMMXc2xms5J+jo5E= in update center 'default' Jun 5, 2012 8:40:41 AM hudson.model.UpdateCenter$DownloadJob run The worng md5 is caused by my urls search replace modification in the json file. In result a standard (embedded) json file urls i used and server tries again to sintall from internet instead from our local mirror. Ho can i rcreate the json file with another plugin update root path (our mirror) I found a plugin (https://github.com/junoyoon/simpleupdatesiterepo/) which support creation of json file but only to single hpi files not for complete jenkins update site mirror. We need a tuturial how to create jenkins update mirror, esecpeciall doc how to create own mirro json indexd update file for end users. > Updating Plugins from plugins mirror and own update-center.json does not work > - > > Key: JENKINS-11598 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11598 > Project: Jenkins > Issue Type: Bug > Components: update-center >Affects Versions: current > Environment: Windows Server 2008, Tomcat 7, Java 1.6 >Reporter: cforce >Assignee: Kohsuke Kawaguchi > Attachments: symlink_plugins.sh, wget_plugins.sh > > > We run oor Jenkis Server in DMZ (Intranet), where direct Internet access is > not allowed, so we can't update plugin direct from web with admin console. We > are mirroring (see attached script wget_plugins.sh to do the job) the public > Jenkins plugins server and rewrite the original jenkins update-center.json, > this way that we repalce all hpi urls with the urls that point on our server > (see attached script symlink_plugins.sh to do that job). We then configure > new update-center urls in our jenkins amdin cosnole to point on our > ApacheServer wioth our modified update-center.json file. > This whole thing worked for about 3 months. We did several jenkins updates > and we don't know since what jenkins version but now this stopped working. > We get following expetion when trying to update the plugins, wher new version > are shows as available in admin console in browser. > Nov 3, 2011 12:17:02 PM hudson.model.UpdateCenter$DownloadJob run > SEVERE: Failed to install Email-ext plugin > java.net.ConnectException: Connection refused: connect > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown > Source) > at java.lang.reflect.Constructor.newInstance(Unknown Source) > at sun.net.www.protocol.http.HttpURLConnection$6.run(Unknown Source) > at java.security.AccessController.doPrivileged(Native Method) > at > sun.net.www.protocol.http.HttpURLConnection.getChainedException(Unknown > Source) > at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown > Source) > at > hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:624) > at hudson.model.UpdateCenter$DownloadJob._run(UpdateCenter.java:967) > at > hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1075) > at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:949) > at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) > 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 java.lang.Thread.run(Unknown Source) > Caused by: java.net.ConnectException: Connection refused: connect > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.PlainSocketImpl.doConnect(Unknown Source) > at java.net.PlainSocketImpl.connectToAddress(Unknown Source) > at java.net.PlainSocketImpl.connect(Unknown Source) > at java.net.SocksSocketImpl.connect(Unknown Source) > at java.net.Socket.connect(Unknown Source) > at java.net.Socket.connect(Unknown Source) > at sun.net.NetworkClient.doConnect(Unknown Source) > at sun.net.www.http.HttpClient.openServer(Unknown Source) > at sun.net.www.http.HttpClient.openServer(Unknown Source) > at sun.net.www.http.HttpClient.(Unknown Source) > at sun.net.www.http.HttpClient.Ne
[JIRA] (JENKINS-14020) Exception during workspace synchronize
[ https://issues.jenkins-ci.org/browse/JENKINS-14020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cyril Jean updated JENKINS-14020: - Environment: jenkins 1.465, PTC 1.13, WinXP 32bit SP3, no proxy, very low bandwidth (was: jenkins 1.465, PTC 1.13) > Exception during workspace synchronize > -- > > Key: JENKINS-14020 > URL: https://issues.jenkins-ci.org/browse/JENKINS-14020 > Project: Jenkins > Issue Type: Bug > Components: integrity-plugin >Affects Versions: current > Environment: jenkins 1.465, PTC 1.13, WinXP 32bit SP3, no proxy, very > low bandwidth >Reporter: Cyril Jean >Assignee: Cletus D'Souza > > Have following exception during workspace resynchronize: > SEVERE: An error occurred while reading stream from > 'file:/D:/tools/.jenkins/jobs/SPS4Pack/builds/2012-06-05_15-40-14/changelog.xml', > see nested exceptions > com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: > Invalid byte 1 of 1-byte UTF-8 sequence. > at > com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.invalidByte(Unknown > Source) > at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.read(Unknown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(Unknown Source) > at > com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.scanData(Unknown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanCDATASection(Unknown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown > Source) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown > Source) > at > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown > Source) > at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown > Source) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown > Source) > at > com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown > Source) > at org.apache.commons.digester3.Digester.parse(Digester.java:1588) > at org.apache.commons.digester3.Digester.parse(Digester.java:1557) > at > hudson.scm.IntegrityChangeLogParser.parse(IntegrityChangeLogParser.java:65) > at > hudson.scm.IntegrityChangeLogParser.parse(IntegrityChangeLogParser.java:20) > at hudson.model.AbstractBuild.calcChangeSet(AbstractBuild.java:825) > at hudson.model.AbstractBuild.access$600(AbstractBuild.java:103) > at > hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:591) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475) > at hudson.model.Run.run(Run.java:1434) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:239) > hudson.util.IOException2: Failed to parse > D:\tools\.jenkins\jobs\SPS4Pack\builds\2012-06-05_15-40-14\changelog.xml > at > hudson.scm.IntegrityChangeLogParser.parse(IntegrityChangeLogParser.java:69) > at > hudson.scm.IntegrityChangeLogParser.parse(IntegrityChangeLogParser.java:20) > at hudson.model.AbstractBuild.calcChangeSet(AbstractBuild.java:825) > at hudson.model.AbstractBuild.access$600(AbstractBuild.java:103) > at > hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:591) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475) > at hudson.model.Run.run(Run.java:1434) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:239) > Caused by: > com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: > Invalid byte 1 of 1-byte UTF-8 sequence. > at > com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.invalidByte(Unknown > Source) > at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.read(Unknown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(Unknown Source) > at > com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.scanData(Unknown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanCDATASection(Unknown > Source) > at > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$Fr
[JIRA] (JENKINS-13990) Polling find old already considered baselines
[ https://issues.jenkins-ci.org/browse/JENKINS-13990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-13990 started by Bue Petersen. > Polling find old already considered baselines > - > > Key: JENKINS-13990 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13990 > Project: Jenkins > Issue Type: Bug > Components: config-rotator >Affects Versions: current > Environment: All OS, Jenkins master-slave configuration >Reporter: Bue Petersen >Assignee: Bue Petersen >Priority: Critical > > Occassionally we see an error related to polling starting an job though there > should be no new baselines on ClearCase components configured. > In the following example we use two components. There are baselines model-1, > model-2, model-3, client-1, client-2, client-3. > We see jobs finding the baselines in correct order ending last configuration > model-3 and client-3. After some random time, polling finds an old > configuration and starts a new build. > By the design the new build i failed, as the configuration is not new and the > build get no new baselines when building. > You will se failed jobs appearing and pollings logs like below. Build #11 is > the first to fail, after finding no new baselines (though the polling log > did). > Build #10 was success. > -- snip: polling log from build #11 -- > Polling Log > View as plain text > This page captures the polling log that triggered this build. > Started on May 31, 2012 9:41:07 PM > [ConfigRotator] Polling > [ConfigRotator] Project configuration was not null > [ConfigRotator] Configuration is not null and was not reconfigured > Index: 0, Size: 0 > The configuration is: > * component:Model@\ConfigRotatorProofOfConceptJob2126_PVOB, > stream:ConfigRotatorProofOfConceptJob2126_one_int@\ConfigRotatorProofOfConceptJob2126_PVOB, > model-3@\ConfigRotatorProofOfConceptJob2126_PVOB > * component:Clientapp@\ConfigRotatorProofOfConceptJob2126_PVOB, > stream:ConfigRotatorProofOfConceptJob2126_one_int@\ConfigRotatorProofOfConceptJob2126_PVOB, > client-3@\ConfigRotatorProofOfConceptJob2126_PVOB > Done. Took 2.2 sec > Changes found > -- snap: polling log from build #11 -- > -- snip: console output from build #11 -- > Started by an SCM change > Building remotely on cc-nightcrawler in workspace > C:\jslave\workspace\ConfigRotatorProofOfConceptJob2126 > Config-rotator version: 0.1.4 > [DEBUG]Getting last result > [DEBUG]Action was NOT null > [DEBUG]Obtaining new configuration based on old > [DEBUG]Foreach configuration component > [DEBUG]CONFIG: > model-3@\ConfigRotatorProofOfConceptJob2126_PVOB@INITIAL(false/false) > [DEBUG]Wasn't fixed: model-3@\ConfigRotatorProofOfConceptJob2126_PVOB > [DEBUG]No baselines found: Index: 0, Size: 0 > Index: 0, Size: 0 > [DEBUG]CONFIG: > client-3@\ConfigRotatorProofOfConceptJob2126_PVOB@INITIAL(false/false) > [DEBUG]Wasn't fixed: client-3@\ConfigRotatorProofOfConceptJob2126_PVOB > [DEBUG]No baselines found: Index: 0, Size: 0 > Index: 0, Size: 0 > [ConfigRotator] No new baselines > [DEBUG]Getting last result > ERROR: No new baselines found! > Retrying after 10 seconds > Config-rotator version: 0.1.4 > [DEBUG]Getting last result > [DEBUG]Getting last result > [DEBUG]Action was NOT null > [DEBUG]Action was NOT null > [DEBUG]Obtaining new configuration based on old > [DEBUG]Obtaining new configuration based on old > [DEBUG]Foreach configuration component > [DEBUG]Foreach configuration component > [DEBUG]CONFIG: > model-3@\ConfigRotatorProofOfConceptJob2126_PVOB@INITIAL(false/false) > [DEBUG]CONFIG: > model-3@\ConfigRotatorProofOfConceptJob2126_PVOB@INITIAL(false/false) > [DEBUG]Wasn't fixed: model-3@\ConfigRotatorProofOfConceptJob2126_PVOB > [DEBUG]Wasn't fixed: model-3@\ConfigRotatorProofOfConceptJob2126_PVOB > [DEBUG]No baselines found: Index: 0, Size: 0 > [DEBUG]No baselines found: Index: 0, Size: 0 > Index: 0, Size: 0 > [DEBUG]CONFIG: > client-3@\ConfigRotatorProofOfConceptJob2126_PVOB@INITIAL(false/false) > [DEBUG]CONFIG: > client-3@\ConfigRotatorProofOfConceptJob2126_PVOB@INITIAL(false/false) > [DEBUG]Wasn't fixed: client-3@\ConfigRotatorProofOfConceptJob2126_PVOB > [DEBUG]Wasn't fixed: client-3@\ConfigRotatorProofOfConceptJob2126_PVOB > [DEBUG]No baselines found: Index: 0, Size: 0 > [DEBUG]No baselines found: Index: 0, Size: 0 > Index: 0, Size: 0 > [ConfigRotator] No new baselines > [DEBUG]Getting last result > [DEBUG]Getting last result > ERROR: No new baselines found! > [DEBUG]SCM is part of ConfigRotator > [DEBUG]SCM is part of ConfigRotator > [DEBUG]Action object is: null > [DEBUG]Action object is: null > [ConfigRotator] Action was null, unable
[JIRA] (JENKINS-13990) Polling find old already considered baselines
[ https://issues.jenkins-ci.org/browse/JENKINS-13990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-13990 started by Bue Petersen. > Polling find old already considered baselines > - > > Key: JENKINS-13990 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13990 > Project: Jenkins > Issue Type: Bug > Components: config-rotator >Affects Versions: current > Environment: All OS, Jenkins master-slave configuration >Reporter: Bue Petersen >Assignee: Bue Petersen >Priority: Critical > > Occassionally we see an error related to polling starting an job though there > should be no new baselines on ClearCase components configured. > In the following example we use two components. There are baselines model-1, > model-2, model-3, client-1, client-2, client-3. > We see jobs finding the baselines in correct order ending last configuration > model-3 and client-3. After some random time, polling finds an old > configuration and starts a new build. > By the design the new build i failed, as the configuration is not new and the > build get no new baselines when building. > You will se failed jobs appearing and pollings logs like below. Build #11 is > the first to fail, after finding no new baselines (though the polling log > did). > Build #10 was success. > -- snip: polling log from build #11 -- > Polling Log > View as plain text > This page captures the polling log that triggered this build. > Started on May 31, 2012 9:41:07 PM > [ConfigRotator] Polling > [ConfigRotator] Project configuration was not null > [ConfigRotator] Configuration is not null and was not reconfigured > Index: 0, Size: 0 > The configuration is: > * component:Model@\ConfigRotatorProofOfConceptJob2126_PVOB, > stream:ConfigRotatorProofOfConceptJob2126_one_int@\ConfigRotatorProofOfConceptJob2126_PVOB, > model-3@\ConfigRotatorProofOfConceptJob2126_PVOB > * component:Clientapp@\ConfigRotatorProofOfConceptJob2126_PVOB, > stream:ConfigRotatorProofOfConceptJob2126_one_int@\ConfigRotatorProofOfConceptJob2126_PVOB, > client-3@\ConfigRotatorProofOfConceptJob2126_PVOB > Done. Took 2.2 sec > Changes found > -- snap: polling log from build #11 -- > -- snip: console output from build #11 -- > Started by an SCM change > Building remotely on cc-nightcrawler in workspace > C:\jslave\workspace\ConfigRotatorProofOfConceptJob2126 > Config-rotator version: 0.1.4 > [DEBUG]Getting last result > [DEBUG]Action was NOT null > [DEBUG]Obtaining new configuration based on old > [DEBUG]Foreach configuration component > [DEBUG]CONFIG: > model-3@\ConfigRotatorProofOfConceptJob2126_PVOB@INITIAL(false/false) > [DEBUG]Wasn't fixed: model-3@\ConfigRotatorProofOfConceptJob2126_PVOB > [DEBUG]No baselines found: Index: 0, Size: 0 > Index: 0, Size: 0 > [DEBUG]CONFIG: > client-3@\ConfigRotatorProofOfConceptJob2126_PVOB@INITIAL(false/false) > [DEBUG]Wasn't fixed: client-3@\ConfigRotatorProofOfConceptJob2126_PVOB > [DEBUG]No baselines found: Index: 0, Size: 0 > Index: 0, Size: 0 > [ConfigRotator] No new baselines > [DEBUG]Getting last result > ERROR: No new baselines found! > Retrying after 10 seconds > Config-rotator version: 0.1.4 > [DEBUG]Getting last result > [DEBUG]Getting last result > [DEBUG]Action was NOT null > [DEBUG]Action was NOT null > [DEBUG]Obtaining new configuration based on old > [DEBUG]Obtaining new configuration based on old > [DEBUG]Foreach configuration component > [DEBUG]Foreach configuration component > [DEBUG]CONFIG: > model-3@\ConfigRotatorProofOfConceptJob2126_PVOB@INITIAL(false/false) > [DEBUG]CONFIG: > model-3@\ConfigRotatorProofOfConceptJob2126_PVOB@INITIAL(false/false) > [DEBUG]Wasn't fixed: model-3@\ConfigRotatorProofOfConceptJob2126_PVOB > [DEBUG]Wasn't fixed: model-3@\ConfigRotatorProofOfConceptJob2126_PVOB > [DEBUG]No baselines found: Index: 0, Size: 0 > [DEBUG]No baselines found: Index: 0, Size: 0 > Index: 0, Size: 0 > [DEBUG]CONFIG: > client-3@\ConfigRotatorProofOfConceptJob2126_PVOB@INITIAL(false/false) > [DEBUG]CONFIG: > client-3@\ConfigRotatorProofOfConceptJob2126_PVOB@INITIAL(false/false) > [DEBUG]Wasn't fixed: client-3@\ConfigRotatorProofOfConceptJob2126_PVOB > [DEBUG]Wasn't fixed: client-3@\ConfigRotatorProofOfConceptJob2126_PVOB > [DEBUG]No baselines found: Index: 0, Size: 0 > [DEBUG]No baselines found: Index: 0, Size: 0 > Index: 0, Size: 0 > [ConfigRotator] No new baselines > [DEBUG]Getting last result > [DEBUG]Getting last result > ERROR: No new baselines found! > [DEBUG]SCM is part of ConfigRotator > [DEBUG]SCM is part of ConfigRotator > [DEBUG]Action object is: null > [DEBUG]Action object is: null > [ConfigRotator] Action was null, unable
[JIRA] (JENKINS-13990) Polling find old already considered baselines
[ https://issues.jenkins-ci.org/browse/JENKINS-13990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-13990 stopped by Bue Petersen. > Polling find old already considered baselines > - > > Key: JENKINS-13990 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13990 > Project: Jenkins > Issue Type: Bug > Components: config-rotator >Affects Versions: current > Environment: All OS, Jenkins master-slave configuration >Reporter: Bue Petersen >Assignee: Bue Petersen >Priority: Critical > > Occassionally we see an error related to polling starting an job though there > should be no new baselines on ClearCase components configured. > In the following example we use two components. There are baselines model-1, > model-2, model-3, client-1, client-2, client-3. > We see jobs finding the baselines in correct order ending last configuration > model-3 and client-3. After some random time, polling finds an old > configuration and starts a new build. > By the design the new build i failed, as the configuration is not new and the > build get no new baselines when building. > You will se failed jobs appearing and pollings logs like below. Build #11 is > the first to fail, after finding no new baselines (though the polling log > did). > Build #10 was success. > -- snip: polling log from build #11 -- > Polling Log > View as plain text > This page captures the polling log that triggered this build. > Started on May 31, 2012 9:41:07 PM > [ConfigRotator] Polling > [ConfigRotator] Project configuration was not null > [ConfigRotator] Configuration is not null and was not reconfigured > Index: 0, Size: 0 > The configuration is: > * component:Model@\ConfigRotatorProofOfConceptJob2126_PVOB, > stream:ConfigRotatorProofOfConceptJob2126_one_int@\ConfigRotatorProofOfConceptJob2126_PVOB, > model-3@\ConfigRotatorProofOfConceptJob2126_PVOB > * component:Clientapp@\ConfigRotatorProofOfConceptJob2126_PVOB, > stream:ConfigRotatorProofOfConceptJob2126_one_int@\ConfigRotatorProofOfConceptJob2126_PVOB, > client-3@\ConfigRotatorProofOfConceptJob2126_PVOB > Done. Took 2.2 sec > Changes found > -- snap: polling log from build #11 -- > -- snip: console output from build #11 -- > Started by an SCM change > Building remotely on cc-nightcrawler in workspace > C:\jslave\workspace\ConfigRotatorProofOfConceptJob2126 > Config-rotator version: 0.1.4 > [DEBUG]Getting last result > [DEBUG]Action was NOT null > [DEBUG]Obtaining new configuration based on old > [DEBUG]Foreach configuration component > [DEBUG]CONFIG: > model-3@\ConfigRotatorProofOfConceptJob2126_PVOB@INITIAL(false/false) > [DEBUG]Wasn't fixed: model-3@\ConfigRotatorProofOfConceptJob2126_PVOB > [DEBUG]No baselines found: Index: 0, Size: 0 > Index: 0, Size: 0 > [DEBUG]CONFIG: > client-3@\ConfigRotatorProofOfConceptJob2126_PVOB@INITIAL(false/false) > [DEBUG]Wasn't fixed: client-3@\ConfigRotatorProofOfConceptJob2126_PVOB > [DEBUG]No baselines found: Index: 0, Size: 0 > Index: 0, Size: 0 > [ConfigRotator] No new baselines > [DEBUG]Getting last result > ERROR: No new baselines found! > Retrying after 10 seconds > Config-rotator version: 0.1.4 > [DEBUG]Getting last result > [DEBUG]Getting last result > [DEBUG]Action was NOT null > [DEBUG]Action was NOT null > [DEBUG]Obtaining new configuration based on old > [DEBUG]Obtaining new configuration based on old > [DEBUG]Foreach configuration component > [DEBUG]Foreach configuration component > [DEBUG]CONFIG: > model-3@\ConfigRotatorProofOfConceptJob2126_PVOB@INITIAL(false/false) > [DEBUG]CONFIG: > model-3@\ConfigRotatorProofOfConceptJob2126_PVOB@INITIAL(false/false) > [DEBUG]Wasn't fixed: model-3@\ConfigRotatorProofOfConceptJob2126_PVOB > [DEBUG]Wasn't fixed: model-3@\ConfigRotatorProofOfConceptJob2126_PVOB > [DEBUG]No baselines found: Index: 0, Size: 0 > [DEBUG]No baselines found: Index: 0, Size: 0 > Index: 0, Size: 0 > [DEBUG]CONFIG: > client-3@\ConfigRotatorProofOfConceptJob2126_PVOB@INITIAL(false/false) > [DEBUG]CONFIG: > client-3@\ConfigRotatorProofOfConceptJob2126_PVOB@INITIAL(false/false) > [DEBUG]Wasn't fixed: client-3@\ConfigRotatorProofOfConceptJob2126_PVOB > [DEBUG]Wasn't fixed: client-3@\ConfigRotatorProofOfConceptJob2126_PVOB > [DEBUG]No baselines found: Index: 0, Size: 0 > [DEBUG]No baselines found: Index: 0, Size: 0 > Index: 0, Size: 0 > [ConfigRotator] No new baselines > [DEBUG]Getting last result > [DEBUG]Getting last result > ERROR: No new baselines found! > [DEBUG]SCM is part of ConfigRotator > [DEBUG]SCM is part of ConfigRotator > [DEBUG]Action object is: null > [DEBUG]Action object is: null > [ConfigRotator] Action was null, unable
[JIRA] (JENKINS-14020) Exception during workspace synchronize
Cyril Jean created JENKINS-14020: Summary: Exception during workspace synchronize Key: JENKINS-14020 URL: https://issues.jenkins-ci.org/browse/JENKINS-14020 Project: Jenkins Issue Type: Bug Components: integrity-plugin Affects Versions: current Environment: jenkins 1.465, PTC 1.13 Reporter: Cyril Jean Assignee: Cletus D'Souza Have following exception during workspace resynchronize: SEVERE: An error occurred while reading stream from 'file:/D:/tools/.jenkins/jobs/SPS4Pack/builds/2012-06-05_15-40-14/changelog.xml', see nested exceptions com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: Invalid byte 1 of 1-byte UTF-8 sequence. at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.invalidByte(Unknown Source) at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.read(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.scanData(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanCDATASection(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.commons.digester3.Digester.parse(Digester.java:1588) at org.apache.commons.digester3.Digester.parse(Digester.java:1557) at hudson.scm.IntegrityChangeLogParser.parse(IntegrityChangeLogParser.java:65) at hudson.scm.IntegrityChangeLogParser.parse(IntegrityChangeLogParser.java:20) at hudson.model.AbstractBuild.calcChangeSet(AbstractBuild.java:825) at hudson.model.AbstractBuild.access$600(AbstractBuild.java:103) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:591) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475) at hudson.model.Run.run(Run.java:1434) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) hudson.util.IOException2: Failed to parse D:\tools\.jenkins\jobs\SPS4Pack\builds\2012-06-05_15-40-14\changelog.xml at hudson.scm.IntegrityChangeLogParser.parse(IntegrityChangeLogParser.java:69) at hudson.scm.IntegrityChangeLogParser.parse(IntegrityChangeLogParser.java:20) at hudson.model.AbstractBuild.calcChangeSet(AbstractBuild.java:825) at hudson.model.AbstractBuild.access$600(AbstractBuild.java:103) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:591) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475) at hudson.model.Run.run(Run.java:1434) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Caused by: com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: Invalid byte 1 of 1-byte UTF-8 sequence. at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.invalidByte(Unknown Source) at com.sun.org.apache.xerces.internal.impl.io.UTF8Reader.read(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.load(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.scanData(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanCDATASection(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unk
[JIRA] (JENKINS-14019) Multiple-SCM-Plugin does not see that nothing changed in Git-Repo and keeps building
Andreas created JENKINS-14019: - Summary: Multiple-SCM-Plugin does not see that nothing changed in Git-Repo and keeps building Key: JENKINS-14019 URL: https://issues.jenkins-ci.org/browse/JENKINS-14019 Project: Jenkins Issue Type: Bug Components: multiple-scms Environment: Ubuntu 10, Jenkins 1.457, multiple-scms 0.2, Git 1.1.17, Git-Parameter 0.2 Reporter: Andreas Assignee: Kevin Bell Priority: Blocker I've extended a certain job with a project containing centralized build-scripts, thus I set the checkout-path to "../BUILD" for this repo, the other remained unchanged. The build works fine, however, the build is triggered all 15 mins (Poll SCM = */15 * * * *), although nothing has changed in neither repo. The git-revision for both repos is shown correctly, only the plugin doesn't recognize it hasn't changed. This is a blocker for me that prevents me from using the plugin, because I can't afford 20 builds to run every 15 minutes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13909) Plugin update via manual upload fails on recent Jenkins version ?
[ https://issues.jenkins-ci.org/browse/JENKINS-13909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163501#comment-163501 ] SCM/JIRA link daemon commented on JENKINS-13909: Code changed in jenkins User: Nicolas De Loof Path: core/src/main/java/hudson/PluginManager.java http://jenkins-ci.org/commit/jenkins/de5938b3a65ea0f33bb0be077decce0b05683cd4 Log: [JENKINS-13909] don't keep legacy *.hpi when uploading a plugin even jenkins takes care to load jpi first, this is confusing > Plugin update via manual upload fails on recent Jenkins version ? > - > > Key: JENKINS-13909 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13909 > Project: Jenkins > Issue Type: Bug > Components: update-center > Environment: Jenkins 1.447.1, 1.465 >Reporter: Yama Tksh > > Plugin update via manual upload seems to have a problem relating to jpi/hpi > files. > Initially, our $JENKINS_HOME/plugins/ folder had the following contents: > * myplugin.hpi - old version > * myplugin/- old version > Then I uploaded a new version of myplugin.hpi file via web upload function on > the pluginManager/advanced page, > and restarted Jenkins. > 1). On Jenkins 1.424.6, the update succeeded. The plugins/ folder was updated > as follows: > * myplugin.hpi - new version (shown version name - OK) > * myplugin/- new version - OK > * (myplugin.bak file was not created) > 2). On Jenkins 1.447.1, the new version name was correctly shown in the > plugin list, > but the update itself failed: > * myplugin.jpi - new version (shown version name - OK) > * myplugin.hpi - old version > * myplugin/- old version - NG > 3). On Jenkins 1.465, the update itself succeeded, but the old version name > was shown: > * myplugin.jpi - new version > * myplugin.hpi - old version (shown version name - NG) > * myplugin/- new version - OK > In the cases of 2) and 3), > when I removed myplugin.hpi and restarted Jenkins, > then both of the update and shown version name became O.K. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13909) Plugin update via manual upload fails on recent Jenkins version ?
[ https://issues.jenkins-ci.org/browse/JENKINS-13909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163502#comment-163502 ] SCM/JIRA link daemon commented on JENKINS-13909: Code changed in jenkins User: Nicolas De loof Path: core/src/main/java/hudson/PluginManager.java http://jenkins-ci.org/commit/jenkins/6da5894f49aba524443fda11702fea33de43733d Log: Merge pull request #491 from ndeloof/JENKINS-13909 [JENKINS-13909] don't keep legacy *.hpi when uploading a plugin Compare: https://github.com/jenkinsci/jenkins/compare/0dfb3ee...6da5894 > Plugin update via manual upload fails on recent Jenkins version ? > - > > Key: JENKINS-13909 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13909 > Project: Jenkins > Issue Type: Bug > Components: update-center > Environment: Jenkins 1.447.1, 1.465 >Reporter: Yama Tksh > > Plugin update via manual upload seems to have a problem relating to jpi/hpi > files. > Initially, our $JENKINS_HOME/plugins/ folder had the following contents: > * myplugin.hpi - old version > * myplugin/- old version > Then I uploaded a new version of myplugin.hpi file via web upload function on > the pluginManager/advanced page, > and restarted Jenkins. > 1). On Jenkins 1.424.6, the update succeeded. The plugins/ folder was updated > as follows: > * myplugin.hpi - new version (shown version name - OK) > * myplugin/- new version - OK > * (myplugin.bak file was not created) > 2). On Jenkins 1.447.1, the new version name was correctly shown in the > plugin list, > but the update itself failed: > * myplugin.jpi - new version (shown version name - OK) > * myplugin.hpi - old version > * myplugin/- old version - NG > 3). On Jenkins 1.465, the update itself succeeded, but the old version name > was shown: > * myplugin.jpi - new version > * myplugin.hpi - old version (shown version name - NG) > * myplugin/- new version - OK > In the cases of 2) and 3), > when I removed myplugin.hpi and restarted Jenkins, > then both of the update and shown version name became O.K. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14018) NullPointerException using Cpplint parser in warnings plugin on console log.
Fabian Pachner created JENKINS-14018: Summary: NullPointerException using Cpplint parser in warnings plugin on console log. Key: JENKINS-14018 URL: https://issues.jenkins-ci.org/browse/JENKINS-14018 Project: Jenkins Issue Type: Bug Components: violations, warnings Affects Versions: current Reporter: Fabian Pachner Assignee: peterkittreilly Priority: Critical I want to use the warnings plugin to display results of cpplint from the console. I am getting the following exception: ERROR: Publisher hudson.plugins.warnings.WarningsPublisher aborted due to exception java.lang.NullPointerException at hudson.plugins.violations.util.AbsoluteFileFinder.addSourcePaths(AbsoluteFileFinder.java:20) at hudson.plugins.violations.types.cpplint.CppLintParser.parse(CppLintParser.java:44) at hudson.plugins.warnings.parser.ViolationsAdapter.parse(ViolationsAdapter.java:60) at hudson.plugins.warnings.parser.ParserRegistry.parse(ParserRegistry.java:317) at hudson.plugins.warnings.parser.ParserRegistry.parse(ParserRegistry.java:296) at hudson.plugins.warnings.WarningsPublisher.parseConsoleLog(WarningsPublisher.java:293) at hudson.plugins.warnings.WarningsPublisher.perform(WarningsPublisher.java:257) at hudson.plugins.analysis.core.HealthAwarePublisher.perform(HealthAwarePublisher.java:338) at hudson.tasks.BuildStepMonitor$2.perform(BuildStepMonitor.java:27) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625) at hudson.model.Run.run(Run.java:1433) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) I am using warnings plugin 4.5 and violations plugin 0.7.10. If you need any further information, please ask. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
