[JIRA] (JENKINS-11618) Prototype 1.7 is missing the instance 'toJSON' method
[
https://issues.jenkins-ci.org/browse/JENKINS-11618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159738#comment-159738
]
dogfood commented on JENKINS-11618:
---
Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png!
[jenkins_main_trunk #1554|http://ci.jenkins-ci.org/job/jenkins_main_trunk/1554/]
[JENKINS-11618] backporting the fix here. (Revision
794cc76676863233f4dd1897c4b2ef7810a927bd)
[JENKINS-11618] Adding back the 'toJSON' instance method. (Revision
34e8117a64ce94a7e5da35be3bc3b077de16e1b2)
Result = SUCCESS
Kohsuke Kawaguchi :
[794cc76676863233f4dd1897c4b2ef7810a927bd|https://github.com/jenkinsci/jenkins/commit/794cc76676863233f4dd1897c4b2ef7810a927bd]
Files :
* war/src/main/webapp/scripts/prototype.js
Kohsuke Kawaguchi :
[34e8117a64ce94a7e5da35be3bc3b077de16e1b2|https://github.com/jenkinsci/jenkins/commit/34e8117a64ce94a7e5da35be3bc3b077de16e1b2]
Files :
* war/src/main/webapp/scripts/prototype.js
> Prototype 1.7 is missing the instance 'toJSON' method
> -
>
> Key: JENKINS-11618
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11618
> Project: Jenkins
> Issue Type: Bug
> Components: html5-notifier
>Affects Versions: current
> Environment: n/a
>Reporter: Dan Savilonis
>Assignee: jieryn
>Priority: Blocker
>
> When the html5-notifier plugin is enabled, you cannot save a job with more
> than one build step. To reproduce, install the plugin and add a new job with
> two windows batch file or shell script build steps. If only one is created,
> it will save, but if two are created, you will see an error like the
> following:
> Failed to parse form data. Please report this problem as a bug
> JSON={"":"","builder":"\"[{\"command\":\"bar\",\"stapler-class\":\"hudson.tasks.Shell\",\"kind\":\"hudson.tasks.Shell\"},
> {\"command\":\"cd
> foo\",\"stapler-class\":\"hudson.tasks.Shell\",\"kind\":\"hudson.tasks.Shell\"}]\"","description":"","hasSlaveAffinity":{"assignedLabelString":"windows&&expander"},"name":"debug_job2","properties":{"hudson-model-ParametersDefinitionProperty":{},"hudson-plugins-batch_task-BatchTaskProperty":{},"stapler-class-bag":"true"},"scm":{"value":"3"}}
> net.sf.json.JSONException: A JSONArray text must start with '[' at character
> 1 of "[{"command":"cd
> bar","stapler-class":"hudson.tasks.Shell","kind":"hudson.tasks.Shell"},
> {"command":"cd
> foo","stapler-class":"hudson.tasks.Shell","kind":"hudson.tasks.Shell"}]"
> at net.sf.json.util.JSONTokener.syntaxError(JSONTokener.java:512)
> at net.sf.json.JSONArray._fromJSONTokener(JSONArray.java:903)
> at net.sf.json.JSONArray._fromString(JSONArray.java:983)
> at net.sf.json.JSONArray.fromObject(JSONArray.java:141)
> at net.sf.json.JSONArray.fromObject(JSONArray.java:120)
> at
> hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:863)
> at
> hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:853)
> at hudson.util.DescribableList.rebuildHetero(DescribableList.java:185)
> at hudson.model.Project.submit(Project.java:197)
> at hudson.model.Job.doConfigSubmit(Job.java:966)
> at hudson.model.AbstractProject.doConfigSubmit(AbstractProject.java:643)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:282)
> at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:149)
> at
> org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:88)
> at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:104)
> at
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:646)
> at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:234)
> at
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:646)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:477)
> at org.kohsuke.stapler.Stapler.service(Stapler.java:159)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
> at winstone.ServletConfiguration.execute(ServletConfiguration.java:249)
> at winstone.RequestDispatcher.forward(RequestDispatcher.java:335)
> at winstone
[JIRA] (JENKINS-11618) Prototype 1.7 is missing the instance 'toJSON' method
[
https://issues.jenkins-ci.org/browse/JENKINS-11618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159737#comment-159737
]
SCM/JIRA link daemon commented on JENKINS-11618:
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
war/src/main/webapp/scripts/prototype.js
http://jenkins-ci.org/commit/jenkins/34e8117a64ce94a7e5da35be3bc3b077de16e1b2
Log:
[JENKINS-11618] Adding back the 'toJSON' instance method.
This change, in parallel to a fix in stapler bind.js, would maximize the
backward compatibility.
> Prototype 1.7 is missing the instance 'toJSON' method
> -
>
> Key: JENKINS-11618
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11618
> Project: Jenkins
> Issue Type: Bug
> Components: html5-notifier
>Affects Versions: current
> Environment: n/a
>Reporter: Dan Savilonis
>Assignee: jieryn
>Priority: Blocker
>
> When the html5-notifier plugin is enabled, you cannot save a job with more
> than one build step. To reproduce, install the plugin and add a new job with
> two windows batch file or shell script build steps. If only one is created,
> it will save, but if two are created, you will see an error like the
> following:
> Failed to parse form data. Please report this problem as a bug
> JSON={"":"","builder":"\"[{\"command\":\"bar\",\"stapler-class\":\"hudson.tasks.Shell\",\"kind\":\"hudson.tasks.Shell\"},
> {\"command\":\"cd
> foo\",\"stapler-class\":\"hudson.tasks.Shell\",\"kind\":\"hudson.tasks.Shell\"}]\"","description":"","hasSlaveAffinity":{"assignedLabelString":"windows&&expander"},"name":"debug_job2","properties":{"hudson-model-ParametersDefinitionProperty":{},"hudson-plugins-batch_task-BatchTaskProperty":{},"stapler-class-bag":"true"},"scm":{"value":"3"}}
> net.sf.json.JSONException: A JSONArray text must start with '[' at character
> 1 of "[{"command":"cd
> bar","stapler-class":"hudson.tasks.Shell","kind":"hudson.tasks.Shell"},
> {"command":"cd
> foo","stapler-class":"hudson.tasks.Shell","kind":"hudson.tasks.Shell"}]"
> at net.sf.json.util.JSONTokener.syntaxError(JSONTokener.java:512)
> at net.sf.json.JSONArray._fromJSONTokener(JSONArray.java:903)
> at net.sf.json.JSONArray._fromString(JSONArray.java:983)
> at net.sf.json.JSONArray.fromObject(JSONArray.java:141)
> at net.sf.json.JSONArray.fromObject(JSONArray.java:120)
> at
> hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:863)
> at
> hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:853)
> at hudson.util.DescribableList.rebuildHetero(DescribableList.java:185)
> at hudson.model.Project.submit(Project.java:197)
> at hudson.model.Job.doConfigSubmit(Job.java:966)
> at hudson.model.AbstractProject.doConfigSubmit(AbstractProject.java:643)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:282)
> at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:149)
> at
> org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:88)
> at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:104)
> at
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:646)
> at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:234)
> at
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:646)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:477)
> at org.kohsuke.stapler.Stapler.service(Stapler.java:159)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
> at winstone.ServletConfiguration.execute(ServletConfiguration.java:249)
> at winstone.RequestDispatcher.forward(RequestDispatcher.java:335)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:378)
> at
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95)
> at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:195)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368)
> at hudson.security.csrf.CrumbFilt
[JIRA] (JENKINS-11618) Prototype 1.7 is missing the instance 'toJSON' method
[
https://issues.jenkins-ci.org/browse/JENKINS-11618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159736#comment-159736
]
SCM/JIRA link daemon commented on JENKINS-11618:
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
war/src/main/webapp/scripts/prototype.js
http://jenkins-ci.org/commit/jenkins/794cc76676863233f4dd1897c4b2ef7810a927bd
Log:
[JENKINS-11618] backporting the fix here.
I actually applied the diff from
6904bb61e31595b70260840937114e79a646da5d in keyboard-shortcuts-plugin
> Prototype 1.7 is missing the instance 'toJSON' method
> -
>
> Key: JENKINS-11618
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11618
> Project: Jenkins
> Issue Type: Bug
> Components: html5-notifier
>Affects Versions: current
> Environment: n/a
>Reporter: Dan Savilonis
>Assignee: jieryn
>Priority: Blocker
>
> When the html5-notifier plugin is enabled, you cannot save a job with more
> than one build step. To reproduce, install the plugin and add a new job with
> two windows batch file or shell script build steps. If only one is created,
> it will save, but if two are created, you will see an error like the
> following:
> Failed to parse form data. Please report this problem as a bug
> JSON={"":"","builder":"\"[{\"command\":\"bar\",\"stapler-class\":\"hudson.tasks.Shell\",\"kind\":\"hudson.tasks.Shell\"},
> {\"command\":\"cd
> foo\",\"stapler-class\":\"hudson.tasks.Shell\",\"kind\":\"hudson.tasks.Shell\"}]\"","description":"","hasSlaveAffinity":{"assignedLabelString":"windows&&expander"},"name":"debug_job2","properties":{"hudson-model-ParametersDefinitionProperty":{},"hudson-plugins-batch_task-BatchTaskProperty":{},"stapler-class-bag":"true"},"scm":{"value":"3"}}
> net.sf.json.JSONException: A JSONArray text must start with '[' at character
> 1 of "[{"command":"cd
> bar","stapler-class":"hudson.tasks.Shell","kind":"hudson.tasks.Shell"},
> {"command":"cd
> foo","stapler-class":"hudson.tasks.Shell","kind":"hudson.tasks.Shell"}]"
> at net.sf.json.util.JSONTokener.syntaxError(JSONTokener.java:512)
> at net.sf.json.JSONArray._fromJSONTokener(JSONArray.java:903)
> at net.sf.json.JSONArray._fromString(JSONArray.java:983)
> at net.sf.json.JSONArray.fromObject(JSONArray.java:141)
> at net.sf.json.JSONArray.fromObject(JSONArray.java:120)
> at
> hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:863)
> at
> hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:853)
> at hudson.util.DescribableList.rebuildHetero(DescribableList.java:185)
> at hudson.model.Project.submit(Project.java:197)
> at hudson.model.Job.doConfigSubmit(Job.java:966)
> at hudson.model.AbstractProject.doConfigSubmit(AbstractProject.java:643)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:282)
> at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:149)
> at
> org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:88)
> at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:104)
> at
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:646)
> at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:234)
> at
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:646)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:477)
> at org.kohsuke.stapler.Stapler.service(Stapler.java:159)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
> at winstone.ServletConfiguration.execute(ServletConfiguration.java:249)
> at winstone.RequestDispatcher.forward(RequestDispatcher.java:335)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:378)
> at
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95)
> at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:195)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368)
> at hudson.security.csrf.CrumbFilter.doFilte
[JIRA] (JENKINS-11618) Prototype 1.7 is missing the instance 'toJSON' method
[
https://issues.jenkins-ci.org/browse/JENKINS-11618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kohsuke Kawaguchi updated JENKINS-11618:
Summary: Prototype 1.7 is missing the instance 'toJSON' method (was:
Enabling html5-notifier plugin breaks job save page)
> Prototype 1.7 is missing the instance 'toJSON' method
> -
>
> Key: JENKINS-11618
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11618
> Project: Jenkins
> Issue Type: Bug
> Components: html5-notifier
>Affects Versions: current
> Environment: n/a
>Reporter: Dan Savilonis
>Assignee: jieryn
>Priority: Blocker
>
> When the html5-notifier plugin is enabled, you cannot save a job with more
> than one build step. To reproduce, install the plugin and add a new job with
> two windows batch file or shell script build steps. If only one is created,
> it will save, but if two are created, you will see an error like the
> following:
> Failed to parse form data. Please report this problem as a bug
> JSON={"":"","builder":"\"[{\"command\":\"bar\",\"stapler-class\":\"hudson.tasks.Shell\",\"kind\":\"hudson.tasks.Shell\"},
> {\"command\":\"cd
> foo\",\"stapler-class\":\"hudson.tasks.Shell\",\"kind\":\"hudson.tasks.Shell\"}]\"","description":"","hasSlaveAffinity":{"assignedLabelString":"windows&&expander"},"name":"debug_job2","properties":{"hudson-model-ParametersDefinitionProperty":{},"hudson-plugins-batch_task-BatchTaskProperty":{},"stapler-class-bag":"true"},"scm":{"value":"3"}}
> net.sf.json.JSONException: A JSONArray text must start with '[' at character
> 1 of "[{"command":"cd
> bar","stapler-class":"hudson.tasks.Shell","kind":"hudson.tasks.Shell"},
> {"command":"cd
> foo","stapler-class":"hudson.tasks.Shell","kind":"hudson.tasks.Shell"}]"
> at net.sf.json.util.JSONTokener.syntaxError(JSONTokener.java:512)
> at net.sf.json.JSONArray._fromJSONTokener(JSONArray.java:903)
> at net.sf.json.JSONArray._fromString(JSONArray.java:983)
> at net.sf.json.JSONArray.fromObject(JSONArray.java:141)
> at net.sf.json.JSONArray.fromObject(JSONArray.java:120)
> at
> hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:863)
> at
> hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:853)
> at hudson.util.DescribableList.rebuildHetero(DescribableList.java:185)
> at hudson.model.Project.submit(Project.java:197)
> at hudson.model.Job.doConfigSubmit(Job.java:966)
> at hudson.model.AbstractProject.doConfigSubmit(AbstractProject.java:643)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:282)
> at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:149)
> at
> org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:88)
> at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:104)
> at
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:646)
> at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:234)
> at
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:646)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:477)
> at org.kohsuke.stapler.Stapler.service(Stapler.java:159)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
> at winstone.ServletConfiguration.execute(ServletConfiguration.java:249)
> at winstone.RequestDispatcher.forward(RequestDispatcher.java:335)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:378)
> at
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95)
> at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:195)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368)
> at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java:195)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368)
> at
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
>
[JIRA] (JENKINS-12958) Deleting an email address from Email Notifications configuration for build projects does not stop emails from being sent to deleted email address
Bryant Kwon created JENKINS-12958: - Summary: Deleting an email address from Email Notifications configuration for build projects does not stop emails from being sent to deleted email address Key: JENKINS-12958 URL: https://issues.jenkins-ci.org/browse/JENKINS-12958 Project: Jenkins Issue Type: Bug Components: email-ext, notification Environment: 64 bit Redhat Linux OS (2.6.18-238.5.1.el5) Reporter: Bryant Kwon Attachments: Jenkins-email-config-issue1.jpg, Jenkins-email-config-issue2.jpg We attempted to delete a previously configured email address in Email Notifications configuration for a job. After saving the changes, the UI shows that the email address is no longer present. However, the job still sends out email notifications to the deleted email address. This was working fine on previous releases. We are on Jenkins v1.445 Diagnostic information for administrators: Generating server: mpsc-expf02.uboc.com akhilesh.dwiv...@unionbank.com #< #5.1.1 X-Notes; User Akhilesh.Dwivedi (Akhilesh.Dwivedi@union bank.com) not listed in Domino Directory > #SMTP# Original message headers: Received: from chdc-exhub01.uboc-ad.corp.uboc.com ([10.170.108.172]) by mpsc-expf02.uboc.com (Lotus Domino Release 6.5.4FP3) with ESMTP id 2012022911594077-76909 ; Wed, 29 Feb 2012 11:59:40 -0800 Received: from chabeprd204.uboc.com (10.170.144.59) by chdc-exhub01.uboc-ad.corp.uboc.com (10.170.108.172) with Microsoft SMTP Server id 8.3.192.1; Wed, 29 Feb 2012 11:59:40 -0800 Date: Wed, 29 Feb 2012 11:59:32 -0800 From: ABE Administrator To: STIP-ABE-ADMIN, , , , , , In-Reply-To: <1237447658.28121330532922186.javamail.abe...@chabeprd204.uboc.com> References: <1237447658.28121330532922186.javamail.abe...@chabeprd204.uboc.com> Subject: Jenkins build is still unstable: SMR #377 MIME-Version: 1.0 X-Jenkins-Job: SMR X-Jenkins-Result: UNSTABLE Return-Path: stip-abe-ad...@unionbank.com X-MIMETrack: Itemize by SMTP Server on MP240-PF02/ENT/UBOC(Release 6.5.4FP3|January 09, 2006) at 02/29/2012 11:59:40 AM, Serialize by Router on MP240-PF02/ENT/UBOC(Release 6.5.4FP3|January 09, 2006) at 02/29/2012 12:00:04 PM, Serialize complete at 02/29/2012 12:00:04 PM Message-ID: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" -- 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-12957) check AJP request attribute value is null.
[
https://issues.jenkins-ci.org/browse/JENKINS-12957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yoshihito Fukuyama updated JENKINS-12957:
-
Description:
I used jenkins and apache httpd and mod_jk 1.2.32.
Jenkins throws NullPointerException.
mod_jk config:
- mod_jk.conf
{quote}
JkWorkersFile conf/workers.properties
JkMount /* jenkins
{quote}
- workers.properties
{quote}
worker.list=jenkins
worker.jenkins.type=ajp13
worker.jenkins.host=localhost
worker.jenkins.port=8009
{quote}
jenkins:
- log
{quote}
:
Feb 29, 2012 1:11:07 PM hudson.WebAppMain$2 run
INFO: Jenkins is fully up and running
Feb 29, 2012 1:26:40 PM winstone.Logger logInternal
SEVERE: Error within request handler thread
java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:411)
at
winstone.ajp13.Ajp13IncomingPacket.parsePacket(Ajp13IncomingPacket.java:163)
at
winstone.ajp13.Ajp13Listener.allocateRequestResponse(Ajp13Listener.java:184)
at winstone.RequestHandlerThread.run(RequestHandlerThread.java:79)
at java.lang.Thread.run(Thread.java:636)
:
{quote}
mod_jk 1.2.32 sending null AJP request attribute value to server.
workaround: configure LB worker to mod_jk.
- workers.properties
{quote}
worker.list=jenkins
worker.jenkins.type=lb
worker.jenkins.balance_workers=jenkins1
worker.jenkins1.type=ajp13
worker.jenkins1.host=localhost
worker.jenkins1.port=8009
{quote}
or use mod_jk 1.2.31.
was:
I used jenkins and apache httpd and mod_jk 1.2.32.
Jenkins throws NullPointerException.
mod_jk config:
mod_jk.conf
JkWorkersFile conf/workers.properties
JkMount /* jenkins
workers.properties
worker.list=jenkins
worker.jenkins.type=ajp13
worker.jenkins.host=localhost
worker.jenkins.port=8009
jenkins log:
:
Feb 29, 2012 1:11:07 PM hudson.WebAppMain$2 run
INFO: Jenkins is fully up and running
Feb 29, 2012 1:26:40 PM winstone.Logger logInternal
SEVERE: Error within request handler thread
java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:411)
at
winstone.ajp13.Ajp13IncomingPacket.parsePacket(Ajp13IncomingPacket.java:163)
at
winstone.ajp13.Ajp13Listener.allocateRequestResponse(Ajp13Listener.java:184)
at winstone.RequestHandlerThread.run(RequestHandlerThread.java:79)
at java.lang.Thread.run(Thread.java:636)
:
mod_jk 1.2.32 sending null AJP request attribute value to server.
workaround:
configure LB worker to mod_jk.
workers.properties
worker.list=jenkins
worker.jenkins.type=lb
worker.jenkins.balance_workers=jenkins1
worker.jenkins1.type=ajp13
worker.jenkins1.host=localhost
worker.jenkins1.port=8009
or use mod_jk 1.2.31.
> check AJP request attribute value is null.
> --
>
> Key: JENKINS-12957
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12957
> Project: Jenkins
> Issue Type: Patch
> Components: www
>Affects Versions: current
> Environment: Scientific Linux release 6.1 (Carbon)
> Apache httpd + mod_jk 1.2.32
> Jenkins ver. 1.452(install rpm)
>Reporter: Yoshihito Fukuyama
>Priority: Minor
> Attachments: CheckAJPAttributeValue.patch
>
>
> I used jenkins and apache httpd and mod_jk 1.2.32.
> Jenkins throws NullPointerException.
> mod_jk config:
> - mod_jk.conf
> {quote}
> JkWorkersFile conf/workers.properties
> JkMount /* jenkins
> {quote}
> - workers.properties
> {quote}
> worker.list=jenkins
> worker.jenkins.type=ajp13
> worker.jenkins.host=localhost
> worker.jenkins.port=8009
> {quote}
> jenkins:
> - log
> {quote}
> :
> Feb 29, 2012 1:11:07 PM hudson.WebAppMain$2 run
> INFO: Jenkins is fully up and running
> Feb 29, 2012 1:26:40 PM winstone.Logger logInternal
> SEVERE: Error within request handler thread
> java.lang.NullPointerException
>at java.util.Hashtable.put(Hashtable.java:411)
>at
> winstone.ajp13.Ajp13IncomingPacket.parsePacket(Ajp13IncomingPacket.java:163)
>at
> winstone.ajp13.Ajp13Listener.allocateRequestResponse(Ajp13Listener.java:184)
>at winstone.RequestHandlerThread.run(RequestHandlerThread.java:79)
>at java.lang.Thread.run(Thread.java:636)
> :
> {quote}
> mod_jk 1.2.32 sending null AJP request attribute value to server.
> workaround: configure LB worker to mod_jk.
> - workers.properties
> {quote}
> worker.list=jenkins
> worker.jenkins.type=lb
> worker.jenkins.balance_workers=jenkins1
> worker.jenkins1.type=ajp13
> worker.jenkins1.host=localhost
> worker.jenkins1.port=8009
> {quote}
> or use mod_jk 1.2.31.
--
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-12957) check AJP request attribute value is null.
[ https://issues.jenkins-ci.org/browse/JENKINS-12957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yoshihito Fukuyama updated JENKINS-12957: - Priority: Minor (was: Major) > check AJP request attribute value is null. > -- > > Key: JENKINS-12957 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12957 > Project: Jenkins > Issue Type: Patch > Components: www >Affects Versions: current > Environment: Scientific Linux release 6.1 (Carbon) > Apache httpd + mod_jk 1.2.32 > Jenkins ver. 1.452(install rpm) >Reporter: Yoshihito Fukuyama >Priority: Minor > Attachments: CheckAJPAttributeValue.patch > > > I used jenkins and apache httpd and mod_jk 1.2.32. > Jenkins throws NullPointerException. > mod_jk config: > mod_jk.conf > JkWorkersFile conf/workers.properties > JkMount /* jenkins > workers.properties > worker.list=jenkins > worker.jenkins.type=ajp13 > worker.jenkins.host=localhost > worker.jenkins.port=8009 > > jenkins log: > > : > Feb 29, 2012 1:11:07 PM hudson.WebAppMain$2 run > INFO: Jenkins is fully up and running > Feb 29, 2012 1:26:40 PM winstone.Logger logInternal > SEVERE: Error within request handler thread > java.lang.NullPointerException >at java.util.Hashtable.put(Hashtable.java:411) >at > winstone.ajp13.Ajp13IncomingPacket.parsePacket(Ajp13IncomingPacket.java:163) >at > winstone.ajp13.Ajp13Listener.allocateRequestResponse(Ajp13Listener.java:184) >at winstone.RequestHandlerThread.run(RequestHandlerThread.java:79) >at java.lang.Thread.run(Thread.java:636) > : > > mod_jk 1.2.32 sending null AJP request attribute value to server. > workaround: > configure LB worker to mod_jk. > workers.properties > worker.list=jenkins > worker.jenkins.type=lb > worker.jenkins.balance_workers=jenkins1 > worker.jenkins1.type=ajp13 > worker.jenkins1.host=localhost > worker.jenkins1.port=8009 > > or use mod_jk 1.2.31. -- 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-12957) check AJP request attribute value is null.
Yoshihito Fukuyama created JENKINS-12957: Summary: check AJP request attribute value is null. Key: JENKINS-12957 URL: https://issues.jenkins-ci.org/browse/JENKINS-12957 Project: Jenkins Issue Type: Patch Components: www Affects Versions: current Environment: Scientific Linux release 6.1 (Carbon) Apache httpd + mod_jk 1.2.32 Jenkins ver. 1.452(install rpm) Reporter: Yoshihito Fukuyama Attachments: CheckAJPAttributeValue.patch I used jenkins and apache httpd and mod_jk 1.2.32. Jenkins throws NullPointerException. mod_jk config: mod_jk.conf JkWorkersFile conf/workers.properties JkMount /* jenkins workers.properties worker.list=jenkins worker.jenkins.type=ajp13 worker.jenkins.host=localhost worker.jenkins.port=8009 jenkins log: : Feb 29, 2012 1:11:07 PM hudson.WebAppMain$2 run INFO: Jenkins is fully up and running Feb 29, 2012 1:26:40 PM winstone.Logger logInternal SEVERE: Error within request handler thread java.lang.NullPointerException at java.util.Hashtable.put(Hashtable.java:411) at winstone.ajp13.Ajp13IncomingPacket.parsePacket(Ajp13IncomingPacket.java:163) at winstone.ajp13.Ajp13Listener.allocateRequestResponse(Ajp13Listener.java:184) at winstone.RequestHandlerThread.run(RequestHandlerThread.java:79) at java.lang.Thread.run(Thread.java:636) : mod_jk 1.2.32 sending null AJP request attribute value to server. workaround: configure LB worker to mod_jk. workers.properties worker.list=jenkins worker.jenkins.type=lb worker.jenkins.balance_workers=jenkins1 worker.jenkins1.type=ajp13 worker.jenkins1.host=localhost worker.jenkins1.port=8009 or use mod_jk 1.2.31. -- 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-12956) Build all jobs that have not been built in N days
[ https://issues.jenkins-ci.org/browse/JENKINS-12956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Moncreaff updated JENKINS-12956: - Summary: Build all jobs that have not been built in N days (was: Build all jobs that have not been build in N days) > Build all jobs that have not been built in N days > - > > Key: JENKINS-12956 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12956 > Project: Jenkins > Issue Type: New Feature > Components: bulk-builder >Reporter: Greg Moncreaff >Assignee: Simon Westcott > > CONOPS - you've updated job configuration or backing scripts and you want to > sweep execute jobs that have not been run since your configuration change. -- 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-12956) Build all jobs that have not been build in N days
Greg Moncreaff created JENKINS-12956: Summary: Build all jobs that have not been build in N days Key: JENKINS-12956 URL: https://issues.jenkins-ci.org/browse/JENKINS-12956 Project: Jenkins Issue Type: New Feature Components: bulk-builder Reporter: Greg Moncreaff Assignee: Simon Westcott CONOPS - you've updated job configuration or backing scripts and you want to sweep execute jobs that have not been run since your configuration change. -- 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-12944) Env Inject Plugin doesn't substitute ${WORKSPACE} variable at all when used in 'Preparing an environment for the job'
[
https://issues.jenkins-ci.org/browse/JENKINS-12944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159732#comment-159732
]
SCM/JIRA link daemon commented on JENKINS-12944:
Code changed in jenkins
User: Gregory Boissinot
Path:
src/main/java/org/jenkinsci/plugins/envinject/service/EnvInjectVariableGetter.java
http://jenkins-ci.org/commit/envinject-plugin/1be2cee5f7bf55dfeb5c99525d181fa05d9faf02
Log:
Fix JENKINS-12944
> Env Inject Plugin doesn't substitute ${WORKSPACE} variable at all when used
> in 'Preparing an environment for the job'
> -
>
> Key: JENKINS-12944
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12944
> Project: Jenkins
> Issue Type: Bug
> Components: envinject
>Affects Versions: current
>Reporter: Joerg Schwaerzler
>Assignee: gbois
>
> Since we upgraded to EnvInject v1.30 we don't get our variable set if they
> are dependend on ${WORKSPACE}.
> Please check the job log snippet:
> --
> 11:02:12 [EnvInject] - Preparing an environment for the job.
> 11:02:12 [EnvInject] - Jenkins system variables are kept.
> 11:02:12 [EnvInject] - Jenkins build variables are kept.
> 11:02:12 [EnvInject] - Injecting as environment variables the properties
> content
> 11:02:12 HOME=${WORKSPACE}\home\muccctt1
> 11:02:12
> 11:02:12 [EnvInject] - Variables injected successfully.
> 11:02:12 [EnvInject] - Unset unresolved 'WORK_DRIVE' variable.
> 11:02:12 [EnvInject] - Unset unresolved 'HOME' variable.
--
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-12944) Env Inject Plugin doesn't substitute ${WORKSPACE} variable at all when used in 'Preparing an environment for the job'
[
https://issues.jenkins-ci.org/browse/JENKINS-12944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159731#comment-159731
]
SCM/JIRA link daemon commented on JENKINS-12944:
Code changed in jenkins
User: Gregory Boissinot
Path:
src/main/java/org/jenkinsci/plugins/envinject/EnvInjectListener.java
http://jenkins-ci.org/commit/envinject-plugin/f101df584bbf27af37a914bf27bcb206db2b97f5
Log:
Fix JENKINS-12944
> Env Inject Plugin doesn't substitute ${WORKSPACE} variable at all when used
> in 'Preparing an environment for the job'
> -
>
> Key: JENKINS-12944
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12944
> Project: Jenkins
> Issue Type: Bug
> Components: envinject
>Affects Versions: current
>Reporter: Joerg Schwaerzler
>Assignee: gbois
>
> Since we upgraded to EnvInject v1.30 we don't get our variable set if they
> are dependend on ${WORKSPACE}.
> Please check the job log snippet:
> --
> 11:02:12 [EnvInject] - Preparing an environment for the job.
> 11:02:12 [EnvInject] - Jenkins system variables are kept.
> 11:02:12 [EnvInject] - Jenkins build variables are kept.
> 11:02:12 [EnvInject] - Injecting as environment variables the properties
> content
> 11:02:12 HOME=${WORKSPACE}\home\muccctt1
> 11:02:12
> 11:02:12 [EnvInject] - Variables injected successfully.
> 11:02:12 [EnvInject] - Unset unresolved 'WORK_DRIVE' variable.
> 11:02:12 [EnvInject] - Unset unresolved 'HOME' variable.
--
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-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159730#comment-159730 ] Greg Moncreaff commented on JENKINS-12424: -- First job that had a build that violated the thresholds had this in the build splash page: Compiler Warnings: 392 warnings. 174 new warnings 139 fixed warnings Plug-in Result:Failed - 117 new warnings of priority Normal Priority exceed the threshold of 80 by 37 (Reference build: #21) build # 21 has Compiler Warnings: 359 warnings. I then remembered that this is not a total, but a priority check, and also that I have 'delta' checked for configuration of the check. build # 21 had 47 normals build # 24 has 164 normals 164 - 47 = 117 > 80 (the threshold) => Answer is OK. It just takes some getting used to. Regardless, Thank You so much for making this change!!! - Is it possible to do something like highlight some text in the justification and link it to the data grids? e.g. (slightly rewording it) 117 New Normal Priority Warnings exceed the threshold of 80 by 37 (Reference build: #21) where the link navigates you to build # >> Compiler Warnings » New Warnings and selects the Normal priority tab? > More correct and specific build state change reasons from Warnings > --- > > Key: JENKINS-12424 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 > Project: Jenkins > Issue Type: Improvement > Components: analysis-core, warnings >Reporter: Greg Moncreaff >Assignee: Ulli Hafner >Priority: Minor > > I got this in my jobs console. > [WARNINGS] Setting build status to FAILURE since total number of annotations > exceeds the threshold 200: [HIGH, NORMAL, LOW] > Two issues. > 1. text says total, but this was actually a "compute status since reference > build (new) gate. > 2. text should say which specific criteria was exceeded > 3. it doesn't tell you what the actual number/difference was > E.g. > [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH > annotations exceeds the threshold of 200 by 34 or 17%. -- 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-12955) Stylecop file report is blank
[ https://issues.jenkins-ci.org/browse/JENKINS-12955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Bristol updated JENKINS-12955: - Description: Clicking file link in a stylecop violations report page takes you to an empty file report page. I am using Jenkins ver. 1.452 and violations plugin 0.7.10 in 2 environments, windows 2003 server and windows 2008 server. It seems that the violating file xml is missing line elements. I added some dummy line elements to the xml and the page then rendered fine. was: Clicking file link in a stylecop violations report page takes you to an empty file report page. I am using Jenkins ver. 1.452 and violations plugin 0.7.10 in 2 environments, windows 2003 server and windows 2008 server. It seems that the violating file xml is missing line elements. I added some dummy lines and the page then rendered fine. > Stylecop file report is blank > - > > Key: JENKINS-12955 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12955 > Project: Jenkins > Issue Type: Bug > Components: violations >Affects Versions: current >Reporter: Marcus Bristol >Assignee: peterkittreilly >Priority: Minor > Labels: plugin > > Clicking file link in a stylecop violations report page takes you to an empty > file report page. > I am using Jenkins ver. 1.452 and violations plugin 0.7.10 in 2 environments, > windows 2003 server and windows 2008 server. > It seems that the violating file xml is missing line elements. I added some > dummy line elements to the xml and the page then rendered fine. -- 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-12955) Stylecop file report is blank
Marcus Bristol created JENKINS-12955: Summary: Stylecop file report is blank Key: JENKINS-12955 URL: https://issues.jenkins-ci.org/browse/JENKINS-12955 Project: Jenkins Issue Type: Bug Components: violations Affects Versions: current Reporter: Marcus Bristol Assignee: peterkittreilly Priority: Minor Clicking file link in a stylecop violations report page takes you to an empty file report page. I am using Jenkins ver. 1.452 and violations plugin 0.7.10 in 2 environments, windows 2003 server and windows 2008 server. It seems that the violating file xml is missing line elements. I added some dummy lines and the page then rendered fine. -- 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-12912) URLTtrigger does not poll on jobs which are tied to disconnected slaves
[
https://issues.jenkins-ci.org/browse/JENKINS-12912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159729#comment-159729
]
OHTAKE Tomohiro commented on JENKINS-12912:
---
It is sufficient for me, but I think "[checkbox] Poll on other node [textbox]"
would be more generic. Someone would like to poll on 'remote1-small-instance'
and tie to 'remote2-large-instance'.
> URLTtrigger does not poll on jobs which are tied to disconnected slaves
> ---
>
> Key: JENKINS-12912
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12912
> Project: Jenkins
> Issue Type: Bug
> Components: urltrigger
> Environment: Jenkins 1.451
> URLTrigger Plugin 0.10, 0.14
>Reporter: OHTAKE Tomohiro
>Assignee: gbois
>
> Since 0.10, URLTtrigger does not poll on jobs which are tied to disconnected
> slaves even if there are available executors on master.
> URLTrigger Plugin 0.9 makes master poll the URL even if the jobs are tied to
> slaves.
> If there are changes in URL, a slave that is tied to the job wakes up and
> runs the job.
> URLTrigger 0.9 says that polling has been done on slaves, but master polles.
> {code:title=URLTrigger Log (0.14, job which is tied to disconnected slaves)}
> Polling for the job aa
> Searching a node to run the polling for the label ''.
> Can't find any complete active node for the polling action. Maybe slaves are
> not yet active at this time or the number of executor of the master is 0.
> Checking again in next polling schedule.
> {code}
> {code:title=URLTrigger Log (0.14, job which is not tied to any slaves)}
> Polling for the job bb
> Polling on master.
> Polling started on Feb 28, 2012 10:22:42 AM
> Invoking the url:
> http://aaa.invalid/bb
> Inspecting the content
> Polling complete. Took 0.12 sec.
> No changes.
> {code}
> {code:title=URLTrigger Log (0.9, job which is tied to disconnected slaves)}
> Polling started on Feb 28, 2012 10:51:04 AM
> Searching a node to run the polling for the label ''.
> Invoking the url:
> http://aaa.invalid/bb
> Inspecting the content
> Polling complete. Took 0.14 sec
> No changes.
> {code}
> Workarounds:
> * Downgrade URLTrigger Plugin to 0.9
> * Do not tie jobs which uses Use URLTrigger
> ** Create a job that uses URLTrigger and do not tie the job to any slaves.
> ** Configure the job to build other projects in its post-build 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-12954) Configure accurev server per Jenkins node
pickgr1 created JENKINS-12954: - Summary: Configure accurev server per Jenkins node Key: JENKINS-12954 URL: https://issues.jenkins-ci.org/browse/JENKINS-12954 Project: Jenkins Issue Type: New Feature Components: accurev Environment: Ubuntu 10.04.04 - Jenkins LTS Reporter: pickgr1 Assignee: Scott Tatum There may be a way to configure this already that I'm overlooking somewhere, but if not, this would be a great feature. In the Jenkins global configuration, it's possible to add multiple servers (replicas) We have replicas that are geographically diverse across a corporate WAN. For example, we have Jenkins nodes/slaves at both site A and site B. Each site also has it's own AccuRev replica. So we want nodes at site A to use their local AccuRev replica and nodes at site B use their local replica. I see that it's possible to configure this on a per-job basis, but what we really need is a per node/slave basis. Otherwise, we have to maintain separate jobs for each site. -- 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-12186) warnings per project dashboard portlet should allow un-used columns to be turned off, same as warnings trend (type distribution does)
[ https://issues.jenkins-ci.org/browse/JENKINS-12186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159728#comment-159728 ] Greg Moncreaff commented on JENKINS-12186: -- I think the open tasks filter isn't working. It is always missing from the table regardless of the checkbox? > warnings per project dashboard portlet should allow un-used columns to be > turned off, same as warnings trend (type distribution does) > - > > Key: JENKINS-12186 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12186 > Project: Jenkins > Issue Type: Improvement > Components: analysis-collector >Affects Versions: current >Reporter: Greg Moncreaff >Assignee: Ulli Hafner > > E.g. if you aren't looking at Java code, then Findbugs and Checkstyle and PMD > don't have any value. > When new things are tied into analysis core, it will be even more important > to allow reasonable display filtering -- 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-6681) Maven-generated site link gives 404
[ https://issues.jenkins-ci.org/browse/JENKINS-6681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159727#comment-159727 ] Peter Johnson edited comment on JENKINS-6681 at 3/1/12 11:38 PM: - I'm having this same issue with Jenkins 1.446 and Maven 3.0.3. I have found that if I set up the Jenkins job to run "mvn deploy site", then the Maven generated site link is broke and I need to append the artifactId to the URL. I also notice in the jobs/job_name/site directory that there is an artifactId subdirectory and the site contents are in there rather than in the site directory. However, if I run "mvn package deploy", the Maven generated site link works just fine. Furthermore, all of the files that previously appeared in jobs/job_name/site/artifactId now appear in jobs/job_name/site. I checked the workspace/job_name/site directory in both cases, and both times the site files, including index.html, were generated in that directory. Jenkins copies the site files from workspace/job_name/site, so why, with the exact same mvn pom.xml, doing the same build, does Jenkins in one case copy the generated site to one location, and in the other case copies the site to a different location? So I disagree very much with evernat - there is an index.html file, it was generated in both cases. The behavior points to a Jenkins problem. was (Author: cafed00d): I'm having this same issue with Jenkins 1.446 and Maven 3.0.3. I have found that if I set up the Jenkins job to run "mvn deploy site", then the Maven generated site link is broke and I need to append the artifactId to the URL. I also notice in the jobs/job_name/site directory that there is an artifactId subdirectory and the site contents are in there rather than in the site directory. However, if I run "mvn package deploy", the Maven generated site link works just fine. Furthermore, all of the files that previously appeared in jobs/job_name/site/artifactId now appear in jobs/job_name/site. I checked the workspace/job_name/site directory in both cases, and both times the site files, including index.html, were generated in that directory. Jenkins copies the site files from workspace/job_name/site, so why, with the exact same mvn pom.xml, doing the same build, does Jenkins in one case place the generated site in one location, and in the other case place the site in a different location? So I disagree very much with evernat - there is an index.html file, it was generated in both cases. The behavior point to a Jenkins problem. > Maven-generated site link gives 404 > --- > > Key: JENKINS-6681 > URL: https://issues.jenkins-ci.org/browse/JENKINS-6681 > Project: Jenkins > Issue Type: Bug > Components: maven2 >Affects Versions: current >Reporter: adico > > After running goals "clean install site" in a Maven2 build, project home page > shows a link called "Maven-generated site". This links gives a 404 because it > is missing project-info.html off the end of the URL. -- 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-6681) Maven-generated site link gives 404
[ https://issues.jenkins-ci.org/browse/JENKINS-6681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159727#comment-159727 ] Peter Johnson commented on JENKINS-6681: I'm having this same issue with Jenkins 1.446 and Maven 3.0.3. I have found that if I set up the Jenkins job to run "mvn deploy site", then the Maven generated site link is broke and I need to append the artifactId to the URL. I also notice in the jobs/job_name/site directory that there is an artifactId subdirectory and the site contents are in there rather than in the site directory. However, if I run "mvn package deploy", the Maven generated site link works just fine. Furthermore, all of the files that previously appeared in jobs/job_name/site/artifactId now appear in jobs/job_name/site. I checked the workspace/job_name/site directory in both cases, and both times the site files, including index.html, were generated in that directory. Jenkins copies the site files from workspace/job_name/site, so why, with the exact same mvn pom.xml, doing the same build, does Jenkins in one case place the generated site in one location, and in the other case place the site in a different location? So I disagree very much with evernat - there is an index.html file, it was generated in both cases. The behavior point to a Jenkins problem. > Maven-generated site link gives 404 > --- > > Key: JENKINS-6681 > URL: https://issues.jenkins-ci.org/browse/JENKINS-6681 > Project: Jenkins > Issue Type: Bug > Components: maven2 >Affects Versions: current >Reporter: adico > > After running goals "clean install site" in a Maven2 build, project home page > shows a link called "Maven-generated site". This links gives a 404 because it > is missing project-info.html off the end of the URL. -- 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-12952) Job stuck sending failure email -- perforce plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-12952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159726#comment-159726 ] Rob Petti commented on JENKINS-12952: - Are all of your perforce-based jobs operable? As in, do the configurations for them work? > Job stuck sending failure email -- perforce plugin > -- > > Key: JENKINS-12952 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12952 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current > Environment: jenkins 1.452 > perforce plugin 1.3.8 (and 1.3.9 although i installed manually) > ubuntu 11.10 master > mac (snow leopard) slaves >Reporter: Robert Sparks >Assignee: Rob Petti > > Very similar to https://issues.jenkins-ci.org/browse/JENKINS-12672. > We have your fix for bug 12672 but we are experiencing hangs forever while > trying to send emails to individuals that broke the build. > We use the "Send separate e-mails to individuals who broke the build" option > under "E-mail Notification". > Problem occurs 100% of the time in our particular configuration. > We consistently get the following stack: > "Executor #0 for mac_1 : executing our-job-name #3450" Id=39 Group=main > TIMED_WAITING on [B@5b195a44 > at java.lang.Object.wait(Native Method) > - waiting on [B@5b195a44 > at > hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:173) > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283) > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177) > - locked java.io.InputStreamReader@2466d4bf > at java.io.InputStreamReader.read(InputStreamReader.java:184) > at java.io.BufferedReader.fill(BufferedReader.java:154) > at java.io.BufferedReader.readLine(BufferedReader.java:317) > - locked java.io.InputStreamReader@2466d4bf > at java.io.BufferedReader.readLine(BufferedReader.java:382) > at > com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:330) > at > com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:292) > at com.tek42.perforce.parse.Users.exists(Users.java:61) > at com.tek42.perforce.parse.Users.getUser(Users.java:54) > at > hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:64) > at > hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:100) > at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:514) > at hudson.tasks.MailSender.buildCulpritList(MailSender.java:404) > at hudson.tasks.MailSender.createEmptyMail(MailSender.java:364) > at hudson.tasks.MailSender.createFailureMail(MailSender.java:223) > at hudson.tasks.MailSender.getMail(MailSender.java:150) > at hudson.tasks.MailSender.execute(MailSender.java:98) > at hudson.tasks.Mailer.perform(Mailer.java:111) > 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:1433) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceCon > Thanks > Rob -- 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-12952) Job stuck sending failure email -- perforce plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-12952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Petti reassigned JENKINS-12952: --- Assignee: Rob Petti > Job stuck sending failure email -- perforce plugin > -- > > Key: JENKINS-12952 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12952 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current > Environment: jenkins 1.452 > perforce plugin 1.3.8 (and 1.3.9 although i installed manually) > ubuntu 11.10 master > mac (snow leopard) slaves >Reporter: Robert Sparks >Assignee: Rob Petti > > Very similar to https://issues.jenkins-ci.org/browse/JENKINS-12672. > We have your fix for bug 12672 but we are experiencing hangs forever while > trying to send emails to individuals that broke the build. > We use the "Send separate e-mails to individuals who broke the build" option > under "E-mail Notification". > Problem occurs 100% of the time in our particular configuration. > We consistently get the following stack: > "Executor #0 for mac_1 : executing our-job-name #3450" Id=39 Group=main > TIMED_WAITING on [B@5b195a44 > at java.lang.Object.wait(Native Method) > - waiting on [B@5b195a44 > at > hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:173) > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283) > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177) > - locked java.io.InputStreamReader@2466d4bf > at java.io.InputStreamReader.read(InputStreamReader.java:184) > at java.io.BufferedReader.fill(BufferedReader.java:154) > at java.io.BufferedReader.readLine(BufferedReader.java:317) > - locked java.io.InputStreamReader@2466d4bf > at java.io.BufferedReader.readLine(BufferedReader.java:382) > at > com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:330) > at > com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:292) > at com.tek42.perforce.parse.Users.exists(Users.java:61) > at com.tek42.perforce.parse.Users.getUser(Users.java:54) > at > hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:64) > at > hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:100) > at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:514) > at hudson.tasks.MailSender.buildCulpritList(MailSender.java:404) > at hudson.tasks.MailSender.createEmptyMail(MailSender.java:364) > at hudson.tasks.MailSender.createFailureMail(MailSender.java:223) > at hudson.tasks.MailSender.getMail(MailSender.java:150) > at hudson.tasks.MailSender.execute(MailSender.java:98) > at hudson.tasks.Mailer.perform(Mailer.java:111) > 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:1433) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceCon > Thanks > Rob -- 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-8082) git plugin multi-repo can't work
[ https://issues.jenkins-ci.org/browse/JENKINS-8082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159725#comment-159725 ] abayer commented on JENKINS-8082: - They opted to go in a different direction - as I said, I'm happily using the Multiple SCMs plugin to do this, without needing changes to the git plugin. > git plugin multi-repo can't work > > > Key: JENKINS-8082 > URL: https://issues.jenkins-ci.org/browse/JENKINS-8082 > Project: Jenkins > Issue Type: Bug > Components: git >Affects Versions: current > Environment: git plugin 1.1 >Reporter: bwilliams >Assignee: abayer > > In the git plugin, you have the ability to watch multiple repos, but then you > clone them into the same dir, so the git checkouts show you all of one repo, > but not the others. > The "local subdirectory for repo" and probably "branches to build" need to be > per repository, not for all. -- 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-12953) SVN Tag failing even though the Remote Module Location & Tag Base URL values are correct
Suresh Kurra created JENKINS-12953: -- Summary: SVN Tag failing even though the Remote Module Location & Tag Base URL values are correct Key: JENKINS-12953 URL: https://issues.jenkins-ci.org/browse/JENKINS-12953 Project: Jenkins Issue Type: Bug Components: svn-tag Affects Versions: current Environment: Jenkins 1.452 on AIX 6.1.0.1 with Jenkins Subversion Plugin 1.39 and Jenkins Subversion Tagging Plugin 1.16 with IBM JRE 1.6.0 Reporter: Suresh Kurra Assignee: k2nakamura BUILD SUCCESSFUL Total time: 11 seconds Remote Module Location: https://SVNSERVERHOSTNAME/svn/SVNPROJECTNAME/trunk@1020. Tag Base URL: https://SVNSERVERHOSTNAME/svn/SVNPROJECTNAME/tags/TemporaryTag_by_Jenkins. There was no old tag at https://SVNSERVERHOSTNAME/svn/SVNPROJECTNAME/tags/TemporaryTag_by_Jenkins. Subversion copy failed. svn: File not found: revision 1020, path '/trunk/trunk' svn: '/svn/SVNPROJECTNAME/!svn/bc/1020/trunk' path not found: 404 Not Found (https://SVNSERVERHOSTNAME) Build step 'Perform Subversion tagging on successful build' marked build as failure Finished: SUCCESS https://SVNSERVERHOSTNAME/svn/SVNPROJECTNAME/!svn/bc/1020/trunk/ works fine in browser as URL and I can see the contents fine. Command line Subversion Tagging works fine with the same Remote Module Location & Tag Base URL values. I don't understand where it's picking up '/trunk/trunk' -- 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-8082) git plugin multi-repo can't work
[ https://issues.jenkins-ci.org/browse/JENKINS-8082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159724#comment-159724 ] crwong commented on JENKINS-8082: - I am not sure I understand why this is marked as "Won't Fix". The Hudson version of the git plugin is marked as "Fixed". I have one project that has its source in one repo and the framework that it uses in another repo, and I would like to be able to use the plugin to pull both the source for the project and the source for the framework. > git plugin multi-repo can't work > > > Key: JENKINS-8082 > URL: https://issues.jenkins-ci.org/browse/JENKINS-8082 > Project: Jenkins > Issue Type: Bug > Components: git >Affects Versions: current > Environment: git plugin 1.1 >Reporter: bwilliams >Assignee: abayer > > In the git plugin, you have the ability to watch multiple repos, but then you > clone them into the same dir, so the git checkouts show you all of one repo, > but not the others. > The "local subdirectory for repo" and probably "branches to build" need to be > per repository, not for all. -- 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-12952) Job stuck sending failure email -- perforce plugin
Robert Sparks created JENKINS-12952: --- Summary: Job stuck sending failure email -- perforce plugin Key: JENKINS-12952 URL: https://issues.jenkins-ci.org/browse/JENKINS-12952 Project: Jenkins Issue Type: Bug Components: perforce Affects Versions: current Environment: jenkins 1.452 perforce plugin 1.3.8 (and 1.3.9 although i installed manually) ubuntu 11.10 master mac (snow leopard) slaves Reporter: Robert Sparks Very similar to https://issues.jenkins-ci.org/browse/JENKINS-12672. We have your fix for bug 12672 but we are experiencing hangs forever while trying to send emails to individuals that broke the build. We use the "Send separate e-mails to individuals who broke the build" option under "E-mail Notification". Problem occurs 100% of the time in our particular configuration. We consistently get the following stack: "Executor #0 for mac_1 : executing our-job-name #3450" Id=39 Group=main TIMED_WAITING on [B@5b195a44 at java.lang.Object.wait(Native Method) - waiting on [B@5b195a44 at hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:173) at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283) at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177) - locked java.io.InputStreamReader@2466d4bf at java.io.InputStreamReader.read(InputStreamReader.java:184) at java.io.BufferedReader.fill(BufferedReader.java:154) at java.io.BufferedReader.readLine(BufferedReader.java:317) - locked java.io.InputStreamReader@2466d4bf at java.io.BufferedReader.readLine(BufferedReader.java:382) at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:330) at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:292) at com.tek42.perforce.parse.Users.exists(Users.java:61) at com.tek42.perforce.parse.Users.getUser(Users.java:54) at hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:64) at hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:100) at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:514) at hudson.tasks.MailSender.buildCulpritList(MailSender.java:404) at hudson.tasks.MailSender.createEmptyMail(MailSender.java:364) at hudson.tasks.MailSender.createFailureMail(MailSender.java:223) at hudson.tasks.MailSender.getMail(MailSender.java:150) at hudson.tasks.MailSender.execute(MailSender.java:98) at hudson.tasks.Mailer.perform(Mailer.java:111) 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:1433) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceCon Thanks Rob -- 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-12076) m2 Release Plugin lock builds
[ https://issues.jenkins-ci.org/browse/JENKINS-12076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159723#comment-159723 ] dogfood commented on JENKINS-12076: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_m2release #69|http://ci.jenkins-ci.org/job/plugins_m2release/69/] [FIXED JENKINS-12076] Add the ability to specify the number of release builds to keep. (Revision 82e9e2c2fbdae06a4d04700ed5cf0bdcea9c8ce8) Result = SUCCESS James Nord : Files : * src/main/resources/org/jvnet/hudson/plugins/m2release/M2ReleaseBuildWrapper/config.jelly * src/main/java/org/jvnet/hudson/plugins/m2release/M2ReleaseBuildWrapper.java * src/main/webapp/help-projectConfig-help-numberOfReleaseBuildsToKeep.html * src/test/java/org/jvnet/hudson/plugins/m2release/M2ReleaseActionTest.java > m2 Release Plugin lock builds > - > > Key: JENKINS-12076 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12076 > Project: Jenkins > Issue Type: New Feature > Components: m2release >Affects Versions: current > Environment: Any >Reporter: Terry Sposato >Assignee: teilo >Priority: Trivial > > Is it possible to have a configurable option per job to always keep a m2 > release build locked. > At the moment only the latest release build stays locked... -- 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-12895) automatically drop nexus stage if build fails
[ https://issues.jenkins-ci.org/browse/JENKINS-12895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159721#comment-159721 ] dogfood commented on JENKINS-12895: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_m2release #69|http://ci.jenkins-ci.org/job/plugins_m2release/69/] [FIXED JENKINS-12895] Drop stage if build is not a success. (Revision ef2ee3a76c17667f5bf130af529f4d92f9998596) Result = SUCCESS James Nord : Files : * src/main/java/org/jvnet/hudson/plugins/m2release/M2ReleaseBuildWrapper.java > automatically drop nexus stage if build fails > - > > Key: JENKINS-12895 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12895 > Project: Jenkins > Issue Type: New Feature > Components: m2release >Reporter: teilo >Assignee: teilo > > if a build fails and is using nexus staging - then drop the stage -- 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-10042) When closing stage failes the plugin causes an exception
[ https://issues.jenkins-ci.org/browse/JENKINS-10042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159722#comment-159722 ] dogfood commented on JENKINS-10042: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_m2release #69|http://ci.jenkins-ci.org/job/plugins_m2release/69/] [FIXED JENKINS-10042] recreate logger on deserialisation. (Revision aeabbd9b71fdc0fa3aeb724d6f7e582b98a937fe) Result = SUCCESS James Nord : Files : * src/main/java/org/jvnet/hudson/plugins/m2release/M2ReleaseBuildWrapper.java > When closing stage failes the plugin causes an exception > > > Key: JENKINS-10042 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10042 > Project: Jenkins > Issue Type: Bug > Components: m2release >Reporter: teilo >Assignee: teilo > > When a promotion of a build fails (due to staging validation rules) the > plugin dumps stack. > [M2Release] Closing repository Stage[profileId=40365b31e0dc2b, > stageId=release_staging_profile-418 > FATAL: [M2Release] Could not close repository , StageException > org.jvnet.hudson.plugins.m2release.nexus.StageException: Failed to perform > CLOSE action to nexus stage(Stage[profileId=40365b31e0dc2b, > stageId=release_staging_profile-418) > ERROR: Processing failed due to a bug in the code. Please report this to > jenkinsci-us...@googlegroups.com > java.lang.NullPointerException > at > org.jvnet.hudson.plugins.m2release.M2ReleaseBuildWrapper$2.tearDown(M2ReleaseBuildWrapper.java:198) > at > hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:754) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:429) > at hudson.model.Run.run(Run.java:1374) > at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:467) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:145) > THis can be reproduced if you have validation rules on closing a stage (for > instance artifact uniqueness where a release version already exists) -- 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-12076) m2 Release Plugin lock builds
[ https://issues.jenkins-ci.org/browse/JENKINS-12076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159720#comment-159720 ] SCM/JIRA link daemon commented on JENKINS-12076: Code changed in jenkins User: James Nord Path: src/main/java/org/jvnet/hudson/plugins/m2release/M2ReleaseBuildWrapper.java src/main/resources/org/jvnet/hudson/plugins/m2release/M2ReleaseBuildWrapper/config.jelly src/main/webapp/help-projectConfig-help-numberOfReleaseBuildsToKeep.html src/test/java/org/jvnet/hudson/plugins/m2release/M2ReleaseActionTest.java http://jenkins-ci.org/commit/m2release-plugin/82e9e2c2fbdae06a4d04700ed5cf0bdcea9c8ce8 Log: [FIXED JENKINS-12076] Add the ability to specify the number of release builds to keep. If the number is -1 then all builds are kept. a positive number will keep that many sucessfull release builds. Any other number (< -1 or 0) will cause no release builds to be kept. Compare: https://github.com/jenkinsci/m2release-plugin/compare/18712bd...82e9e2c > m2 Release Plugin lock builds > - > > Key: JENKINS-12076 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12076 > Project: Jenkins > Issue Type: New Feature > Components: m2release >Affects Versions: current > Environment: Any >Reporter: Terry Sposato >Assignee: teilo >Priority: Trivial > > Is it possible to have a configurable option per job to always keep a m2 > release build locked. > At the moment only the latest release build stays locked... -- 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-12895) automatically drop nexus stage if build fails
[ https://issues.jenkins-ci.org/browse/JENKINS-12895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-12895. Resolution: Fixed > automatically drop nexus stage if build fails > - > > Key: JENKINS-12895 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12895 > Project: Jenkins > Issue Type: New Feature > Components: m2release >Reporter: teilo >Assignee: teilo > > if a build fails and is using nexus staging - then drop the stage -- 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-12076) m2 Release Plugin lock builds
[ https://issues.jenkins-ci.org/browse/JENKINS-12076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-12076. Resolution: Fixed > m2 Release Plugin lock builds > - > > Key: JENKINS-12076 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12076 > Project: Jenkins > Issue Type: New Feature > Components: m2release >Affects Versions: current > Environment: Any >Reporter: Terry Sposato >Assignee: teilo >Priority: Trivial > > Is it possible to have a configurable option per job to always keep a m2 > release build locked. > At the moment only the latest release build stays locked... -- 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-10042) When closing stage failes the plugin causes an exception
[ https://issues.jenkins-ci.org/browse/JENKINS-10042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-10042. Resolution: Fixed > When closing stage failes the plugin causes an exception > > > Key: JENKINS-10042 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10042 > Project: Jenkins > Issue Type: Bug > Components: m2release >Reporter: teilo >Assignee: teilo > > When a promotion of a build fails (due to staging validation rules) the > plugin dumps stack. > [M2Release] Closing repository Stage[profileId=40365b31e0dc2b, > stageId=release_staging_profile-418 > FATAL: [M2Release] Could not close repository , StageException > org.jvnet.hudson.plugins.m2release.nexus.StageException: Failed to perform > CLOSE action to nexus stage(Stage[profileId=40365b31e0dc2b, > stageId=release_staging_profile-418) > ERROR: Processing failed due to a bug in the code. Please report this to > jenkinsci-us...@googlegroups.com > java.lang.NullPointerException > at > org.jvnet.hudson.plugins.m2release.M2ReleaseBuildWrapper$2.tearDown(M2ReleaseBuildWrapper.java:198) > at > hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:754) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:429) > at hudson.model.Run.run(Run.java:1374) > at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:467) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:145) > THis can be reproduced if you have validation rules on closing a stage (for > instance artifact uniqueness where a release version already exists) -- 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-10042) When closing stage failes the plugin causes an exception
[ https://issues.jenkins-ci.org/browse/JENKINS-10042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159719#comment-159719 ] SCM/JIRA link daemon commented on JENKINS-10042: Code changed in jenkins User: James Nord Path: src/main/java/org/jvnet/hudson/plugins/m2release/M2ReleaseBuildWrapper.java http://jenkins-ci.org/commit/m2release-plugin/aeabbd9b71fdc0fa3aeb724d6f7e582b98a937fe Log: [FIXED JENKINS-10042] recreate logger on deserialisation. > When closing stage failes the plugin causes an exception > > > Key: JENKINS-10042 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10042 > Project: Jenkins > Issue Type: Bug > Components: m2release >Reporter: teilo >Assignee: teilo > > When a promotion of a build fails (due to staging validation rules) the > plugin dumps stack. > [M2Release] Closing repository Stage[profileId=40365b31e0dc2b, > stageId=release_staging_profile-418 > FATAL: [M2Release] Could not close repository , StageException > org.jvnet.hudson.plugins.m2release.nexus.StageException: Failed to perform > CLOSE action to nexus stage(Stage[profileId=40365b31e0dc2b, > stageId=release_staging_profile-418) > ERROR: Processing failed due to a bug in the code. Please report this to > jenkinsci-us...@googlegroups.com > java.lang.NullPointerException > at > org.jvnet.hudson.plugins.m2release.M2ReleaseBuildWrapper$2.tearDown(M2ReleaseBuildWrapper.java:198) > at > hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:754) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:429) > at hudson.model.Run.run(Run.java:1374) > at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:467) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:145) > THis can be reproduced if you have validation rules on closing a stage (for > instance artifact uniqueness where a release version already exists) -- 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-12895) automatically drop nexus stage if build fails
[ https://issues.jenkins-ci.org/browse/JENKINS-12895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159718#comment-159718 ] SCM/JIRA link daemon commented on JENKINS-12895: Code changed in jenkins User: James Nord Path: src/main/java/org/jvnet/hudson/plugins/m2release/M2ReleaseBuildWrapper.java http://jenkins-ci.org/commit/m2release-plugin/ef2ee3a76c17667f5bf130af529f4d92f9998596 Log: [FIXED JENKINS-12895] Drop stage if build is not a success. > automatically drop nexus stage if build fails > - > > Key: JENKINS-12895 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12895 > Project: Jenkins > Issue Type: New Feature > Components: m2release >Reporter: teilo >Assignee: teilo > > if a build fails and is using nexus staging - then drop the stage -- 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-4958) add switch for -DdryRun=true
[ https://issues.jenkins-ci.org/browse/JENKINS-4958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] teilo resolved JENKINS-4958. Resolution: Fixed fixed in 0.9.1 > add switch for -DdryRun=true > > > Key: JENKINS-4958 > URL: https://issues.jenkins-ci.org/browse/JENKINS-4958 > Project: Jenkins > Issue Type: Improvement > Components: m2release >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: skybird >Assignee: teilo > > It would be nice to have a checkbox on the release page which allows a dryRun > bevore a release to check if everything is working or to test configuration > changes. > If the checkbox is activated, simply -DdryRun=true should be appended to the > build parameters. -- 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-12651) Possibility to select whether to save build or not on m2release
[ https://issues.jenkins-ci.org/browse/JENKINS-12651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] teilo resolved JENKINS-12651. - Resolution: Duplicate Duplicate of JENKINS-12076 > Possibility to select whether to save build or not on m2release > --- > > Key: JENKINS-12651 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12651 > Project: Jenkins > Issue Type: Improvement > Components: m2release >Affects Versions: current >Reporter: Roland Asmann >Assignee: teilo >Priority: Minor > > We would like to be able to set whether or not we want to save the release > builds in Jenkins. > Optimally we would like to have this configurable in the main Jenkins > configuration with the possibility to override in the jobs themselves. -- 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-12894) Building a scheme including multiple static library test targets fails under jenkins but works with xcodebuild from cli
[ https://issues.jenkins-ci.org/browse/JENKINS-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Héritier closed JENKINS-12894. - > Building a scheme including multiple static library test targets fails under > jenkins but works with xcodebuild from cli > --- > > Key: JENKINS-12894 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12894 > Project: Jenkins > Issue Type: Bug > Components: xcode >Affects Versions: current > Environment: OSX lion server > jenkins 1.450 > xcode 4.2 > plugin 1.3 > glassfish 3.1 host >Reporter: ian carr >Priority: Blocker > > I have an XCode workspace with several projects, each building a static > library target. Each library with it's own test target. > I have created a scheme containing each of the 7 test targets each selected > for build, test, run (7 targets in all) > (parralel building is disabled in this scheme.) > Checking out this workspace from git and running a manual xcodebuild and > setting TEST_AFTER_BUILD completes the build successfully and runs the tests. > I have also configured a jenkins build for this same workspace and scheme. > Most of the targets build, but one generates compile errors when compiling > the test target. The failures indicate redefinitions of objective c interfaces > indicating multiple inclusions of header files. Since these files are > #imported and not #included there should be no multiple-inclusion. And as > mentioned > in XCode or from a manual run of xcodebuild these errors are not appearing. > I am wondering whether there are some additional environment variables being > set in the jenkins invocation? > or perhaps the mutiple target scheme is not supported? -- 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-12936) EnvInject Plugin 1.30 does not display all properties on job config page
[
https://issues.jenkins-ci.org/browse/JENKINS-12936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159715#comment-159715
]
mwebber commented on JENKINS-12936:
---
Thanks. 1.31 isn't released yet, will it be soon?
> EnvInject Plugin 1.30 does not display all properties on job config page
>
>
> Key: JENKINS-12936
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12936
> Project: Jenkins
> Issue Type: Bug
> Components: envinject
>Reporter: mwebber
>Assignee: gbois
>
> I upgraded from EnvInject Plugin 1.28 to 1.30. The result was that, for some
> jobs, variables I have previously defined are not displayed on the job
> configuration page.
> This is where I have selected "Inject environment variables to the build
> process", and have entries in the "Properties Content" box. Even though the
> entries are on teh job config file, they are not always displayed in the
> "Properties Content" box.
> When the config.xml looks like this, the "Properties Content" box IS
> correctly populated:
> {noformat}
>
>
> branchTagPath=v0.9
> false
>
>
> {noformat}
> When the config.xml looks like this, the "Properties Content" box s
> incorrectly displays EMPTY:
> {noformat}
>
>
>
>
> materialize_component
> sda
>
>
> materialize_category
> sda
>
>
> materialize_version
> v0.9
>
>
> materialize_workspace_path
> ${WORKSPACE}/materialize_workspace
>
>
> false
>
>
> {noformat}
--
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-12951) Freestyle job 'Invoke Maven 3' build step can't find maven home for Maven installation installed from Apache Archives
Andrew Fannin created JENKINS-12951: --- Summary: Freestyle job 'Invoke Maven 3' build step can't find maven home for Maven installation installed from Apache Archives Key: JENKINS-12951 URL: https://issues.jenkins-ci.org/browse/JENKINS-12951 Project: Jenkins Issue Type: Bug Components: maven Affects Versions: current Environment: Jenkins 1.424.3 Ubuntu 10.04.2 LTS Tomcat 6 Reporter: Andrew Fannin Out of the blue, with really no explanation, our freestyle projects which use the 'Invoke Maven 3' began throwing the following error when attempting to invoke the Maven 3 step: ERROR: Maven 'Maven3' doesn't have its home set Finished: FAILURE Where 'Maven3' is the name of the Maven installation configured to 'Install from Apache' version 3.0.4 Nothing in the logs to indicate a problem. I've deleted and re-added the Maven installation as well as creating new ones with different versions. Even went as far a blowing away the Tomcat context and redeploying still nothing. Maven 2/3 projects still work fine. Not completely convinced the Jenkins-Artifactory plugin doesn't have something to do with this; I have tested this issue in isolation, using only svn checkout and 'Invoke Maven 3', but wonder if the Artifactory plugin may be wrapping the job anyway. -- 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-12950) pom.xml not deploying to Artifactory
[ https://issues.jenkins-ci.org/browse/JENKINS-12950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry Thome updated JENKINS-12950: -- I stumbled across someone else who ran into this issue. The work-around was to run 'mvn install'. Somehow, this created the right chain of events for the upload to work correctly. It seems to me, that as long as the JAR and POM are in the standard maven locations, the deploy should work correctly (from a user experience perspective). I did not see any documentation which directed Maven users to first run an install. I guess, if this plug-in is strategically replacing the 'deploy', then executing the 'install' might make sense... but it wasn't intuitive. Just looking for comment. Thanks. > pom.xml not deploying to Artifactory > > > Key: JENKINS-12950 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12950 > Project: Jenkins > Issue Type: Bug > Components: artifactory >Reporter: Jerry Thome >Assignee: yossis > Attachments: 3-1-2012 10-38-30 AM.png > > > Jenkins ver. 1.444 > Jenkins Artifactory Plugin 2.0.5 > Maven 3.0.3 > We have a very simple Maven project setup. We are running "clean package > verify emma:emma" and then using the Artifactory plugin to publish to a > snapshot repository in Artifactory. > We simlpy want the basic pom.xml and jar deployed, but only the JAR is being > deployed. If I use the standard 'mvn deploy' or the "Deploy artifacts to > Maven repository", it works as expected. > Do we need to configure something special in the "Include Patterns"? > Thanks. -- 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-11783) SAXParser-related IllegalAccessError on svn update
[
https://issues.jenkins-ci.org/browse/JENKINS-11783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159713#comment-159713
]
Peter Lillevold commented on JENKINS-11783:
---
I can confirm the same behavior using Jenkins 1.452 and the Config File
Provider Plugin
(https://wiki.jenkins-ci.org/display/JENKINS/Config+File+Provider+Plugin). The
config files could not be pushed to my jnlp-enabled slave and I had indeed
disabled the Maven plugin.
Enabling the Maven plugin solved the problem. But as @pancake says, there is an
unnecessary dependency here.
> SAXParser-related IllegalAccessError on svn update
> --
>
> Key: JENKINS-11783
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11783
> Project: Jenkins
> Issue Type: Bug
> Components: subversion
>Affects Versions: current
> Environment: Jenkins ver. 1.439
> Jenkins Subversion Plug-in1.34
>Reporter: pancake
>Assignee: Kohsuke Kawaguchi
>Priority: Critical
>
> This started to occur after a recent update to Jenkins ver. 1.439 + Jenkins
> Subversion Plug-in 1.34.
> It only happens on *some slaves, not others* \- while they are (at least at
> 1st glance) are totally identical.
> I did these steps, and the problem was fixed for *some* slaves:
> - deleted job workspaces;
> - deleted %APPDATA%\Subversion;
> - cleared %USERPROFILE%\Local Settings\Temp;
> - cleared %TMP%, %TEMP% (we override these env vars in slave nodes'
> configuration) Jenkins service uses;
> - removed %JENKINS_HOME%\*.jar.
> {noformat}
> 15:02:14 Checking out a fresh workspace because there's no workspace at
> C:\_JenkinsCI\workspace\for_maintenance
> 15:02:14 Cleaning local Directory .
> 15:02:14 Checking out http://server/rep
> 15:02:14 hudson.util.IOException2: remote file operation failed:
> C:\_JenkinsCI\workspace\for_maintenance at
> hudson.remoting.Channel@a18951:hudson32
> 15:02:14 at hudson.FilePath.act(FilePath.java:781)
> 15:02:14 at hudson.FilePath.act(FilePath.java:767)
> 15:02:14 at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:735)
> 15:02:14 at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:677)
> 15:02:14 at
> hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
> 15:02:14 at
> hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:568)
> 15:02:14 at
> hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:456)
> 15:02:14 at hudson.model.Run.run(Run.java:1404)
> 15:02:14 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
> 15:02:14 at
> hudson.model.ResourceController.execute(ResourceController.java:88)
> 15:02:14 at hudson.model.Executor.run(Executor.java:230)
> 15:02:14 Caused by: java.io.IOException: Remote call on hudson32 failed
> 15:02:14 at hudson.remoting.Channel.call(Channel.java:690)
> 15:02:14 at hudson.FilePath.act(FilePath.java:774)
> 15:02:14 ... 10 more
> 15:02:14 Caused by: java.lang.IllegalAccessError: tried to access method
> org.apache.xerces.jaxp.SAXParserImpl.(Lorg/apache/xerces/jaxp/SAXParserFactoryImpl;Ljava/util/Hashtable;Z)V
> from class org.apache.xerces.jaxp.SAXParserFactoryImpl
> 15:02:14 at
> org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:745)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:719)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:216)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:364)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:285)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:276)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:264)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doPropfind(DAVConnection.java:126)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getProperties(DAVUtil.java:73)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getResourceProperties(DAVUtil.java:79)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getStartingProperties(DAVUtil.java:103)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.DAVUtil.findStartingProperties(DAVUtil.java:125)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getBaselineProperties(DAVUtil.java:226)
> 15:02:14 at
> org.tmatesoft.svn.core.internal.i
[JIRA] (JENKINS-12912) URLTtrigger does not poll on jobs which are tied to disconnected slaves
[
https://issues.jenkins-ci.org/browse/JENKINS-12912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159712#comment-159712
]
gbois commented on JENKINS-12912:
-
The current behavior is to process polling on the target execution node (master
or a slave).
In your use case, you need to have to ability to poll always on master.
Does it suits you if I add a check-box 'Poll on master' in the job
configuration?
> URLTtrigger does not poll on jobs which are tied to disconnected slaves
> ---
>
> Key: JENKINS-12912
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12912
> Project: Jenkins
> Issue Type: Bug
> Components: urltrigger
> Environment: Jenkins 1.451
> URLTrigger Plugin 0.10, 0.14
>Reporter: OHTAKE Tomohiro
>Assignee: gbois
>
> Since 0.10, URLTtrigger does not poll on jobs which are tied to disconnected
> slaves even if there are available executors on master.
> URLTrigger Plugin 0.9 makes master poll the URL even if the jobs are tied to
> slaves.
> If there are changes in URL, a slave that is tied to the job wakes up and
> runs the job.
> URLTrigger 0.9 says that polling has been done on slaves, but master polles.
> {code:title=URLTrigger Log (0.14, job which is tied to disconnected slaves)}
> Polling for the job aa
> Searching a node to run the polling for the label ''.
> Can't find any complete active node for the polling action. Maybe slaves are
> not yet active at this time or the number of executor of the master is 0.
> Checking again in next polling schedule.
> {code}
> {code:title=URLTrigger Log (0.14, job which is not tied to any slaves)}
> Polling for the job bb
> Polling on master.
> Polling started on Feb 28, 2012 10:22:42 AM
> Invoking the url:
> http://aaa.invalid/bb
> Inspecting the content
> Polling complete. Took 0.12 sec.
> No changes.
> {code}
> {code:title=URLTrigger Log (0.9, job which is tied to disconnected slaves)}
> Polling started on Feb 28, 2012 10:51:04 AM
> Searching a node to run the polling for the label ''.
> Invoking the url:
> http://aaa.invalid/bb
> Inspecting the content
> Polling complete. Took 0.14 sec
> No changes.
> {code}
> Workarounds:
> * Downgrade URLTrigger Plugin to 0.9
> * Do not tie jobs which uses Use URLTrigger
> ** Create a job that uses URLTrigger and do not tie the job to any slaves.
> ** Configure the job to build other projects in its post-build 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-12938) MavenReporters always run, even if unneeded: MavenFingerprinter is slow
[ https://issues.jenkins-ci.org/browse/JENKINS-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Atwill updated JENKINS-12938: --- Description: The MavenFingerprinter MavenReporter should not run if fingerprinting the build is disabled. --- Yesterday I attached YourKit to our Jenkins Maven-style build. I was attached to the actual Maven3 builder and discovered that 36% of our build time is spent in MavenReporters we don't use. We don't have fingerprinting turned on but the MavenFingerprinter report still runs and was particularly expensive. --- I rebuilt the maven-plugin removing the @Extension from MavenArtifactArchiver, MavenFingerprinter and MavenMailer and improved our build time by 36%. There's no good out-of-the-box way to do this with Jenkins. I had little luck when dropping in a custom PluginStrategy to do this at runtime. was: The MavenFingerprinter MavenReporter should not run if fingerprinting the build is disabled. --- Yesterday I attached YourKit to our Jenkins Maven-style build. I was attached to the actual Maven3 builder and discovered that 36% of our build time is spent in MavenReporters we don't use. We don't have fingerprinting turned on but the MavenFingerprinter report still runs and was particularly expensive. --- I rebuilt the maven-plugin removing the @Extension from MavenArtifactArchiver, MavenFingerprinter and MavenMailer and improved our build time by 36%. > MavenReporters always run, even if unneeded: MavenFingerprinter is slow > --- > > Key: JENKINS-12938 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12938 > Project: Jenkins > Issue Type: Bug > Components: maven > Environment: Linux, separate master/slave. Slave launched via SSH. > Multi-minute, multi-module maven build. >Reporter: James Atwill > Labels: maven > > The MavenFingerprinter MavenReporter should not run if fingerprinting the > build is disabled. > --- > Yesterday I attached YourKit to our Jenkins Maven-style build. I was > attached to the actual Maven3 builder and discovered that 36% of our build > time is spent in MavenReporters we don't use. We don't have fingerprinting > turned on but the MavenFingerprinter report still runs and was particularly > expensive. > --- > I rebuilt the maven-plugin removing the @Extension from > MavenArtifactArchiver, MavenFingerprinter and MavenMailer and improved our > build time by 36%. There's no good out-of-the-box way to do this with > Jenkins. I had little luck when dropping in a custom PluginStrategy to do > this at runtime. -- 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-12950) pom.xml not deploying to Artifactory
Jerry Thome created JENKINS-12950: - Summary: pom.xml not deploying to Artifactory Key: JENKINS-12950 URL: https://issues.jenkins-ci.org/browse/JENKINS-12950 Project: Jenkins Issue Type: Bug Components: artifactory Reporter: Jerry Thome Assignee: yossis Attachments: 3-1-2012 10-38-30 AM.png Jenkins ver. 1.444 Jenkins Artifactory Plugin 2.0.5 Maven 3.0.3 We have a very simple Maven project setup. We are running "clean package verify emma:emma" and then using the Artifactory plugin to publish to a snapshot repository in Artifactory. We simlpy want the basic pom.xml and jar deployed, but only the JAR is being deployed. If I use the standard 'mvn deploy' or the "Deploy artifacts to Maven repository", it works as expected. Do we need to configure something special in the "Include Patterns"? Thanks. -- 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-11784) Build numbers not getting into manifest file
[ https://issues.jenkins-ci.org/browse/JENKINS-11784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159711#comment-159711 ] Oded Maimon commented on JENKINS-11784: --- Actually this is something that i would be very happy if it was configurable. i for instant don't wish jenkins to add the manifest data, it makes each build artifact to have different md5sum even if the code wasn't changed. > Build numbers not getting into manifest file > > > Key: JENKINS-11784 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11784 > Project: Jenkins > Issue Type: Bug > Components: core >Reporter: vinod mahalingam >Assignee: olamy > > I recently upgraded from Hudson to Jenkins and found that the Manifest file > in my jars no longer have the build/version related information in them. > Contents of manifest file with hudson that are missing after upgrading to > Jenkins > ... > Hudson-Build-Number: 11 > Hudson-Project: > Hudson-Version: 1.357 -- 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-12810) JUnit test results are getting wrongly attached to all the test cases
[ https://issues.jenkins-ci.org/browse/JENKINS-12810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159710#comment-159710 ] Bruno P. Kinoshita commented on JENKINS-12810: -- Your understanding is perfect, and very clear for me. The actual problem is where to find which platform the test case used. > How it should work with platform property: Let's include one more step here. 1. plugin gets set of test cases from defined Test Plan and Platform (TC11, TC12, TC13; let's call it 'definedTestCasesByTestPlanAndPlatform') 2. executes all tests that are specified as maven argument 3. seeks result + platform in JUnit/TestNG XML 4. record result for 'definedTestCasesByTestPlanAndPlatform' in TestLink for defined Test Plan and Platform combination I couldn't find an easy way to include the platform in JUnit or TestNG XML. That's way only TAP supports platforms at moment. Thanks Jaroslavas, it's really great to discuss this issue with someone else that is keen to help :-) Bruno > JUnit test results are getting wrongly attached to all the test cases > - > > Key: JENKINS-12810 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12810 > Project: Jenkins > Issue Type: Bug > Components: testlink >Affects Versions: current >Reporter: Vignesh Senapathy >Assignee: Bruno P. Kinoshita > Fix For: current > > Attachments: 1.jpg, 2.jpg, 3.jpg, last_tc.png, schema.jpg, > screenshot20120228152415.jpg, screenshot20120228152511.jpg, tc1.png, tc2.png, > testlink-3.1-alpha2.hpi > > > Hi, > I am using the Testlink Jenkins plugin and when i run my jobs in Jenkins the > Junit Test results are getting generated. This in turn calls the Testlink xml > rpc and attaches the results to the test case, but the test results are > attached wrongly. The 1st test case has 6 results, the next has 5 and so on > and the last one has 1 test result attached to it. I dont know if it is bug > which is causing this. Please let me know what seems to be the problems. Also > the execution flags are correctly rendered in this. which ever test case > fails is marked as failed and which passed is marked as passed. > Also I have one custom field which maps to the test suite name and test > classname. -- 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-12947) update of Perforce plugin fails with IOException
[ https://issues.jenkins-ci.org/browse/JENKINS-12947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159709#comment-159709 ] Rob Petti commented on JENKINS-12947: - Updating without restarting isn't supported by Jenkins yet. > update of Perforce plugin fails with IOException > > > Key: JENKINS-12947 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12947 > Project: Jenkins > Issue Type: Bug > Components: perforce, update-center >Affects Versions: current > Environment: Windows 7 64 SP1, JDK 1.6_29_x64, Jenkins 1.451 >Reporter: robsimon > > Try to updated an installed plugin without restarting Jenkins. In my case > Perforce threw the following exception (SubVersion behaved similar): > hudson.util.IOException2: Failed to dynamically deploy this plugin > at > hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1137) > at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:955) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > Caused by: java.io.IOException: Unable to delete > C:\Jenkins\plugins\perforce\WEB-INF\lib\commons-codec-1.4.jar > at hudson.Util.deleteFile(Util.java:237) > at hudson.Util.deleteRecursive(Util.java:287) > at hudson.Util.deleteContentsRecursive(Util.java:198) > at hudson.Util.deleteRecursive(Util.java:278) > at hudson.Util.deleteContentsRecursive(Util.java:198) > at hudson.Util.deleteRecursive(Util.java:278) > at hudson.Util.deleteContentsRecursive(Util.java:198) > at hudson.ClassicPluginStrategy.explode(ClassicPluginStrategy.java:389) > at > hudson.ClassicPluginStrategy.createPluginWrapper(ClassicPluginStrategy.java:113) > at hudson.PluginManager.dynamicLoad(PluginManager.java:340) > at > hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1133) > ... 7 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-10606) Support Matrix Builds
[
https://issues.jenkins-ci.org/browse/JENKINS-10606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159708#comment-159708
]
Rob Petti commented on JENKINS-10606:
-
Yeah, I've been thinking about how best to handle it going forward. Having to
add ${JOB_NAME} seems a bit hacky, but it works until this ticket gets resolved.
> Support Matrix Builds
> -
>
> Key: JENKINS-10606
> URL: https://issues.jenkins-ci.org/browse/JENKINS-10606
> Project: Jenkins
> Issue Type: Improvement
> Components: perforce
>Reporter: Rob Petti
>Assignee: Rob Petti
>
> Currently the perforce plugin does not explicitly support matrix builds,
> which can lead to certain features not working correctly.
> For example, matrix builds will always use the same client workspace for all
> sub jobs, requiring a force sync for each one. In addition, each sub job will
> sync to the latest changeset, which could be different depending on when the
> jobs run. At the very least, the perforce plugin should sync to the same
> changeset for all sub jobs.
--
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-10606) Support Matrix Builds
[
https://issues.jenkins-ci.org/browse/JENKINS-10606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159707#comment-159707
]
Andy Bigos commented on JENKINS-10606:
--
Yes - that was it. Thanks!
I'd set all the other items that had an 'Import Note' about matrix builds - but
the workspace name didn't have one (though it has plenty of others!). At the
risk of adding even more text I'd suggest adding something about this - or even
better, when a matrix job is detected auto-populate the field with ${JOB_NAME}.
That will at least bring the issue to notice.
Anyway - thanks for sorting the issue out so quickly.
Andy
> Support Matrix Builds
> -
>
> Key: JENKINS-10606
> URL: https://issues.jenkins-ci.org/browse/JENKINS-10606
> Project: Jenkins
> Issue Type: Improvement
> Components: perforce
>Reporter: Rob Petti
>Assignee: Rob Petti
>
> Currently the perforce plugin does not explicitly support matrix builds,
> which can lead to certain features not working correctly.
> For example, matrix builds will always use the same client workspace for all
> sub jobs, requiring a force sync for each one. In addition, each sub job will
> sync to the latest changeset, which could be different depending on when the
> jobs run. At the very least, the perforce plugin should sync to the same
> changeset for all sub jobs.
--
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-10606) Support Matrix Builds
[
https://issues.jenkins-ci.org/browse/JENKINS-10606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159706#comment-159706
]
Rob Petti commented on JENKINS-10606:
-
Your matrixruns might be running at the exact same time with the same client,
so some of them don't sync.
Try adding the ${JOB_NAME} token to your client workspace name. That should
prevent any collisions, since it's unique for all matrixruns.
> Support Matrix Builds
> -
>
> Key: JENKINS-10606
> URL: https://issues.jenkins-ci.org/browse/JENKINS-10606
> Project: Jenkins
> Issue Type: Improvement
> Components: perforce
>Reporter: Rob Petti
>Assignee: Rob Petti
>
> Currently the perforce plugin does not explicitly support matrix builds,
> which can lead to certain features not working correctly.
> For example, matrix builds will always use the same client workspace for all
> sub jobs, requiring a force sync for each one. In addition, each sub job will
> sync to the latest changeset, which could be different depending on when the
> jobs run. At the very least, the perforce plugin should sync to the same
> changeset for all sub jobs.
--
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-12948) "Always Force Sync" and "Don't update server database on sync (-p)" are not compatible with each other
[ https://issues.jenkins-ci.org/browse/JENKINS-12948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Petti updated JENKINS-12948: Assignee: Rob Petti > "Always Force Sync" and "Don't update server database on sync (-p)" are not > compatible with each other > -- > > Key: JENKINS-12948 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12948 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current >Reporter: Thomas Fields >Assignee: Rob Petti >Priority: Trivial > > Hi there, > If you configure the Perforce plugin to "Always Force Sync" and "Don't update > server database on sync (-p)" then this will fail with: > [NvTriStrip] $ "C:\\Program Files\\Perforce\\p4.exe" -s sync -f -p > //Jenkins_NvTriStrip-Build2/...@167119 > 11:33:20 Caught exception communicating with perforce. Errors encountered > while force syncing: error: Usage: sync [ -n -p -q ] [-m max] [files...] > 11:33:20 com.tek42.perforce.PerforceException: Errors encountered while > force syncing: error: Usage: sync [ -n -p -q ] [-m max] [files...] > 11:33:20 > 11:33:20 at > com.tek42.perforce.parse.Workspaces.syncTo(Workspaces.java:167) > 11:33:20 at > hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:747) > 11:33:20 at > hudson.model.AbstractProject.checkout(AbstractProject.java:1195) > 11:33:20 at > hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579) > 11:33:20 at > hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468) > 11:33:20 at hudson.model.Run.run(Run.java:1408) > 11:33:20 at hudson.matrix.MatrixBuild.run(MatrixBuild.java:252) > 11:33:20 at > hudson.model.ResourceController.execute(ResourceController.java:88) > 11:33:20 at hudson.model.Executor.run(Executor.java:238) > 11:33:20 at hudson.model.OneOffExecutor.run(OneOffExecutor.java:66) > 11:33:20 ERROR: Unable to communicate with perforce. Errors encountered > while force syncing: error: Usage: sync [ -n -p -q ] [-m max] [files...] > Is it possible to update the Perforce plugin to at least warn or error if > both these options are enabled? > Regards, > Tom. -- 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-12934) Subversion Tag plugin tries to copy from invalid source path
[
https://issues.jenkins-ci.org/browse/JENKINS-12934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Lillevold updated JENKINS-12934:
--
Priority: Critical (was: Blocker)
Description:
Last week the subversion tagging plugin stopped working, and I have so far not
been able to pinpoint the source of this error.
This bug is a showstopper for us since the tags are used in other jobs.
The job module have Subversion SCM set up with the following repo:
https://svn.myserver.com/svn/repo/folder1.sub/trunk
The svn-tag plugin is configured with:
https://svn.myserver.com/svn/repo/folder1.sub/tags/${env['BUILD_VERSION']}
The error message from the plugin shows that apparently it tries to copy from
an invalid source path.
(note: I have obfuscated url names, but otherwise the number of parts are the
same)
Remote Module Location:
https://svn.myserver.com/svn/repo/folder1.sub/trunk@2254.
Tag Base URL: https://svn.myserver.com/svn/repo/folder1.sub/tags/0.0.3.2254.
There was no old tag at
https://svn.myserver.com/svn/repo/folder1.sub/tags/0.0.3.2254.
Subversion copy failed. svn: File not found: revision 2254, path
'/folder1.sub/trunk/folder1.sub/trunk'
svn: '/svn/repo/!svn/bc/2254/folder1.sub/trunk' path not found: 404 Not Found
(https://svn.myserver.com)
Build step 'Perform Subversion tagging on successful build' marked build as
failure
was:
Last week the subversion tagging plugin stopped working, and I have so far not
been able to pinpoint the source of this error.
This bug is a showstopper for us since the tags are used in other jobs.
The error message from the plugin shows that apparently it tries to copy from
an invalid source path.
(note: I have obfuscated url names, but otherwise the number of parts are the
same)
The job module have the following repo:
https://svn.myserver.com/svn/repo/folder1/folder2/trunk
The svn-tag plugin is configured with:
https://svn.myserver.com/svn/repo/folder1/folder2/tags/${env['BUILD_VERSION']}
Remote Module Location:
https://svn.myserver.com/svn/repo/folder1/folder2/trunk@2254.
Tag Base URL: https://svn.myserver.com/svn/repo/folder1/folder2/tags/0.0.3.2254.
There was no old tag at
https://svn.myserver.com/svn/repo/folder1/folder2/tags/0.0.3.2254.
Subversion copy failed. svn: File not found: revision 2254, path
'/folder1/folder2/trunk/folder1/folder2/trunk'
svn: '/svn/repo/!svn/bc/2254/folder1/folder2/trunk' path not found: 404 Not
Found (https://svn.myserver.com)
Build step 'Perform Subversion tagging on successful build' marked build as
failure
Fixed the actual folder beneath repo level, and added that my folder includes a
'.' in case this has any significance. I have tried with other folders with
names that do not contain '.' with same results though.
> Subversion Tag plugin tries to copy from invalid source path
>
>
> Key: JENKINS-12934
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12934
> Project: Jenkins
> Issue Type: Bug
> Components: plugin, subversion
>Affects Versions: current
> Environment: Windows Server 2008 R2.
> Jenkins installed as Windows Service.
>Reporter: Peter Lillevold
>Priority: Critical
> Labels: jenkins, plugin, subversion, tag
>
> Last week the subversion tagging plugin stopped working, and I have so far
> not been able to pinpoint the source of this error.
> This bug is a showstopper for us since the tags are used in other jobs.
> The job module have Subversion SCM set up with the following repo:
> https://svn.myserver.com/svn/repo/folder1.sub/trunk
> The svn-tag plugin is configured with:
> https://svn.myserver.com/svn/repo/folder1.sub/tags/${env['BUILD_VERSION']}
> The error message from the plugin shows that apparently it tries to copy from
> an invalid source path.
> (note: I have obfuscated url names, but otherwise the number of parts are the
> same)
> Remote Module Location:
> https://svn.myserver.com/svn/repo/folder1.sub/trunk@2254.
> Tag Base URL: https://svn.myserver.com/svn/repo/folder1.sub/tags/0.0.3.2254.
> There was no old tag at
> https://svn.myserver.com/svn/repo/folder1.sub/tags/0.0.3.2254.
> Subversion copy failed. svn: File not found: revision 2254, path
> '/folder1.sub/trunk/folder1.sub/trunk'
> svn: '/svn/repo/!svn/bc/2254/folder1.sub/trunk' path not found: 404 Not Found
> (https://svn.myserver.com)
> Build step 'Perform Subversion tagging on successful build' marked build as
> 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-12949) Do not automatically convert post-split Hudson installation to Jenkins
Richard Mortimer created JENKINS-12949: -- Summary: Do not automatically convert post-split Hudson installation to Jenkins Key: JENKINS-12949 URL: https://issues.jenkins-ci.org/browse/JENKINS-12949 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Debian/Ubuntu but I suspect other packaging has the same problems. Reporter: Richard Mortimer Priority: Critical The Jenkins Debian/Ubuntu packaging automatically converts Hudson installs into Jenkins. This works fine for pre-split versions of Hudson but newer installs of Hudson have configuration/plugins that are starting to diverge significantly from Jenkins. The packaging should detect newer post-split Hudson installs and should refrain from converting the install to Jenkins. Earlier today there was an incident of this reported via IRC #jenkins and it was not immediately obvious what the cause of the problems were and fixing plugin versions/configuration is not for the fainthearted! -- 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-10606) Support Matrix Builds
[ https://issues.jenkins-ci.org/browse/JENKINS-10606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159704#comment-159704 ] Andy Bigos commented on JENKINS-10606: -- Hi, Given the title of this issue - can I ask what is the general state of Matrix Job support at the moment? I ask as I have some jobs which have some matrix elements that don't sync. It's pretty random which elements don't get a synced. I have selected: * Let Jenkins Manage Workspace View - TRUE * Let Jenkins Create Workspace - TRUE * Clean Workspace Before Each Build - TRUE * Always Force Sync - TRUE * Poll Only on Master - TRUE Does this behaviour sounds like something you might expect given the current level of support for matrix builds, or should I create a new issue and add more details? Or am I simply missing something in the config? Thanks for help, Andy > Support Matrix Builds > - > > Key: JENKINS-10606 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10606 > Project: Jenkins > Issue Type: Improvement > Components: perforce >Reporter: Rob Petti >Assignee: Rob Petti > > Currently the perforce plugin does not explicitly support matrix builds, > which can lead to certain features not working correctly. > For example, matrix builds will always use the same client workspace for all > sub jobs, requiring a force sync for each one. In addition, each sub job will > sync to the latest changeset, which could be different depending on when the > jobs run. At the very least, the perforce plugin should sync to the same > changeset for all sub jobs. -- 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-12223) Warnings trend graph (type distribution) dashboard portlet is very slow to display when # jobs in view > 12 or so
[ https://issues.jenkins-ci.org/browse/JENKINS-12223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulli Hafner resolved JENKINS-12223. --- Resolution: Fixed > Warnings trend graph (type distribution) dashboard portlet is very slow to > display when # jobs in view > 12 or so > - > > Key: JENKINS-12223 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12223 > Project: Jenkins > Issue Type: Improvement > Components: analysis-collector, analysis-core, dashboard-view, > warnings >Affects Versions: current >Reporter: Greg Moncreaff >Assignee: Ulli Hafner > > Is it possible that the data can be cached (in the dashboard view) to be > reused (and refreshed in the background as needed) rather than starting from > scratch each time. > While waiting for portlet to finish, view controls in other portlets (e.g. > sorts) are not available. -- 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-12929) Is it possible to have a QTP only plugin or perhaps enhance the QC plugin to do this?
[ https://issues.jenkins-ci.org/browse/JENKINS-12929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159703#comment-159703 ] Nathmie S commented on JENKINS-12929: - I have managed thus far to kick of test(s) and export results to HTML without the QC plugin. >From what I have read you guys managed to get the QC plugin to read the >results.xml and work with the Junit test reporting is this correct? If so, could you please provide some guidance on how to do that? > Is it possible to have a QTP only plugin or perhaps enhance the QC plugin to > do this? > - > > Key: JENKINS-12929 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12929 > Project: Jenkins > Issue Type: New Feature > Components: qc > Environment: Windows 2008 Server, HP QTP 11 >Reporter: Nathmie S >Assignee: Daniel Petisme > > I want to be able to kick off QTP tests and store results in Jenkins. I do > not have access to a QC installation. > Do you have any ideas? I have been googling to try and find a solution. > CAn the QC plugin be manipulated to do this? -- 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-12810) JUnit test results are getting wrongly attached to all the test cases
[ https://issues.jenkins-ci.org/browse/JENKINS-12810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159702#comment-159702 ] Jaroslavas D. edited comment on JENKINS-12810 at 3/1/12 1:14 PM: - I don't really understood why it is JUnit or TestNG limitation.. I'll explain my situation. Let's imagine we have such Test plan/Platforms/Test Case structure !schema.jpg|thumbnail! For simplicity, let's use only _Test Plan 1_ for execution. As I understand (correct me if I am wrong), now it works like this: # plugin gets set of test cases from defined _Test Plan_ (_TC11_, _TC12_, _TC13_, _TC14_, _TC15_, _TC16_; let's call it 'definedTestCasesByTestPlan') # executes all tests that are specified as maven argument # records results for 'definedTestCasesByTestPlan' in TestLink for defined _Test Plan_ How it should work with platform property: # plugin gets set of test cases from defined _Test Plan_ and _Platform_ (_TC11_, _TC12_, _TC13_; let's call it 'definedTestCasesByTestPlanAndPlatform') # executes all tests that are specified as maven argument # record result for 'definedTestCasesByTestPlanAndPlatform' in TestLink for defined _Test Plan_ and _Platform_ combination So, the problem is to get proper set of Test Cases for execution in TestLink (in step 1). However, JUnit/TestNG/TAP takes a part on step 2 and step 3. Sorry if I am wrong in some cases (please, correct me).. I just want to understand the problem and try to help :) was (Author: jar): I don't really understood why it is JUnit or TestNG limitation.. I'll explain my situation. Let's imagine we have such Test plan/Platforms/Test Case structure !schema.jpg|thumbnail! As I understand (correct me if I am wrong), now it works like this: # plugin gets set of test cases from defined _Test Plan_ (_TC11_, _TC12_, _TC13_, _TC14_, _TC15_, _TC16_; let's call it 'definedTestCasesByTestPlan') # executes all tests that are specified as maven argument # records results for 'definedTestCasesByTestPlan' in TestLink for defined _Test Plan_ How it should work with platform property: # plugin gets set of test cases from defined _Test Plan_ and _Platform_ (_TC11_, _TC12_, _TC13_; let's call it 'definedTestCasesByTestPlanAndPlatform') # executes all tests that are specified as maven argument # record result for 'definedTestCasesByTestPlanAndPlatform' in TestLink for defined _Test Plan_ and _Platform_ combination So, the problem is to get proper set of Test Cases for execution in TestLink (in step 1). However, JUnit/TestNG/TAP takes a part on step 2 and step 3. Sorry if I am wrong in some cases (please, correct me).. I just want to understand the problem and try to help :) > JUnit test results are getting wrongly attached to all the test cases > - > > Key: JENKINS-12810 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12810 > Project: Jenkins > Issue Type: Bug > Components: testlink >Affects Versions: current >Reporter: Vignesh Senapathy >Assignee: Bruno P. Kinoshita > Fix For: current > > Attachments: 1.jpg, 2.jpg, 3.jpg, last_tc.png, schema.jpg, > screenshot20120228152415.jpg, screenshot20120228152511.jpg, tc1.png, tc2.png, > testlink-3.1-alpha2.hpi > > > Hi, > I am using the Testlink Jenkins plugin and when i run my jobs in Jenkins the > Junit Test results are getting generated. This in turn calls the Testlink xml > rpc and attaches the results to the test case, but the test results are > attached wrongly. The 1st test case has 6 results, the next has 5 and so on > and the last one has 1 test result attached to it. I dont know if it is bug > which is causing this. Please let me know what seems to be the problems. Also > the execution flags are correctly rendered in this. which ever test case > fails is marked as failed and which passed is marked as passed. > Also I have one custom field which maps to the test suite name and test > classname. -- 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-12810) JUnit test results are getting wrongly attached to all the test cases
[ https://issues.jenkins-ci.org/browse/JENKINS-12810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159702#comment-159702 ] Jaroslavas D. commented on JENKINS-12810: - I don't really understood why it is JUnit or TestNG limitation.. I'll explain my situation. Let's imagine we have such Test plan/Platforms/Test Case structure !schema.jpg|thumbnail! As I understand (correct me if I am wrong), now it works like this: # plugin gets set of test cases from defined _Test Plan_ (_TC11_, _TC12_, _TC13_, _TC14_, _TC15_, _TC16_; let's call it 'definedTestCasesByTestPlan') # executes all tests that are specified as maven argument # records results for 'definedTestCasesByTestPlan' in TestLink for defined _Test Plan_ How it should work with platform property: # plugin gets set of test cases from defined _Test Plan_ and _Platform_ (_TC11_, _TC12_, _TC13_; let's call it 'definedTestCasesByTestPlanAndPlatform') # executes all tests that are specified as maven argument # record result for 'definedTestCasesByTestPlanAndPlatform' in TestLink for defined _Test Plan_ and _Platform_ combination So, the problem is to get proper set of Test Cases for execution in TestLink (in step 1). However, JUnit/TestNG/TAP takes a part on step 2 and step 3. Sorry if I am wrong in some cases (please, correct me).. I just want to understand the problem and try to help :) > JUnit test results are getting wrongly attached to all the test cases > - > > Key: JENKINS-12810 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12810 > Project: Jenkins > Issue Type: Bug > Components: testlink >Affects Versions: current >Reporter: Vignesh Senapathy >Assignee: Bruno P. Kinoshita > Fix For: current > > Attachments: 1.jpg, 2.jpg, 3.jpg, last_tc.png, schema.jpg, > screenshot20120228152415.jpg, screenshot20120228152511.jpg, tc1.png, tc2.png, > testlink-3.1-alpha2.hpi > > > Hi, > I am using the Testlink Jenkins plugin and when i run my jobs in Jenkins the > Junit Test results are getting generated. This in turn calls the Testlink xml > rpc and attaches the results to the test case, but the test results are > attached wrongly. The 1st test case has 6 results, the next has 5 and so on > and the last one has 1 test result attached to it. I dont know if it is bug > which is causing this. Please let me know what seems to be the problems. Also > the execution flags are correctly rendered in this. which ever test case > fails is marked as failed and which passed is marked as passed. > Also I have one custom field which maps to the test suite name and test > classname. -- 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-12810) JUnit test results are getting wrongly attached to all the test cases
[ https://issues.jenkins-ci.org/browse/JENKINS-12810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslavas D. updated JENKINS-12810: Attachment: schema.jpg > JUnit test results are getting wrongly attached to all the test cases > - > > Key: JENKINS-12810 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12810 > Project: Jenkins > Issue Type: Bug > Components: testlink >Affects Versions: current >Reporter: Vignesh Senapathy >Assignee: Bruno P. Kinoshita > Fix For: current > > Attachments: 1.jpg, 2.jpg, 3.jpg, last_tc.png, schema.jpg, > screenshot20120228152415.jpg, screenshot20120228152511.jpg, tc1.png, tc2.png, > testlink-3.1-alpha2.hpi > > > Hi, > I am using the Testlink Jenkins plugin and when i run my jobs in Jenkins the > Junit Test results are getting generated. This in turn calls the Testlink xml > rpc and attaches the results to the test case, but the test results are > attached wrongly. The 1st test case has 6 results, the next has 5 and so on > and the last one has 1 test result attached to it. I dont know if it is bug > which is causing this. Please let me know what seems to be the problems. Also > the execution flags are correctly rendered in this. which ever test case > fails is marked as failed and which passed is marked as passed. > Also I have one custom field which maps to the test suite name and test > classname. -- 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-12945) New breadcrumb: relative path should be resolved based on model-link's href
[ https://issues.jenkins-ci.org/browse/JENKINS-12945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-12945 stopped by OHTAKE Tomohiro. > New breadcrumb: relative path should be resolved based on model-link's href > --- > > Key: JENKINS-12945 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12945 > Project: Jenkins > Issue Type: Bug > Components: core > Environment: Jenkins 1.454-SNAPSHOT > (7bf8e8e894e0358401de4be1aa15986627efad11) >Reporter: OHTAKE Tomohiro >Assignee: OHTAKE Tomohiro > Attachments: relative.png > > > See screenshot attached. > Clicking "Delete Slave" menu item will navigate to the page for deleting All > View. -- 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-12945) New breadcrumb: relative path should be resolved based on model-link's href
[ https://issues.jenkins-ci.org/browse/JENKINS-12945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159701#comment-159701 ] OHTAKE Tomohiro commented on JENKINS-12945: --- I have raised a pull request to fix path resolution of new breadcrumb. https://github.com/jenkinsci/jenkins/pull/393 > New breadcrumb: relative path should be resolved based on model-link's href > --- > > Key: JENKINS-12945 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12945 > Project: Jenkins > Issue Type: Bug > Components: core > Environment: Jenkins 1.454-SNAPSHOT > (7bf8e8e894e0358401de4be1aa15986627efad11) >Reporter: OHTAKE Tomohiro >Assignee: OHTAKE Tomohiro > Attachments: relative.png > > > See screenshot attached. > Clicking "Delete Slave" menu item will navigate to the page for deleting All > View. -- 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-12948) "Always Force Sync" and "Don't update server database on sync (-p)" are not compatible with each other
Thomas Fields created JENKINS-12948: --- Summary: "Always Force Sync" and "Don't update server database on sync (-p)" are not compatible with each other Key: JENKINS-12948 URL: https://issues.jenkins-ci.org/browse/JENKINS-12948 Project: Jenkins Issue Type: Bug Components: perforce Affects Versions: current Reporter: Thomas Fields Priority: Trivial Hi there, If you configure the Perforce plugin to "Always Force Sync" and "Don't update server database on sync (-p)" then this will fail with: [NvTriStrip] $ "C:\\Program Files\\Perforce\\p4.exe" -s sync -f -p //Jenkins_NvTriStrip-Build2/...@167119 11:33:20 Caught exception communicating with perforce. Errors encountered while force syncing: error: Usage: sync [ -n -p -q ] [-m max] [files...] 11:33:20 com.tek42.perforce.PerforceException: Errors encountered while force syncing: error: Usage: sync [ -n -p -q ] [-m max] [files...] 11:33:20 11:33:20at com.tek42.perforce.parse.Workspaces.syncTo(Workspaces.java:167) 11:33:20at hudson.plugins.perforce.PerforceSCM.checkout(PerforceSCM.java:747) 11:33:20at hudson.model.AbstractProject.checkout(AbstractProject.java:1195) 11:33:20at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579) 11:33:20at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468) 11:33:20at hudson.model.Run.run(Run.java:1408) 11:33:20at hudson.matrix.MatrixBuild.run(MatrixBuild.java:252) 11:33:20at hudson.model.ResourceController.execute(ResourceController.java:88) 11:33:20at hudson.model.Executor.run(Executor.java:238) 11:33:20at hudson.model.OneOffExecutor.run(OneOffExecutor.java:66) 11:33:20 ERROR: Unable to communicate with perforce. Errors encountered while force syncing: error: Usage: sync [ -n -p -q ] [-m max] [files...] Is it possible to update the Perforce plugin to at least warn or error if both these options are enabled? Regards, Tom. -- 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-12947) update of Perforce plugin fails with IOException
robsimon created JENKINS-12947: -- Summary: update of Perforce plugin fails with IOException Key: JENKINS-12947 URL: https://issues.jenkins-ci.org/browse/JENKINS-12947 Project: Jenkins Issue Type: Bug Components: perforce, update-center Affects Versions: current Environment: Windows 7 64 SP1, JDK 1.6_29_x64, Jenkins 1.451 Reporter: robsimon Try to updated an installed plugin without restarting Jenkins. In my case Perforce threw the following exception (SubVersion behaved similar): hudson.util.IOException2: Failed to dynamically deploy this plugin at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1137) at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:955) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.IOException: Unable to delete C:\Jenkins\plugins\perforce\WEB-INF\lib\commons-codec-1.4.jar at hudson.Util.deleteFile(Util.java:237) at hudson.Util.deleteRecursive(Util.java:287) at hudson.Util.deleteContentsRecursive(Util.java:198) at hudson.Util.deleteRecursive(Util.java:278) at hudson.Util.deleteContentsRecursive(Util.java:198) at hudson.Util.deleteRecursive(Util.java:278) at hudson.Util.deleteContentsRecursive(Util.java:198) at hudson.ClassicPluginStrategy.explode(ClassicPluginStrategy.java:389) at hudson.ClassicPluginStrategy.createPluginWrapper(ClassicPluginStrategy.java:113) at hudson.PluginManager.dynamicLoad(PluginManager.java:340) at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1133) ... 7 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-12946) New breadcrumb: "Next/Previous Build" does not work
OHTAKE Tomohiro created JENKINS-12946: - Summary: New breadcrumb: "Next/Previous Build" does not work Key: JENKINS-12946 URL: https://issues.jenkins-ci.org/browse/JENKINS-12946 Project: Jenkins Issue Type: Bug Components: core Environment: Jenkins 1.454-SNAPSHOT (7bf8e8e894e0358401de4be1aa15986627efad11) Reporter: OHTAKE Tomohiro Attachments: prev.png See screenshot attached. Clicking "Previous Build" menu item will navigate to JSON 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-12945) New breadcrumb: relative path should be resolved based on model-link's href
[ https://issues.jenkins-ci.org/browse/JENKINS-12945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-12945 started by OHTAKE Tomohiro. > New breadcrumb: relative path should be resolved based on model-link's href > --- > > Key: JENKINS-12945 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12945 > Project: Jenkins > Issue Type: Bug > Components: core > Environment: Jenkins 1.454-SNAPSHOT > (7bf8e8e894e0358401de4be1aa15986627efad11) >Reporter: OHTAKE Tomohiro >Assignee: OHTAKE Tomohiro > Attachments: relative.png > > > See screenshot attached. > Clicking "Delete Slave" menu item will navigate to the page for deleting All > View. -- 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-12945) New breadcrumb: relative path should be resolved based on model-link's href
OHTAKE Tomohiro created JENKINS-12945: - Summary: New breadcrumb: relative path should be resolved based on model-link's href Key: JENKINS-12945 URL: https://issues.jenkins-ci.org/browse/JENKINS-12945 Project: Jenkins Issue Type: Bug Components: core Environment: Jenkins 1.454-SNAPSHOT (7bf8e8e894e0358401de4be1aa15986627efad11) Reporter: OHTAKE Tomohiro Assignee: OHTAKE Tomohiro Attachments: relative.png See screenshot attached. Clicking "Delete Slave" menu item will navigate to the page for deleting All View. -- 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-6963) CGit browser support.
[ https://issues.jenkins-ci.org/browse/JENKINS-6963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159700#comment-159700 ] Lionel Schwarz commented on JENKINS-6963: - any news on this request? I'm currently trying to setup a dev platform base upon CGit and Jenkins. Support of CGit would be great benefit. > CGit browser support. > - > > Key: JENKINS-6963 > URL: https://issues.jenkins-ci.org/browse/JENKINS-6963 > Project: Jenkins > Issue Type: Improvement > Components: git >Affects Versions: current > Environment: All >Reporter: mkalika >Assignee: abayer >Priority: Minor > Attachments: 0001-Add-CGit-git-browser-support.patch > > > Please add cgit support to the git plugin. I added the plugin support for it > (heavily based on the existing GitWeb code). I'll uploaded the patch next. > Thank you for your consideration. -- 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-12810) JUnit test results are getting wrongly attached to all the test cases
[
https://issues.jenkins-ci.org/browse/JENKINS-12810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159699#comment-159699
]
Bruno P. Kinoshita commented on JENKINS-12810:
--
Hi Jaroslavas!
That's a very interesting feature, that I really would like to see available
for all strategies. However, there's one technical limitation from JUnit and
TestNG that I never could overcome. They are not extensible. Let me explain why
that's important.
When you're using platform, sometimes your test plan has more than one
platform. So the platform has to exist for each test case, and then I cannot
add one field in plugin options configuration :-( that was my first try some
time ago (there was an issue on that).
TAP can be extended with YAMLish, which looks a lot like JSON, but minus '{'
and '}'. So with TAP, I expect you to include the platform for each case in
your test result (like a test case in JUnit XML).
One alternative for JUnit and TestNG, is using tap4j JUnit Runner or TestNG
Listener. This way, besides generating JUnit XML and TestNG XML, your tests
will output TAP too. But you'll have to use the TAP file name strategy.
Does it make sense? Do you have any other idea to enable platforms on JUnit and
TestNG?
Thanks :)
> JUnit test results are getting wrongly attached to all the test cases
> -
>
> Key: JENKINS-12810
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12810
> Project: Jenkins
> Issue Type: Bug
> Components: testlink
>Affects Versions: current
>Reporter: Vignesh Senapathy
>Assignee: Bruno P. Kinoshita
> Fix For: current
>
> Attachments: 1.jpg, 2.jpg, 3.jpg, last_tc.png,
> screenshot20120228152415.jpg, screenshot20120228152511.jpg, tc1.png, tc2.png,
> testlink-3.1-alpha2.hpi
>
>
> Hi,
> I am using the Testlink Jenkins plugin and when i run my jobs in Jenkins the
> Junit Test results are getting generated. This in turn calls the Testlink xml
> rpc and attaches the results to the test case, but the test results are
> attached wrongly. The 1st test case has 6 results, the next has 5 and so on
> and the last one has 1 test result attached to it. I dont know if it is bug
> which is causing this. Please let me know what seems to be the problems. Also
> the execution flags are correctly rendered in this. which ever test case
> fails is marked as failed and which passed is marked as passed.
> Also I have one custom field which maps to the test suite name and test
> classname.
--
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-12944) Env Inject Plugin doesn't substitute ${WORKSPACE} variable at all when used in 'Preparing an environment for the job'
Joerg Schwaerzler created JENKINS-12944:
---
Summary: Env Inject Plugin doesn't substitute ${WORKSPACE}
variable at all when used in 'Preparing an environment for the job'
Key: JENKINS-12944
URL: https://issues.jenkins-ci.org/browse/JENKINS-12944
Project: Jenkins
Issue Type: Bug
Components: envinject
Affects Versions: current
Reporter: Joerg Schwaerzler
Assignee: gbois
Since we upgraded to EnvInject v1.30 we don't get our variable set if they are
dependend on ${WORKSPACE}.
Please check the job log snippet:
--
11:02:12 [EnvInject] - Preparing an environment for the job.
11:02:12 [EnvInject] - Jenkins system variables are kept.
11:02:12 [EnvInject] - Jenkins build variables are kept.
11:02:12 [EnvInject] - Injecting as environment variables the properties
content
11:02:12 HOME=${WORKSPACE}\home\muccctt1
11:02:12
11:02:12 [EnvInject] - Variables injected successfully.
11:02:12 [EnvInject] - Unset unresolved 'WORK_DRIVE' variable.
11:02:12 [EnvInject] - Unset unresolved 'HOME' variable.
--
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-12943) Intermittent "java.io.StreamCorruptedException: invalid type code: 4B" when communicating with a slave
Pontus Edvardsson created JENKINS-12943: --- Summary: Intermittent "java.io.StreamCorruptedException: invalid type code: 4B" when communicating with a slave Key: JENKINS-12943 URL: https://issues.jenkins-ci.org/browse/JENKINS-12943 Project: Jenkins Issue Type: Bug Components: ssh-slaves Affects Versions: current Environment: Jenkins 1.452 Reporter: Pontus Edvardsson Assignee: Kohsuke Kawaguchi Priority: Critical Attachments: jenkins_log.txt, jenkins_server_info.txt This resembles an earlier bug, JENKINS-8856 I experience random crashes while Jenkins is trying to contact any of the configured slaves. Jobs have been working fine prior upgrading from v1.450, at which time I also added the GIT/Gerrit plugins. I don't do anything special to invoke the problem. I create and run either a maven or freestyle job which in turn starts another job which more than likely crashes. I have attached the log and server info. -- 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-9589) SSH sessions kept open by Subversion checkout
[ https://issues.jenkins-ci.org/browse/JENKINS-9589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159698#comment-159698 ] Stefan Moj commented on JENKINS-9589: - Did you resolve the issue or find a workaround? Seems like i ran into the same issue. We are using SVN version 1.6.12. It looks like that problem occurs since i set up post-commit hook as described [here. | https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin] > SSH sessions kept open by Subversion checkout > - > > Key: JENKINS-9589 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9589 > Project: Jenkins > Issue Type: Bug > Components: subversion > Environment: Jenkins ver. 1.410 > Jenkins subversion plugin 1.25 > Subversion server 1.1 >Reporter: Steven Murdoch > > After running Jenkins for a few days there are a large number of SSH > processes running on the server: > root 19732 0.0 0.6 11632 3092 ?Ss May02 0:00 \_ sshd: > secsvn [priv] > secsvn 19736 0.0 0.6 11632 3332 ?SMay02 0:00 | \_ sshd: > secsvn@notty > secsvn 19737 0.0 0.3 6152 2052 ?Ss May02 0:00 | \_ > svnserve -t --tunnel-user=sjm217 -r ... > root 19756 0.0 0.6 11632 3092 ?Ss May02 0:00 \_ sshd: > secsvn [priv] > secsvn 19760 0.0 0.6 11632 3332 ?SMay02 0:00 | \_ sshd: > secsvn@notty > secsvn 19761 0.0 0.3 6148 1944 ?Ss May02 0:00 | \_ > svnserve -t --tunnel-user=sjm217 -r ... > root 19780 0.0 0.5 11632 2676 ?Ss May02 0:00 \_ sshd: > secsvn [priv] > secsvn 19784 0.0 0.5 11632 2944 ?SMay02 0:00 | \_ sshd: > secsvn@notty > secsvn 19785 0.0 0.3 6152 1928 ?Ss May02 0:00 | \_ > svnserve -t --tunnel-user=sjm217 -r ... > ... > Perhaps related is the following error in the log > 04-May-2011 15:03:08 hudson.model.Run run > INFO: cheri #10 main build action completed: SUCCESS > 04-May-2011 15:03:08 hudson.scm.SubversionSCM$CheckOutTask checkClockOutOfSync > INFO: Failed to estimate the remote time stamp > org.tmatesoft.svn.core.SVNException: svn: 'stat' not implemented > svn: Unknown command 'stat' > at > org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:126) > at > org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:110) > at > org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.handleUnsupportedCommand(SVNRepositoryImpl.java:1368) > at > org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.info(SVNRepositoryImpl.java:1212) > at > hudson.scm.SubversionSCM$CheckOutTask.checkClockOutOfSync(SubversionSCM.java:732) > at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:709) > at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:691) > at hudson.FilePath.act(FilePath.java:756) > at hudson.FilePath.act(FilePath.java:738) > at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:684) > at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:633) > at hudson.model.AbstractProject.checkout(AbstractProject.java:1181) > at > hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:536) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:424) > at hudson.model.Run.run(Run.java:1374) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:145) > Caused by: org.tmatesoft.svn.core.SVNException: svn: Unknown command 'stat' > at > org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) > at > org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) > at > org.tmatesoft.svn.core.internal.io.svn.SVNReader.handleFailureStatus(SVNReader.java:269) > at > org.tmatesoft.svn.core.internal.io.svn.SVNReader.parse(SVNReader.java:248) > at > org.tmatesoft.svn.core.internal.io.svn.SVNConnection.read(SVNConnection.java:260) > at > org.tmatesoft.svn.core.internal.io.svn.SVNConnection.authenticate(SVNConnection.java:160) > at > org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.authenticate(SVNRepositoryImpl.java:1265) > at > org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.info(SVNRepositoryImpl.java:1191) > ... 14 more > Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: Unknown command 'stat' > at > org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200) > at > org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:146) > at > org.tmatesoft.svn.core.SVNErro
[JIRA] (JENKINS-11683) email-ext: user unknown ($PROJECT_DEFAULT_RECIPIENTS) exception
[ https://issues.jenkins-ci.org/browse/JENKINS-11683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159697#comment-159697 ] Niels Wegner commented on JENKINS-11683: According to the value displayed in the Jenkins configuration ist should be possible to use $DEFAULT_RECIPIENT_LIST instead > email-ext: user unknown ($PROJECT_DEFAULT_RECIPIENTS) exception > --- > > Key: JENKINS-11683 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11683 > Project: Jenkins > Issue Type: Bug > Components: email-ext >Affects Versions: current > Environment: linux, jenkins 1.438, email-ext 2.16 >Reporter: Bruno Marti >Assignee: Slide-O-Mix > Labels: email-ext, unknown, user > > According to [https://issues.jenkins-ci.org/browse/JENKINS-11665], global > recipients variable does no longer exist. > But is still use in email-ext plugin, even if there is not present. > $PROJECT_DEFAULT_RECIPIENTS is added to recipient list automatically. > Stacktrace: > Email was triggered for: Success > Sending email for trigger: Success > Sending email to: www.t...@xxx.com $PROJECT_DEFAULT_RECIPIENTS > ERROR: Could not send email as a part of the post-build publishers. > com.sun.mail.smtp.SMTPSendFailedException: 250 2.0.0 pA99kJg2007424 Message > accepted for delivery; > nested exception is: > com.sun.mail.smtp.SMTPAddressFailedException: 550 5.1.1 > <$PROJECT_DEFAULT_RECIPIENTS>... user unknown > at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:598) > at javax.mail.Transport.send0(Transport.java:169) > at javax.mail.Transport.send(Transport.java:99) > at > hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:260) > at > hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:243) > at > hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:203) > at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:695) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:670) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:648) > at hudson.model.Build$RunnerImpl.cleanUp(Build.java:172) > at hudson.model.Run.run(Run.java:1448) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:47) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:230) -- 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-11683) email-ext: user unknown ($PROJECT_DEFAULT_RECIPIENTS) exception
[ https://issues.jenkins-ci.org/browse/JENKINS-11683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159697#comment-159697 ] Niels Wegner edited comment on JENKINS-11683 at 3/1/12 9:33 AM: According to the value displayed in the Jenkins configuration it should be possible to use $DEFAULT_RECIPIENT_LIST instead was (Author: nwegner): According to the value displayed in the Jenkins configuration ist should be possible to use $DEFAULT_RECIPIENT_LIST instead > email-ext: user unknown ($PROJECT_DEFAULT_RECIPIENTS) exception > --- > > Key: JENKINS-11683 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11683 > Project: Jenkins > Issue Type: Bug > Components: email-ext >Affects Versions: current > Environment: linux, jenkins 1.438, email-ext 2.16 >Reporter: Bruno Marti >Assignee: Slide-O-Mix > Labels: email-ext, unknown, user > > According to [https://issues.jenkins-ci.org/browse/JENKINS-11665], global > recipients variable does no longer exist. > But is still use in email-ext plugin, even if there is not present. > $PROJECT_DEFAULT_RECIPIENTS is added to recipient list automatically. > Stacktrace: > Email was triggered for: Success > Sending email for trigger: Success > Sending email to: www.t...@xxx.com $PROJECT_DEFAULT_RECIPIENTS > ERROR: Could not send email as a part of the post-build publishers. > com.sun.mail.smtp.SMTPSendFailedException: 250 2.0.0 pA99kJg2007424 Message > accepted for delivery; > nested exception is: > com.sun.mail.smtp.SMTPAddressFailedException: 550 5.1.1 > <$PROJECT_DEFAULT_RECIPIENTS>... user unknown > at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:598) > at javax.mail.Transport.send0(Transport.java:169) > at javax.mail.Transport.send(Transport.java:99) > at > hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:260) > at > hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:243) > at > hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:203) > at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:695) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:670) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:648) > at hudson.model.Build$RunnerImpl.cleanUp(Build.java:172) > at hudson.model.Run.run(Run.java:1448) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:47) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:230) -- 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-3105) Configuration UI to disable process tree killer selectively
[ https://issues.jenkins-ci.org/browse/JENKINS-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159696#comment-159696 ] chanti vlad commented on JENKINS-3105: -- @mdonohue: I think it _does_ apply to enough users. Lots of us are using concurrent gmake builds without a problem on linux machines, and lots of us want to do just the same for msvc builds under windows. It would be definitely nice to have a checkbox for a "Windows Batch Command" build step or something like this, because a typical use case is not to kill mspdbsrv.exe for simultaneous visual studio builds. > Configuration UI to disable process tree killer selectively > --- > > Key: JENKINS-3105 > URL: https://issues.jenkins-ci.org/browse/JENKINS-3105 > Project: Jenkins > Issue Type: Improvement > Components: other >Affects Versions: current > Environment: Platform: Sun, OS: Solaris >Reporter: olamy >Priority: Trivial > > Due to fix https://hudson.dev.java.net/issues/show_bug.cgi?id=2729, I can't > restart my tomcat instance with using a script which worked fine before 1.283. > My script called fastRestart.sh is : > PWD=`pwd` > cd $PWD > #BUILD_ID="dontKillMe catalina.sh start" > #BUILD_ID="dontKillMe ./startup.sh" > echo $BUILD_ID > kill -9 `cat ./tomcat.pid` && ./startup.sh > My hudson job do : > BUILD_ID=dontKillMe startup.sh && cd > /local/dotw/tomcat-dev-ota-ah/apache-tomcat-6.0.14/bin && ./fastRestart.sh > job console output : > started > [workspace] $ /bin/sh -xe > /local/dotw/tmp/hudson-tmp/hudson3776950102996593394.sh > BUILD_ID=dontKillMe startup.sh > + cd /local/dotw/tomcat-dev-ota-ah/apache-tomcat-6.0.14/bin > + ./fastRestart.sh > + pwd > PWD=/local/dotw/tomcat-dev-ota-ah/apache-tomcat-6.0.14/bin > + cd /local/dotw/tomcat-dev-ota-ah/apache-tomcat-6.0.14/bin > + echo dontKillMe startup.sh > dontKillMe startup.sh > + cat ./tomcat.pid > + kill -9 9822 > + ./startup.sh > finished: SUCCESS > Here the tomcat has been killed and restarted but immediatly stop due to fix > for > 2729. > Is there any other workaround ? > IMHO we should have a flag when running a script which "don't kill child > processes" (to preserve a minimum of backward compatibility and a minimum of > some jobs/scripts rewriting) > Thanks > -- > Olivier -- 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-9104) Visual studio builds started by Jenkins fail with "Fatal error C1090" because mspdbsrv.exe gets killed
[
https://issues.jenkins-ci.org/browse/JENKINS-9104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159695#comment-159695
]
chanti vlad commented on JENKINS-9104:
--
"Jenkins mustn't kill mspdbsrv.exe to be able to build more than one Visual
Studio project at the same time."
Although i will try the indicated workaround, i think this would be good to
have it as a feature somewhere, maybe in the node configuration?
> Visual studio builds started by Jenkins fail with "Fatal error C1090" because
> mspdbsrv.exe gets killed
> --
>
> Key: JENKINS-9104
> URL: https://issues.jenkins-ci.org/browse/JENKINS-9104
> Project: Jenkins
> Issue Type: Bug
> Components: core
>Affects Versions: current
> Environment: Windows XP, using MSBuild or devenv.exe to build MS
> Visual Studio Projects
>Reporter: Christoph Vogtländer
>Priority: Minor
>
> I run into errors when using a customized build system which uses Visual
> Studio's devenv.exe under the hood to compile VisualStudio 2005 projects
> (with VC++ compiler). When starting two parallel builds with Jenkins (on
> different code base) the second job will always fail with "Fatal error C1090:
> PDB API call failed, error code '23' : '(" in exactly the same second the
> first job finishes processing. Running both jobs outside Jenkins does not
> produce the error.
> This has also been reported for builds executed by MSBuild on the Jenkins
> user mailing list [1].
> I analysed this issue thoroughly and can track the problem down to the usage
> of mspdbsrv.exe. This program is automatically spawned when building a
> VisualStudio project. All Visual Studio instances normally share one common
> pdb-server which shutdown itself after a idle period (standard is 10
> minutes). "It ensures access to .pdb files is properly serialized in parallel
> builds when multiple instances of the compiler try to access the same .pdb
> file" [2].
> I assume that Jenkins does a clean up of its build environment when a
> automatically started job finishes (like as described at
> http://wiki.jenkins-ci.org/display/JENKINS/Aborting+a+build). I checked
> mspbsrv.exe with ProcessExplorer and the process indeed has a variable
> JENKINS_COOKIE/HUDSON_COOKIE set in its environment if started through
> Jenkins. Killing mspdbsrv.exe while projects are still connected will break
> compilation.
> Jenkins mustn't kill mspdbsrv.exe to be able to build more than one Visual
> Studio project at the same time.
> --
> [1]
> http://jenkins.361315.n4.nabble.com/MSBuild-fatal-errors-when-build-triggered-by-timer-td385181.html
> [2]
> http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/b1d1bceb-06b6-47ef-a0ea-23ea752e0c4f/
--
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-12810) JUnit test results are getting wrongly attached to all the test cases
[
https://issues.jenkins-ci.org/browse/JENKINS-12810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159693#comment-159693
]
Jaroslavas D. edited comment on JENKINS-12810 at 3/1/12 8:03 AM:
-
Oh, I have found what it's supported from 3.0 version (JENKINS-9054).. only for
TAP. How it should be used?
Is it possible to have it for JUnit?
Now, if I run _Test Plan_ with platform I get an exception
{code}
br.eti.kinoshita.testlinkjavaapi.TestLinkAPIException: (reportTCResult) -
Parameter platformname OR platformid is required, but has not been provided
at
br.eti.kinoshita.testlinkjavaapi.BaseService.checkResponseError(BaseService.java:119)
at
br.eti.kinoshita.testlinkjavaapi.BaseService.executeXmlRpcCall(BaseService.java:92)
at
br.eti.kinoshita.testlinkjavaapi.TestCaseService.reportTCResult(TestCaseService.java:634)
at
br.eti.kinoshita.testlinkjavaapi.TestLinkAPI.reportTCResult(TestLinkAPI.java:1115)
at
hudson.plugins.testlink.TestLinkSite.updateTestCase(TestLinkSite.java:166)
at
hudson.plugins.testlink.result.AbstractJUnitResultSeeker.handleResult(AbstractJUnitResultSeeker.java:82)
at
hudson.plugins.testlink.result.JUnitCaseNameResultSeeker.seek(JUnitCaseNameResultSeeker.java:98)
at
hudson.plugins.testlink.TestLinkBuilder.perform(TestLinkBuilder.java:158)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703)
at hudson.model.Build$RunnerImpl.build(Build.java:178)
at hudson.model.Build$RunnerImpl.doRun(Build.java:139)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:473)
at hudson.model.Run.run(Run.java:1408)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
{code}
So, maybe it is a trivial problem of one additional field in plugin options
configuration on jenkins job?
was (Author: jar):
Oh, I have found what it's supported from 3.0 version (JENKINS-9054).. only
for TAP. How it should be used?
Is it possible to have it for JUnit?
No, if I run _Test Plan_ with platform I get an exception
{code}
br.eti.kinoshita.testlinkjavaapi.TestLinkAPIException: (reportTCResult) -
Parameter platformname OR platformid is required, but has not been provided
at
br.eti.kinoshita.testlinkjavaapi.BaseService.checkResponseError(BaseService.java:119)
at
br.eti.kinoshita.testlinkjavaapi.BaseService.executeXmlRpcCall(BaseService.java:92)
at
br.eti.kinoshita.testlinkjavaapi.TestCaseService.reportTCResult(TestCaseService.java:634)
at
br.eti.kinoshita.testlinkjavaapi.TestLinkAPI.reportTCResult(TestLinkAPI.java:1115)
at
hudson.plugins.testlink.TestLinkSite.updateTestCase(TestLinkSite.java:166)
at
hudson.plugins.testlink.result.AbstractJUnitResultSeeker.handleResult(AbstractJUnitResultSeeker.java:82)
at
hudson.plugins.testlink.result.JUnitCaseNameResultSeeker.seek(JUnitCaseNameResultSeeker.java:98)
at
hudson.plugins.testlink.TestLinkBuilder.perform(TestLinkBuilder.java:158)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703)
at hudson.model.Build$RunnerImpl.build(Build.java:178)
at hudson.model.Build$RunnerImpl.doRun(Build.java:139)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:473)
at hudson.model.Run.run(Run.java:1408)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
{code}
So, maybe it is a trivial problem of one additional field in plugin options
configuration on jenkins job?
> JUnit test results are getting wrongly attached to all the test cases
> -
>
> Key: JENKINS-12810
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12810
> Project: Jenkins
> Issue Type: Bug
> Components: testlink
>Affects Versions: current
>Reporter: Vignesh Senapathy
>Assignee: Bruno P. Kinoshita
> Fix For: current
>
> Attachments: 1.jpg, 2.jpg, 3.jpg, last_tc.png,
> screenshot20120228152415.jpg, screenshot20120228152511.jpg, tc1.png, tc2.png,
> testlink-3.1-alpha2.hpi
>
>
> Hi,
> I am using the Testlink Jenkins plugin and when i run my jobs in Jenkins the
> Junit Test results are getting generated. This in turn calls the Testlink xml
> rpc and attaches the
[JIRA] (JENKINS-12810) JUnit test results are getting wrongly attached to all the test cases
[
https://issues.jenkins-ci.org/browse/JENKINS-12810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159693#comment-159693
]
Jaroslavas D. edited comment on JENKINS-12810 at 3/1/12 8:03 AM:
-
Oh, I have found what it's supported from 3.0 version (JENKINS-9054).. only for
TAP. How it should be used?
Is it possible to have it for JUnit?
No, if I run _Test Plan_ with platform I get an exception
{code}
br.eti.kinoshita.testlinkjavaapi.TestLinkAPIException: (reportTCResult) -
Parameter platformname OR platformid is required, but has not been provided
at
br.eti.kinoshita.testlinkjavaapi.BaseService.checkResponseError(BaseService.java:119)
at
br.eti.kinoshita.testlinkjavaapi.BaseService.executeXmlRpcCall(BaseService.java:92)
at
br.eti.kinoshita.testlinkjavaapi.TestCaseService.reportTCResult(TestCaseService.java:634)
at
br.eti.kinoshita.testlinkjavaapi.TestLinkAPI.reportTCResult(TestLinkAPI.java:1115)
at
hudson.plugins.testlink.TestLinkSite.updateTestCase(TestLinkSite.java:166)
at
hudson.plugins.testlink.result.AbstractJUnitResultSeeker.handleResult(AbstractJUnitResultSeeker.java:82)
at
hudson.plugins.testlink.result.JUnitCaseNameResultSeeker.seek(JUnitCaseNameResultSeeker.java:98)
at
hudson.plugins.testlink.TestLinkBuilder.perform(TestLinkBuilder.java:158)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703)
at hudson.model.Build$RunnerImpl.build(Build.java:178)
at hudson.model.Build$RunnerImpl.doRun(Build.java:139)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:473)
at hudson.model.Run.run(Run.java:1408)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
{code}
So, maybe it is a trivial problem of one additional field in plugin options
configuration on jenkins job?
was (Author: jar):
Oh, I have found what it's supported from 3.0 version (JENKINS-9054).. only
for TAP. How it should be used?
Is it possible to have it for JUnit?
> JUnit test results are getting wrongly attached to all the test cases
> -
>
> Key: JENKINS-12810
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12810
> Project: Jenkins
> Issue Type: Bug
> Components: testlink
>Affects Versions: current
>Reporter: Vignesh Senapathy
>Assignee: Bruno P. Kinoshita
> Fix For: current
>
> Attachments: 1.jpg, 2.jpg, 3.jpg, last_tc.png,
> screenshot20120228152415.jpg, screenshot20120228152511.jpg, tc1.png, tc2.png,
> testlink-3.1-alpha2.hpi
>
>
> Hi,
> I am using the Testlink Jenkins plugin and when i run my jobs in Jenkins the
> Junit Test results are getting generated. This in turn calls the Testlink xml
> rpc and attaches the results to the test case, but the test results are
> attached wrongly. The 1st test case has 6 results, the next has 5 and so on
> and the last one has 1 test result attached to it. I dont know if it is bug
> which is causing this. Please let me know what seems to be the problems. Also
> the execution flags are correctly rendered in this. which ever test case
> fails is marked as failed and which passed is marked as passed.
> Also I have one custom field which maps to the test suite name and test
> classname.
--
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-11327) NUnit plugin: fails to find report files for nontrivial file pattern
[ https://issues.jenkins-ci.org/browse/JENKINS-11327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Heinrich resolved JENKINS-11327. --- Fix Version/s: current Resolution: Not A Defect Just came across this ticket while searching for another issue. Filenames in the example contain Tests-results.xml, but patterns are Test-results.xml (without 's'!). Sorry for jumping in at this point. I am quite sure, there is no use in open tickets for resolved(?) issues. > NUnit plugin: fails to find report files for nontrivial file pattern > > > Key: JENKINS-11327 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11327 > Project: Jenkins > Issue Type: Bug > Components: nunit >Affects Versions: current >Reporter: Simon Hoffmann >Assignee: redsolo > Fix For: current > > > I have a project that uses a custom workspace. The NUnit test reports are > written to a directory "Output\Log" relative to the workspace root, together > with other kinds of log files. > If I specify "Output\Log\*.Test-reports.xml" or > "Output\Log\*Test-reports.xml" in the "Test report XMLs" field, recording the > results fails with: > > Recording NUnit tests results > > FATAL: No NUnit test report files were found. Configuration error? > > Build step 'Publish NUnit test result report' marked build as failure > If I reduce the pattern to "Output\Log\*.xml", the NUnit reports are found > (only now there are other, non-NUnit files matched as well). -- 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
