[JIRA] (JENKINS-11938) Jenkins loses builds when restarted
[
https://issues.jenkins-ci.org/browse/JENKINS-11938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161832#comment-161832
]
Blazej Mirowski commented on JENKINS-11938:
---
Hi,
I have exactly the same problem. My workaround for this is to run this script
before Jenkins start:
path=/var/lib/jenkins/jobs
`find $path -name build.xml -print0 | xargs -0 sed -i '//,/<\/file>/d'`
but this is only workaround ... I have created a bug report for this:
https://issues.jenkins-ci.org/browse/JENKINS-13536
> Jenkins loses builds when restarted
> ---
>
> Key: JENKINS-11938
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11938
> Project: Jenkins
> Issue Type: Bug
> Components: other, versionnumber
>Affects Versions: current
> Environment: tomcat 7.0.22
> windows server 2008 r2
>Reporter: Ben Dean
>
> Jenkins version 1.437
> If I stop the Apache Tomcat windows service, a bunch of my builds disappear
> from the history of the jobs. The missing builds are still on disk in the
> build folder, it just doesn't "find" them when making the history list.
> The jobs that lose history use the version number plugin and I had recently
> changed the version format from "4.3.${BUILDS_ALL_TIME}" to
> "4.4.${BUILDS_ALL_TIME}". The builds that disappear are all those after I
> changed this format. Also affects jobs that are downstream from those with
> version number changes.
> I could not find any Component related to the build history for a job. If
> someone knows what that should be feel free to change this. Also, sorry if
> there's not enough (or to much) information, this is the first Jenkins bug I
> have filed.
--
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-12130) cppcheck plugin will not fail build if more than one severity.evaluation is checked
[ https://issues.jenkins-ci.org/browse/JENKINS-12130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gbois resolved JENKINS-12130. - Resolution: Fixed This issue was fixed in previous version > cppcheck plugin will not fail build if more than one severity.evaluation is > checked > --- > > Key: JENKINS-12130 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12130 > Project: Jenkins > Issue Type: Bug > Components: cppcheck >Affects Versions: current > Environment: I'm running Jenkins 1.443 on a 64 bit CentOS 5.5 machine. >Reporter: brianii >Assignee: gbois > Labels: plugin > Fix For: current > > > I want to run the cppcheck plugin in a manner that will evaluate the sum of > errors and warnings to determine if my build should become unstable or fail. > I have my severity.evaluation (note that this is misspelled on the gui as > 'severiry.evaluation') configured with both severity 'error' and severity > 'warning' checked. I also have my 'Build Status' thresholds set to '0' as I > want any error or warning to fail the build. I had a build with an error in > it and my build did not fail. I've worked this issue into a small test > project and saw the same results. > Here is the console output for a project with severity evaluation configured > to consider both errors and warnings and the build status thresholds set to > '0', and a cppcheck.xml file with a single error: > Started by user anonymous > Building on master > [workspace] $ /bin/bash -xe /tmp/hudson127869.sh > + touch regtestout.xml > + touch junit.xml > [Cppcheck] Starting the cppcheck analysis. > [Cppcheck] Processing 1 files with the pattern 'cppcheck.xml'. > [Cppcheck] [WARNING] - The source file > 'file:/var/hudson/workspace/drra-mysql-32/drra/src/RecTemplate.cpp' doesn't > exist on the slave. The ability to display its source code has been removed. > [Cppcheck] Not changing build status, since no threshold has been exceeded > [Cppcheck] Ending the cppcheck analysis. > Finished: SUCCESS > Here is the console output of the same project ran with severity evaluation > configured to consider just errors (no longer warnings) and the build status > thresholds set to '0', and a cppcheck.xml file with a single error: > Started by user anonymous > Building on master > [workspace] $ /bin/bash -xe /tmp/hudson127860.sh > + touch regtestout.xml > + touch junit.xml > [Cppcheck] Starting the cppcheck analysis. > [Cppcheck] Processing 1 files with the pattern 'cppcheck.xml'. > [Cppcheck] [WARNING] - The source file > 'file:/var/hudson/workspace/drra-mysql-32/drra/src/RecTemplate.cpp' doesn't > exist on the slave. The ability to display its source code has been removed. > [Cppcheck] Setting build status to FAILURE since total number of errors > (severity 'error') exceeds the threshold value ;0'. > [Cppcheck] Ending the cppcheck analysis. > Build step 'Publish Cppcheck results' changed build result to FAILURE > Finished: FAILURE > So it appears as though the only way to get the cppcheck plugin to fail a > build is if the severity is only evaluated for a single severity level. If > multiple severity levels are configured the build will not fail. -- 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-13533) Maven build fails on CleanTempFilesAction#tempFiles serialization
[ https://issues.jenkins-ci.org/browse/JENKINS-13533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161834#comment-161834 ] domi commented on JENKINS-13533: Sorry, I'm not able to reproduce the issue... can you give me some more hints on this one? - you provide a a configuration file - right? how many? - in the maven build config, do you select a provided settings.xml from the drop down? - has the build worked with the old version? - did this occur right with the first build after the upgrade? - did this occur after the build failed because of an other issue first? - was the previous build successful with the same configuration and plugin version? - was the previous build executed on the same slave? > Maven build fails on CleanTempFilesAction#tempFiles serialization > - > > Key: JENKINS-13533 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13533 > Project: Jenkins > Issue Type: Bug > Components: config-file-provider > Environment: config-file-provider 2.1 > Jenkins 1.460 >Reporter: mdp >Assignee: domi > > A Maven project build (on a remote slave) fails with: > org.apache.maven.InternalErrorException: Internal error: > java.lang.RuntimeException: Failed to serialize > hudson.model.Actionable#actions for class hudson.maven.MavenModuleSetBuild > at > org.apache.maven.lifecycle.internal.BuilderCommon.handleBuildError(BuilderCommon.java:128) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:95) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at > org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239) > at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158) > at hudson.maven.Maven3Builder.call(Maven3Builder.java:98) > at hudson.maven.Maven3Builder.call(Maven3Builder.java:64) > at hudson.remoting.UserRequest.perform(UserRequest.java:118) > at hudson.remoting.UserRequest.perform(UserRequest.java:48) > at hudson.remoting.Request$2.run(Request.java:287) > at > hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > Caused by: java.lang.RuntimeException: Failed to serialize > hudson.model.Actionable#actions for class hudson.maven.MavenModuleSetBuild > at > hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:167) > at > hudson.util.RobustReflectionConverter$2.visit(RobustReflectionConverter.java:135) > at > com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.visitSerializableFields(PureJavaReflectionProvider.java:130) > at > hudson.util.RobustReflectionConverter.doMarshal(RobustReflectionConverter.java:120) > at > hudson.util.RobustReflectionConverter.marshal(RobustReflectionConverter.java:94) > at > com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:68) > at > com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:78) > at > com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:63) > at > com.thoughtworks.xstream.core.TreeMarshaller.start(TreeMarshaller.java:98) > at > com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.marshal(AbstractTreeMarshallingStrategy.java:38) > at com.thoughtworks.xstream.XStream.marshal(XStream.java
[JIRA] (JENKINS-13533) Maven build fails on CleanTempFilesAction#tempFiles serialization
[ https://issues.jenkins-ci.org/browse/JENKINS-13533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161834#comment-161834 ] domi edited comment on JENKINS-13533 at 4/21/12 10:26 AM: -- Sorry, I'm not able to reproduce the issue... can you give me some more hints on this one? - you provide a a configuration file - right? how many? - in the maven build config, do you select a provided settings.xml from the drop down? - has the build worked with the old version? - did this occur right with the first build after the upgrade? - did this occur after the build failed because of an other issue first? - was the previous build successful with the same configuration and plugin version? - was the previous build executed on the same slave? could you please also provide the build.xml of the failed and the previous build? was (Author: domi): Sorry, I'm not able to reproduce the issue... can you give me some more hints on this one? - you provide a a configuration file - right? how many? - in the maven build config, do you select a provided settings.xml from the drop down? - has the build worked with the old version? - did this occur right with the first build after the upgrade? - did this occur after the build failed because of an other issue first? - was the previous build successful with the same configuration and plugin version? - was the previous build executed on the same slave? > Maven build fails on CleanTempFilesAction#tempFiles serialization > - > > Key: JENKINS-13533 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13533 > Project: Jenkins > Issue Type: Bug > Components: config-file-provider > Environment: config-file-provider 2.1 > Jenkins 1.460 >Reporter: mdp >Assignee: domi > > A Maven project build (on a remote slave) fails with: > org.apache.maven.InternalErrorException: Internal error: > java.lang.RuntimeException: Failed to serialize > hudson.model.Actionable#actions for class hudson.maven.MavenModuleSetBuild > at > org.apache.maven.lifecycle.internal.BuilderCommon.handleBuildError(BuilderCommon.java:128) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:95) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at > org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239) > at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158) > at hudson.maven.Maven3Builder.call(Maven3Builder.java:98) > at hudson.maven.Maven3Builder.call(Maven3Builder.java:64) > at hudson.remoting.UserRequest.perform(UserRequest.java:118) > at hudson.remoting.UserRequest.perform(UserRequest.java:48) > at hudson.remoting.Request$2.run(Request.java:287) > at > hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > Caused by: java.lang.RuntimeException: Failed to serialize > hudson.model.Actionable#actions for class hudson.maven.MavenModuleSetBuild > at > hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:167) > at > hudson.util.RobustReflectionConverter$2.visit(RobustReflectionConverter.java:135) > at > com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.visitSerializableFields(PureJavaReflectionProvider.java:130) > at > hudson.util.RobustReflectionCo
[JIRA] (JENKINS-13542) Backslashes in Environment / Script-Variables are not quoted correctly for Groovy
Peter Schaefer created JENKINS-13542: Summary: Backslashes in Environment / Script-Variables are not quoted correctly for Groovy Key: JENKINS-13542 URL: https://issues.jenkins-ci.org/browse/JENKINS-13542 Project: Jenkins Issue Type: Bug Components: scripttrigger Affects Versions: current Environment: Windows Reporter: Peter Schaefer Assignee: gbois Priority: Minor Under windows, the variable "WORKSPACE" usually contains backward-shlashes (i.e. "C:\Jenkins\foo\bar"). Trying to assign a string variable like String baz = "$WORKSPACE\\sandbox"; is not possible. After the variables are substitued Groovy complains about illegal character, since the statement looks like this: String baz = "C:\Jenkins\foo\bar\\sandbox"; ^ illegal escape sequence -- 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-13518) Wrong JSON syntax
[
https://issues.jenkins-ci.org/browse/JENKINS-13518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161835#comment-161835
]
domi commented on JENKINS-13518:
I'm not able to reproduce this issue :(
the issue is not about the boolean, the problem is that [ {"":"","builder": ]
should not be there at all, but thats nothing the plugin has anything to do
with...
- which version of the plugin do you use?
- is this through the WebGUI or do you use any other API? XML, JSON, CLI?
- does this always happen?
- what else can you tell me about the configuration? do you have any wrapping
step around the scriptler step? (e.g. conditional-build-step)?
> Wrong JSON syntax
> -
>
> Key: JENKINS-13518
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13518
> Project: Jenkins
> Issue Type: Bug
> Components: scriptler
>Affects Versions: current
> Environment: OSX 10.7.3
> java version "1.6.0_31"
> Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3635)
> Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode)
> Jenkins 1.460
>Reporter: Florian Schwab
>Assignee: domi
> Labels: plugin
>
> If I try adding a script with scriptler to a job I get the following
> exception:
> Failed to parse form data. Please report this problem as a bug
> JSON={"":"","builder":{"backupJobName":"","builderId":"","defineParams":false,"kind":"org.jenkinsci.plugins.scriptler.builder.ScriptlerBuilder","parameters":[{"name":"","value":""},{"name":"","value":""}],"scriptlerScriptId":"testOutput.groovy","stapler-class":"org.jenkinsci.plugins.scriptler.builder.ScriptlerBuilder"},"core:apply":"","description":"","displayNameOrNull":"","name":"test","properties":{"hudson-model-ParametersDefinitionProperty":{},"org-jenkinsci-plugins-envinject-EnvInjectJobProperty":{},"stapler-class-bag":"true"},"scm":{"value":"0"}}
> net.sf.json.JSONException: JSONObject["defineParams"] is not a JSONObject.
> at net.sf.json.JSONObject.getJSONObject(JSONObject.java:1759)
> at
> org.jenkinsci.plugins.scriptler.util.UIHelper.extractParameters(UIHelper.java:22)
> at
> org.jenkinsci.plugins.scriptler.builder.ScriptlerBuilder$DescriptorImpl.newInstance(ScriptlerBuilder.java:161)
> at
> org.jenkinsci.plugins.scriptler.builder.ScriptlerBuilder$DescriptorImpl.newInstance(ScriptlerBuilder.java:109)
> at
> hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:912)
> at
> hudson.model.Descriptor.newInstancesFromHeteroList(Descriptor.java:899)
> at hudson.util.DescribableList.rebuildHetero(DescribableList.java:184)
> at hudson.model.Project.submit(Project.java:197)
> at hudson.model.Job.doConfigSubmit(Job.java:990)
> at hudson.model.AbstractProject.doConfigSubmit(AbstractProject.java:665)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288)
> at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151)
> at
> org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90)
> at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111)
> at
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
> at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241)
> at
> org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
> at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659)
> at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488)
> at org.kohsuke.stapler.Stapler.service(Stapler.java:162)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:45)
> at winstone.ServletConfiguration.execute(ServletConfiguration.java:248)
> at winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
> at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376)
> at
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95)
> at
> hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74)
> at
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
> at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
> at winstone.FilterConfiguration.execute(FilterConfiguration.java
[JIRA] (JENKINS-13542) Backslashes in Environment / Script-Variables are not quoted correctly for Groovy
[
https://issues.jenkins-ci.org/browse/JENKINS-13542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161836#comment-161836
]
Peter Schaefer commented on JENKINS-13542:
--
Great. Escaping issues even here in the Wiki-text! It was meant to be
{noformat}
String baz = "$WORKSPACE\\sandbox";
{noformat}
and
{noformat}
String baz = "C:\Jenkins\foo\bar\\sandbox";
^ illegal escape sequence
{noformat}
respectively.
> Backslashes in Environment / Script-Variables are not quoted correctly for
> Groovy
> -
>
> Key: JENKINS-13542
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13542
> Project: Jenkins
> Issue Type: Bug
> Components: scripttrigger
>Affects Versions: current
> Environment: Windows
>Reporter: Peter Schaefer
>Assignee: gbois
>Priority: Minor
>
> Under windows, the variable "WORKSPACE" usually contains backward-shlashes
> (i.e. "C:\Jenkins\foo\bar"). Trying to assign a string variable like
> String baz = "$WORKSPACE\\sandbox";
> is not possible. After the variables are substitued Groovy complains about
> illegal character, since the statement looks like this:
> String baz = "C:\Jenkins\foo\bar\\sandbox";
> ^ illegal escape sequence
--
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-13543) Cannot add Project Roles in Role Based Strategy Plug-In
John Van Lierde created JENKINS-13543:
-
Summary: Cannot add Project Roles in Role Based Strategy Plug-In
Key: JENKINS-13543
URL: https://issues.jenkins-ci.org/browse/JENKINS-13543
Project: Jenkins
Issue Type: Bug
Components: role-strategy
Affects Versions: current
Environment: Hudson 2.2.0
Role Based Strategy Plug In 1.1.2
Java - java version "1.6.0.05" ("java -version")
OS - HP-UX tdcndv01 B.11.31 U ia64 1579589996 unlimited-user license ("uname
-a")
Browser - IE8
Reporter: John Van Lierde
Assignee: Daniel Petisme
Attachments: HudsonRBS Manage Roles.png
In the "Manage and Assign Roles" screen. I cannot add project roles. I can
populate the "Role to add" and "Pattern" fields, but nothing happens when I
click on the Add button.I've tried various strings for Role and Pattern.
The plug in is not terribly useful without this functionality.
I can add Global Roles.
I was able to get this to work on Windows XP, but HP-UX is our production
environment.
(I saw this issue was mentioned on the plug in page and the maintainer as to
have the issue recorded here. I couldn't find any such issue, so I'm entering
here. My apologies if this is a duplicate.)
--
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-10651) Add cppcheck to "Dashboard View"
[ https://issues.jenkins-ci.org/browse/JENKINS-10651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gbois updated JENKINS-10651: Component/s: dashboard-view (was: cppcheck) Change component to dashboard-view. In my opinion, cppcheck plugin should not have any dependency to dashboard-view. It has to be independent. Therefore, I change the component issue. > Add cppcheck to "Dashboard View" > > > Key: JENKINS-10651 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10651 > Project: Jenkins > Issue Type: New Feature > Components: dashboard-view >Reporter: keperry >Assignee: gbois >Priority: Minor > > It would be awesome if the cppcheck plugin could be added to the > https://wiki.jenkins-ci.org/display/JENKINS/Dashboard+View. This is the only > plugin that I have right now that I can't get summary information for all my > projects in one place. Please add to the dashboard view plugin in the future. -- 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-10368) Wrong image dimension for Cppcheck Results link on Dashboard
[ https://issues.jenkins-ci.org/browse/JENKINS-10368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gbois resolved JENKINS-10368. - Resolution: Fixed > Wrong image dimension for Cppcheck Results link on Dashboard > - > > Key: JENKINS-10368 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10368 > Project: Jenkins > Issue Type: Bug > Components: cppcheck >Affects Versions: current > Environment: OS: Linux, openSUSE; > OS version: 11.4; > DE: LXDE; > WebBrowser: Mozilla Firefox 4.+. >Reporter: Sergey Piatakov >Assignee: gbois >Priority: Trivial > Attachments: cppcheck_plugin_version.png, > wrong_jenkins_image_on_cppcheck_build_detailed_page.png, > wrong_jenkins_image_on_cppcheck_dashboard.png, > wrong_jenkins_image_on_cppcheck_link.png > > > Wrong image for Cppcheck Results link on Dashboard. > Using file: http://jenkins:8080/plugin/cppcheck/icons/cppcheck-24.png > instead of: http://jenkins:8080/plugin/cppcheck/icons/cppcheck-48.png -- 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-10368) Wrong image dimension for Cppcheck Results link on Dashboard
[ https://issues.jenkins-ci.org/browse/JENKINS-10368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161838#comment-161838 ] SCM/JIRA link daemon commented on JENKINS-10368: Code changed in jenkins User: Gregory Boissinot Path: src/main/java/org/jenkinsci/plugins/cppcheck/util/AbstractCppcheckProjectAction.java http://jenkins-ci.org/commit/cppcheck-plugin/17d9731ff2990fafe1e4ca04638a34d30625192a Log: Fix JENKINS-10368 > Wrong image dimension for Cppcheck Results link on Dashboard > - > > Key: JENKINS-10368 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10368 > Project: Jenkins > Issue Type: Bug > Components: cppcheck >Affects Versions: current > Environment: OS: Linux, openSUSE; > OS version: 11.4; > DE: LXDE; > WebBrowser: Mozilla Firefox 4.+. >Reporter: Sergey Piatakov >Assignee: gbois >Priority: Trivial > Attachments: cppcheck_plugin_version.png, > wrong_jenkins_image_on_cppcheck_build_detailed_page.png, > wrong_jenkins_image_on_cppcheck_dashboard.png, > wrong_jenkins_image_on_cppcheck_link.png > > > Wrong image for Cppcheck Results link on Dashboard. > Using file: http://jenkins:8080/plugin/cppcheck/icons/cppcheck-24.png > instead of: http://jenkins:8080/plugin/cppcheck/icons/cppcheck-48.png -- 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-13217) Build Status page continues to show flashing "building" icons after build completion
[
https://issues.jenkins-ci.org/browse/JENKINS-13217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161839#comment-161839
]
dogfood commented on JENKINS-13217:
---
Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png!
[jenkins_ui-changes_branch
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
[FIXED JENKINS-13217] Build Status page continues to show flashing
"building" (Revision eb3e288d6e761109c20cf479c80dfb4c69801dbe)
Result = SUCCESS
Seiji Sogabe :
[eb3e288d6e761109c20cf479c80dfb4c69801dbe|https://github.com/jenkinsci/jenkins/commit/eb3e288d6e761109c20cf479c80dfb4c69801dbe]
Files :
* core/src/main/resources/lib/hudson/buildCaption.jelly
* changelog.html
> Build Status page continues to show flashing "building" icons after build
> completion
>
>
> Key: JENKINS-13217
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13217
> Project: Jenkins
> Issue Type: Bug
> Components: core
>Affects Versions: current
> Environment: Jenkins 1.456/ Ubuntu 11.10
>Reporter: Richard Mortimer
>Assignee: Richard Mortimer
>Priority: Minor
>
> The main build status page shows a 48x48 icon representing the build status.
> If you visit the page during the build this shows a flashing "build in
> progress" icon. However when the build stops the "build in progress" icon
> continues to be displayed.
> This is due to browser caching behaviour. For example the recent build at the
> following URL
> http://ci.jenkins-ci.org/job/tools_maven-hpi-plugin-maven-2.x/40/
> During the build the relevant markup was
> {code}
>
> Build #40
> (23-Mar-2012 01:18:30)
> {code}
> The request for buildStatus returned a HTTP 302 redirect to
> {code}
> Location:http://ci.jenkins-ci.org/images/48x48/blue_anime.gif
> {code}
> The combination of a 302 redirect and caching headers in the gif cause the
> browser to not re-request buildStatus within the same browser session.
> http://ci.jenkins-ci.org/job/tools_maven-hpi-plugin-maven-2.x/40/buildStatus
> Note this is unrelated to the recent changes for caching of images etc. I
> have noticed this in the past but have not had time to investigate before now.
--
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-13319) Change icon for repeatableDeleteButton and show tooltip on it
[ https://issues.jenkins-ci.org/browse/JENKINS-13319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161840#comment-161840 ] dogfood commented on JENKINS-13319: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/] Result = SUCCESS > Change icon for repeatableDeleteButton and show tooltip on it > - > > Key: JENKINS-13319 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13319 > Project: Jenkins > Issue Type: Improvement > Components: ui-changes >Reporter: OHTAKE Tomohiro >Assignee: OHTAKE Tomohiro >Priority: Minor > > Currently icon for repeatableDeleteButton is "edit-delete.png". [1] > Change it to "user-trash.png". [3] > Discussions: (written in Japanese) > [1] https://twitter.com/#!/ohtaket/status/186631033582657538 > [2] https://twitter.com/#!/kohsukekawa/status/186913466391597056 > [3] https://twitter.com/#!/ohtaket/status/186977316025540609 > [4] https://twitter.com/#!/kohsukekawa/status/186978692772278272 > [5] https://twitter.com/#!/ohtaket/status/186983488975679488 > [6] https://twitter.com/#!/kohsukekawa/status/186983938441494529 -- 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-12037) CLI - I/O error in channel Chunked connection/Unexpected termination of the channel - still occurring in Jenkins 1.449
[ https://issues.jenkins-ci.org/browse/JENKINS-12037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161841#comment-161841 ] dogfood commented on JENKINS-12037: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/] [FIXED JENKINS-12037] CLI - I/O error in channel Chunked connection (Revision ea1b80aebe85a9414d5befd58e976d85818a258d) Result = SUCCESS richm : [ea1b80aebe85a9414d5befd58e976d85818a258d|https://github.com/jenkinsci/jenkins/commit/ea1b80aebe85a9414d5befd58e976d85818a258d] Files : * cli/src/main/java/hudson/cli/CLI.java * changelog.html > CLI - I/O error in channel Chunked connection/Unexpected termination of the > channel - still occurring in Jenkins 1.449 > -- > > Key: JENKINS-12037 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12037 > Project: Jenkins > Issue Type: Bug > Components: cli > Environment: * Running on SLES9 Linux server with 4 CPUs and plenty > of diskspace. > * Tomcat 7.0.22 > * JDK 1.6.0_14 > * Only ONE Master configuration - no slaves are configured > * 3 Executors - (one less than the max number of CPUs) >Reporter: mark streit >Priority: Critical > Attachments: jenkins-timeout, Tomcat7_Jenkins1449_logs.zip > > > We reported an issue some time back that was also listed as fixed in Jenkins > 1.441: > Log: > [FIXED JENKINS-11130] SEVERE: I/O error in channel Chunked connection when > using jenkins-cli.jar > Perhaps another bug should NOT be submitted so I have added the following > comments below the line to the original defect 11130 comments section in case > it can be reviewed/re-opened. > We did NOT try to make any adjustments to the Tomcat configuration: > Tomcat Connector connectionUploadTimeout > but we are also now seeing the same problem with Winstone when at this same > 1.441 level. We did revert to the 1.438 version of the CLI (leaving the WAR > at 1.441 running in Winstone) and that is serving asthe current workaround. > > We have downloaded and installed the LATEST 1.441 release that lists the fix > for this problem. Currently we were running 1.438 on Winstone only (since > with Tomcat 6 or 7, we had experienced the error HOWEVER yet under Winstone, > it worked OK so that was our workaround - while running 1.438). > Now with Jenkins 1.441 - we are getting the ERROR again and NOW WITH BOTH > Winstone and the Tomcat configurations). We have left the Jenkins 1.441 WAR > file in place running on Winstone, and reverted the CLI jar file back to the > 1.438 version for now and that appears to work again with Winstone. > Checked Manifest of CLI jar downloaded with the 1.441 WAR installation: > Manifest-Version: 1.0 > Archiver-Version: Plexus Archiver > Created-By: Apache Maven > Built-By: kohsuke > Build-Jdk: 1.6.0_26 > Main-Class: hudson.cli.CLI > Jenkins-CLI-Version: 1.441 > Under Tomcat 7, we get this stacktrace: > Started by command line > [workspace] $ /bin/bash -xe > /opt/apache-tomcat-7.0.22_jenkins/temp/hudson3281734817830.sh > + /opt/Sun/jdk1.6.0_14/bin/java -jar /opt/Sun/jdk1.6.0_14/lib/jenkins-cli.jar > -s http://11.22.33.44:8082/jenkins/ build XYZ_Project-SharedLibs -s -p > SVN_PATH=trunk > Dec 5, 2011 12:59:11 PM hudson.remoting.Channel$ReaderThread run > SEVERE: I/O error in channel Chunked connection to > http://11.22.33.44:8082/jenkins/cli > java.io.IOException: Unexpected termination of the channel > at hudson.remoting.Channel$ReaderThread.run(Channel.java:1115) > Caused by: java.io.EOFException > at > java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2554) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1297) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) > at hudson.remoting.Channel$ReaderThread.run(Channel.java:1109) > Exception in thread "main" hudson.remoting.RequestAbortedException: > hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected > termination of the channel > at hudson.remoting.Request.call(Request.java:149) > at hudson.remoting.Channel.call(Channel.java:681) > at > hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158) > at $Proxy2.main(Unknown Source) > at hudson.cli.CLI.execute(CLI.java:200) > at hudson.cli.CLI._main(CLI.java:330) > at hudson.cli.CLI.main(CLI.java:245) > Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: > Unexpected termination of the channel > at hudson.remoting.Request.abort(Request.java:273) > at hudson.remoting.Channel.terminat
[JIRA] (JENKINS-13389) Move "View as plain text" link on console output page from top right to the sidepanel.
[ https://issues.jenkins-ci.org/browse/JENKINS-13389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161843#comment-161843 ] dogfood commented on JENKINS-13389: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/] [FIXED JENKINS-13389] Moved "View as plain text" link on console output page from top right to (Revision 7681ab09828251640d2ca1508eef1027fb8afa9c) Result = SUCCESS Fred G : [7681ab09828251640d2ca1508eef1027fb8afa9c|https://github.com/jenkinsci/jenkins/commit/7681ab09828251640d2ca1508eef1027fb8afa9c] Files : * core/src/main/resources/hudson/model/AbstractBuild/tasks_da.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_zh_TW.properties * core/src/main/resources/hudson/model/Run/console_sv_SE.properties * core/src/main/resources/hudson/model/Run/console_pl.properties * core/src/main/resources/hudson/model/Run/console_sk.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_lt.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_pt_PT.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_bg.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_is.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_el.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_zh_CN.properties * core/src/main/resources/hudson/model/Run/console.jelly * core/src/main/resources/hudson/model/Run/console_ro.properties * core/src/main/resources/hudson/model/Run/console_fi.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_ko.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_ca.properties * core/src/main/resources/hudson/model/Run/console_nb_NO.properties * core/src/main/resources/hudson/model/Run/console_tr.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_cs.properties * core/src/main/resources/hudson/model/Run/console_he.properties * core/src/main/resources/hudson/model/Run/console_zh_TW.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_lv.properties * core/src/main/resources/hudson/model/Run/console_it.properties * core/src/main/resources/hudson/model/Run/console_hu.properties * core/src/main/resources/hudson/model/Run/console_es.properties * core/src/main/resources/hudson/model/Run/console_cs.properties * core/src/main/resources/hudson/model/Run/console_pt_PT.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_pl.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_hi_IN.properties * core/src/main/resources/hudson/model/Run/console_de.properties * core/src/main/resources/hudson/model/Run/console_pt_BR.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_hu.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_de.properties * core/src/main/resources/hudson/model/Run/console_eo.properties * core/src/main/resources/hudson/model/Run/console_is.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_sv_SE.properties * core/src/main/resources/hudson/model/Run/console_nl.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_he.properties * core/src/main/resources/hudson/model/Run/console_el.properties * core/src/main/resources/hudson/model/Run/console_fr.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_ja.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_es.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_ru.properties * core/src/main/resources/hudson/model/Run/console_ru.properties * core/src/main/resources/hudson/model/Run/console_lt.properties * core/src/main/resources/hudson/model/Run/console_ja.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_pt_BR.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_ro.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_it.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_uk.properties * core/src/main/resources/hudson/model/Run/console_hi_IN.properties * core/src/main/resources/hudson/model/Run/console_uk.properties * core/src/main/resources/hudson/model/Run/console_ca.properties * core/src/main/resources/hudson/model/Run/console_lv.properties * core/src/main/resources/hudson/model/Run/console_da.properties * core/src/main/resources/hudson/model/Run/console_ko.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_nb_NO.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_eo.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_fi.properties * core/src/main/resources/hudson/model/Run/console_bg.properties * core/src/main/resources/hudson/model/AbstractBuild/tasks_tr.properties * core/src/main/resources/hudson/model/Abstrac
[JIRA] (JENKINS-12302) Remote call on CLI channel from [ip] failed
[
https://issues.jenkins-ci.org/browse/JENKINS-12302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161842#comment-161842
]
dogfood commented on JENKINS-12302:
---
Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png!
[jenkins_ui-changes_branch
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
[JENKINS-12302] (Revision 7110ddb7d2a2f141a6887ffe352526db91046867)
Result = SUCCESS
Kohsuke Kawaguchi :
[7110ddb7d2a2f141a6887ffe352526db91046867|https://github.com/jenkinsci/jenkins/commit/7110ddb7d2a2f141a6887ffe352526db91046867]
Files :
* core/src/main/java/hudson/cli/CLICommand.java
> Remote call on CLI channel from [ip] failed
> ---
>
> Key: JENKINS-12302
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12302
> Project: Jenkins
> Issue Type: Bug
> Components: cli, groovy
>Affects Versions: current
> Environment: Jenkins 1.446, Linux CentOS
>Reporter: Markus Hjerto
>Assignee: vjuranek
>
> I've had a KillStuckPolling.groovy job running for about 6 months without
> problems, but on January 4th it stopped working with the below stack trace.
> This matches with the release of Jenkins 1.446, which is currently installed.
> I have tried to restart the server without any effect.
> {noformat}
> Killing all stuck SCM polls using ~/bin/KillStuckPolling.groovy
> log4j:WARN No appenders could be found for logger
> (org.apache.commons.beanutils.converters.BooleanConverter).
> log4j:WARN Please initialize the log4j system properly.
> java.io.IOException: Remote call on CLI channel from /[ip] failed
> at hudson.remoting.Channel.call(Channel.java:690)
> at hudson.cli.GroovyCommand.loadScript(GroovyCommand.java:106)
> at hudson.cli.GroovyCommand.run(GroovyCommand.java:93)
> at hudson.cli.CLICommand.main(CLICommand.java:205)
> at hudson.cli.CliManagerImpl.main(CliManagerImpl.java:66)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:274)
> at
> hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:255)
> at
> hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:215)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:287)
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
> at java.util.concurrent.FutureTask.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
> Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.ExceptionInInitializerError
> at java.io.ObjectStreamClass.hasStaticInitializer(Native Method)
> at java.io.ObjectStreamClass.computeDefaultSUID(Unknown Source)
> at java.io.ObjectStreamClass.access$100(Unknown Source)
> at java.io.ObjectStreamClass$1.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.io.ObjectStreamClass.getSerialVersionUID(Unknown Source)
> at java.io.ObjectStreamClass.initNonProxy(Unknown Source)
> at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
> at java.io.ObjectInputStream.readClassDesc(Unknown Source)
> at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
> at java.io.ObjectInputStream.readObject0(Unknown Source)
> at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
> at java.io.ObjectInputStream.readSerialData(Unknown Source)
> at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
> at java.io.ObjectInputStream.readObject0(Unknown Source)
> at java.io.ObjectInputStream.readObject(Unknown Source)
> at hudson.remoting.UserRequest.deserialize(UserRequest.java:182)
> at hudson.remoting.UserRequest.perform(UserRequest.java:98)
> ... 8 more
> Caused by: java.lang.NullPointerException
> at hudson.cli.CLICommand.(CLICommand.java:448)
> ... 26 more
> Build step 'Execute shell' marked build as failure
> {noformat}
> The groovy script is as follows:
> {code:title=KillStuckPolling.groovy|borderStyle=solid}
> Thread.getAllStackTraces().keySet().each() {
>item ->
>println "Checking item" + item.getNa
[JIRA] (JENKINS-13416) On demand slave provisioning is starting all available slaves
[ https://issues.jenkins-ci.org/browse/JENKINS-13416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161844#comment-161844 ] dogfood commented on JENKINS-13416: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/] [FIXED JENKINS-13416] On demand slave provisioning is starting all available slaves (Revision 5a32eca331bf1d5652ab908c356f0ed64de82c6f) Result = SUCCESS Kohsuke Kawaguchi : [5a32eca331bf1d5652ab908c356f0ed64de82c6f|https://github.com/jenkinsci/jenkins/commit/5a32eca331bf1d5652ab908c356f0ed64de82c6f] Files : * core/src/main/java/hudson/slaves/RetentionStrategy.java > On demand slave provisioning is starting all available slaves > - > > Key: JENKINS-13416 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13416 > Project: Jenkins > Issue Type: Bug > Components: slave-setup >Affects Versions: current >Reporter: Bruno Meneguello >Assignee: Kohsuke Kawaguchi >Priority: Minor > Attachments: jenkins-1.459.diff > > > I'm using on demand slaves (on amazon) started by a shell script. When > starting a job with all slaves disconnected, all my slaves are started > together. > When in debug, I'd noticed that "RetentionStrategy" "Demand" is testing > "Computer.getDemandStartMilliseconds()" to connect the slave, but all slaves > (that 'll take some time to wake up) pass in test. > Shouldn't this strategy take in account if there are executor enough and > nodes starting? > I,ve made a change in RetentionStrategy that solves the problem. Anyone see > any problem with this solution? -- 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-13387) Convert "Delete this build" buttons into links in the sidepanel
[ https://issues.jenkins-ci.org/browse/JENKINS-13387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161845#comment-161845 ] dogfood commented on JENKINS-13387: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/] [FIXED JENKINS-13387] Converted "Delete this build" buttons into links in the sidepanel, added (Revision be88e0120fef6d5837ef9adf9b7803cbdde88b30) Result = SUCCESS Fred G : [be88e0120fef6d5837ef9adf9b7803cbdde88b30|https://github.com/jenkinsci/jenkins/commit/be88e0120fef6d5837ef9adf9b7803cbdde88b30] Files : * core/src/main/resources/hudson/matrix/MatrixBuild/delete_de.properties * core/src/main/resources/hudson/model/Run/delete.jelly * core/src/main/resources/hudson/model/AbstractBuild/index.jelly * core/src/main/resources/hudson/matrix/MatrixBuild/delete_ja.properties * core/src/main/resources/hudson/model/AbstractBuild/sidepanel.jelly * core/src/main/resources/hudson/matrix/MatrixBuild/delete.jelly * core/src/main/resources/hudson/matrix/MatrixBuild/confirmDeleteAll_de.properties * core/src/main/resources/hudson/model/Run/delete.properties > Convert "Delete this build" buttons into links in the sidepanel > --- > > Key: JENKINS-13387 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13387 > Project: Jenkins > Issue Type: Improvement > Components: gui, ui-changes >Reporter: Fred G >Assignee: Fred G > Labels: gui > Attachments: DeleteBuildButtons_MatrixBuild.png, > DeleteBuildButtons_MatrixConfig.png, DeleteBuildLinks_MatrixBuild.png, > DeleteBuildLinks_MatrixConfig.png > > > The "Delete this build" buttons on build pages and also the "Delete this > build and all configurations of this build" buttons on matrix build pages > should be converted to links in the sidepanel of the respective pages (see > Screenshots). > This simplifies the user experience of deleting an object (see the "Delete > Project" link in the sidepanel of project pages). > Having the links in the sidepanel also makes them accessible through the > newly added context menus that came with the breadcrumbs. > Recent discussion about this topic: > https://github.com/jenkinsci/jenkins/pull/403 -- 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-13238) Loading All Build History Fails
[ https://issues.jenkins-ci.org/browse/JENKINS-13238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161846#comment-161846 ] dogfood commented on JENKINS-13238: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/] [FIXED JENKINS-13238] Loading All Build History Fails (Revision a45ecf45ee8571aae7a0273784971afeeefb6e3c) Result = SUCCESS Seiji Sogabe : [a45ecf45ee8571aae7a0273784971afeeefb6e3c|https://github.com/jenkinsci/jenkins/commit/a45ecf45ee8571aae7a0273784971afeeefb6e3c] Files : * core/src/main/resources/hudson/widgets/HistoryWidget/index.jelly > Loading All Build History Fails > --- > > Key: JENKINS-13238 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13238 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: linux, jenkins 1.456 >Reporter: Spencer Oliver >Assignee: sogabe > > seems after the update from 1.455 to 1.456 causes an issue where pressing > 'More' to expand the job Build History now fails with a 404. > Calling the build history directly also causes the 404, eg. > http://openocd.zylin.com/jenkins/job/openocd/buildHistory/all/ > For info rolling back to 1.455 cures the problem. > tested 1.457 and issue still present. > jenkins own server also shows the issue: > http://ci.jenkins-ci.org/view/All/job/jenkins_main_trunk/buildHistory/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-13448) Guice injector failure can cause failure of whole Jenkins
[ https://issues.jenkins-ci.org/browse/JENKINS-13448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161848#comment-161848 ] dogfood commented on JENKINS-13448: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/] [FIXED JENKINS-13448] Added additional checks if Guice will be able to create injector to exclude missing extension poins. (Revision 6788f82a2c9f8e3580440913c2d39f1d1dc3ad70) Result = SUCCESS Vojtech Juranek : [6788f82a2c9f8e3580440913c2d39f1d1dc3ad70|https://github.com/jenkinsci/jenkins/commit/6788f82a2c9f8e3580440913c2d39f1d1dc3ad70] Files : * core/src/main/java/hudson/ExtensionFinder.java > Guice injector failure can cause failure of whole Jenkins > - > > Key: JENKINS-13448 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13448 > Project: Jenkins > Issue Type: Bug > Components: core >Reporter: vjuranek >Priority: Critical > > When Guice fails to create injector (e.g. because some extension point is > optional and therefore missing), it can break other plugins and eventually > crash whole Jenkins, see e.g. JENKINS-12970, JENKINS-13385, JENKINS-13381. -- 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-13505) Apply bootstrap style to "hetero-list-add" buttons
[
https://issues.jenkins-ci.org/browse/JENKINS-13505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161849#comment-161849
]
dogfood commented on JENKINS-13505:
---
Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png!
[jenkins_ui-changes_branch
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
[FIXED JENKINS-13505] Apply bootstrap style to "hetero-list-add" buttons
(Revision 84549d6220ac4ed0d7633e85eb8aed2cc69d56ca)
Result = SUCCESS
ohtake.tomohiro :
[84549d6220ac4ed0d7633e85eb8aed2cc69d56ca|https://github.com/jenkinsci/jenkins/commit/84549d6220ac4ed0d7633e85eb8aed2cc69d56ca]
Files :
* core/src/main/resources/lib/form/hetero-list.jelly
* war/src/main/webapp/scripts/hudson-behavior.js
> Apply bootstrap style to "hetero-list-add" buttons
> --
>
> Key: JENKINS-13505
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13505
> Project: Jenkins
> Issue Type: Improvement
> Components: ui-changes
>Reporter: OHTAKE Tomohiro
>Assignee: OHTAKE Tomohiro
>Priority: Minor
>
> Most of the buttons have been converted from YUI to Bootstrap.
> But "hetero-list-add" buttons are still YUI.
> We should apply Bootstrap style to "hetero-list-add" buttons.
> An example of "hetero-list-add" is:
> {code}
> Add build step â–¾
> Execute shell
> Invoke Ant
> ...
> {code}
--
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-12647) Jetty configuration causes locked files when running tests on Windows, which causes test failures
[ https://issues.jenkins-ci.org/browse/JENKINS-12647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161847#comment-161847 ] dogfood commented on JENKINS-12647: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/] [FIXED JENKINS-12647] (Revision 7ae303f88191a540491a21484316d63dff775e21) Result = SUCCESS Kohsuke Kawaguchi : [7ae303f88191a540491a21484316d63dff775e21|https://github.com/jenkinsci/jenkins/commit/7ae303f88191a540491a21484316d63dff775e21] Files : * test/src/main/java/org/jvnet/hudson/test/HudsonTestCase.java > Jetty configuration causes locked files when running tests on Windows, which > causes test failures > - > > Key: JENKINS-12647 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12647 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Windows 7 x64 > Java 1.6 >Reporter: Slide-O-Mix >Assignee: Kohsuke Kawaguchi > Attachments: jenkins-12647.patch > > > When running tests on either the token-macro plugin or email-ext plugin that > create temporary files for the tests, the tests fail with an exception that > says those temporary files were not able to be deleted. I believe this is > related to [1] which, in summary, says that Jetty locks static files on > Windows. > [1] http://docs.codehaus.org/display/JETTY/Files+locked+on+Windows -- 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-11538) Jenkins serves existing files regardless of security
[ https://issues.jenkins-ci.org/browse/JENKINS-11538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161851#comment-161851 ] dogfood commented on JENKINS-11538: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/] [FIXED JENKINS-11538] integrated Stapler 1.187 that contains the fix. (Revision 9acf12f7976bd97bfa125e4b715ae340be8c1715) Result = SUCCESS Kohsuke Kawaguchi : [9acf12f7976bd97bfa125e4b715ae340be8c1715|https://github.com/jenkinsci/jenkins/commit/9acf12f7976bd97bfa125e4b715ae340be8c1715] Files : * core/pom.xml > Jenkins serves existing files regardless of security > > > Key: JENKINS-11538 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11538 > Project: Jenkins > Issue Type: Bug > Components: security, www >Affects Versions: current > Environment: Jenkins 1.436, Windows 7 64-bit SP1, build-in Winstone > servlet engine 0.9.10 >Reporter: Steve Betts >Priority: Critical > > an url of the form (note the dot): https://WEB-INF./web.xml will > return the file, even with security turned on and the client unauthenticated. > As will any other url that references a valid filename with a '.' after the > first directory name, such as https:///scripts./behavior.js. > these behaviors are considered culnerabilites by our large corporation. > http://xforce.iss.net/xforce/xfdb/9446 > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-1858 -- 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-8043) "Reload Configuration from Disk" loses labels for swarm-clients
[ https://issues.jenkins-ci.org/browse/JENKINS-8043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161850#comment-161850 ] dogfood commented on JENKINS-8043: -- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/] [Fixed JENKINS-8043] "Reload Configuration from Disk" broke swarm clients (Revision 24c31d138fe7b9ff14870b921220bdf709af20cc) Result = SUCCESS Seiji Sogabe : [24c31d138fe7b9ff14870b921220bdf709af20cc|https://github.com/jenkinsci/jenkins/commit/24c31d138fe7b9ff14870b921220bdf709af20cc] Files : * core/src/main/java/jenkins/model/Jenkins.java > "Reload Configuration from Disk" loses labels for swarm-clients > --- > > Key: JENKINS-8043 > URL: https://issues.jenkins-ci.org/browse/JENKINS-8043 > Project: Jenkins > Issue Type: Bug > Components: swarm >Reporter: voorth >Assignee: abayer > -- 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-13129) Updating built-in plugins doesn't work, the file doesn't get pinned and is overwritten on the next startup
[ https://issues.jenkins-ci.org/browse/JENKINS-13129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161853#comment-161853 ] dogfood commented on JENKINS-13129: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/] [Fixed JENKINS-13129] Updating built-in plugins doesn't work, the file doesn't get pinned and is overwritten on the next startup (Revision 2453985ca5f4cb2c824466d132fe3658020b72fe) Result = SUCCESS alexlehm : [2453985ca5f4cb2c824466d132fe3658020b72fe|https://github.com/jenkinsci/jenkins/commit/2453985ca5f4cb2c824466d132fe3658020b72fe] Files : * test/src/test/java/hudson/PluginManagerTest2.java * core/src/main/java/hudson/PluginManager.java > Updating built-in plugins doesn't work, the file doesn't get pinned and is > overwritten on the next startup > -- > > Key: JENKINS-13129 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13129 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: jenkins 1.456, tomcat 7.0.25, java 1.6.0-31 running on > windows vista >Reporter: Alex Lehmann >Assignee: Alex Lehmann >Priority: Critical > > I still cannot update cvs or subversion plugins without manually creating a > .pinned file. > When e.g. updating cvs plugin 1.6 (shipped with jenkins.war) to 2.1, the file > is installed into the plugin dir, but no cvs.jpi.pinned file is created. When > restarting the tomcat server, the file is replaced by the 1.6 version from > the war directory. -- 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-8663) Parsing of POM happens before SNAPSHOT-Parents are updated
[ https://issues.jenkins-ci.org/browse/JENKINS-8663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161854#comment-161854 ] dogfood commented on JENKINS-8663: -- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/] [FIXED JENKINS-8663] Flag -U is not used during the parsing step of a (Revision 1421ca15d5a36706214476e613eeab789b9066df) Result = SUCCESS Vincent Latombe : [1421ca15d5a36706214476e613eeab789b9066df|https://github.com/jenkinsci/jenkins/commit/1421ca15d5a36706214476e613eeab789b9066df] Files : * maven-plugin/src/main/java/hudson/maven/MavenEmbedderRequest.java * maven-plugin/src/main/java/hudson/maven/MavenUtil.java * changelog.html * maven-plugin/src/main/java/hudson/maven/MavenModuleSetBuild.java > Parsing of POM happens before SNAPSHOT-Parents are updated > -- > > Key: JENKINS-8663 > URL: https://issues.jenkins-ci.org/browse/JENKINS-8663 > Project: Jenkins > Issue Type: Bug > Components: maven2 >Affects Versions: current > Environment: Hudson 1.394 >Reporter: Stephan Pauxberger >Priority: Blocker > > Given the following constellation. > Project A 1.0-SNAPSHOT (POM only) > Project B 1.0-SNAPSHOT (Jar, has A as parent) > Both jobs use private Maven repositories. > Both projects have a separate job. > Change something in project A, commit. Job A builds and deploys to repository > Change something in project B that dependes on changes in project A. Commit. > Job B starts an resolves the POM using the old parent POM, potentially > leading to a broken build. > For example: B declares a dependency WITH a version. Now remove the version > from B and enter a dependencyManagement entry into A. Commit A, later B. > Result: B fails because pom validation has no valid version for the > dependency. > Only solution (since private repositories are used): Clean workspace of B via > Webinterface, the rebuild B. -- 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-5784) Usage of kill in logrotate script is non-portable
[
https://issues.jenkins-ci.org/browse/JENKINS-5784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161855#comment-161855
]
dogfood commented on JENKINS-5784:
--
Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png!
[jenkins_ui-changes_branch
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
[FIXED JENKINS-5784] (Revision 8fb2f5162e499b5c0c4dc8f88af761b7c490bc38)
Result = SUCCESS
Kohsuke Kawaguchi :
[8fb2f5162e499b5c0c4dc8f88af761b7c490bc38|https://github.com/jenkinsci/jenkins/commit/8fb2f5162e499b5c0c4dc8f88af761b7c490bc38]
Files :
* rpm/SOURCES/jenkins.logrotate
* changelog.html
> Usage of kill in logrotate script is non-portable
> -
>
> Key: JENKINS-5784
> URL: https://issues.jenkins-ci.org/browse/JENKINS-5784
> Project: Jenkins
> Issue Type: Bug
> Components: other
>Reporter: rombert
> Attachments: hudson.logrotate.patch2010-10-20pdurbin,
> jenkins-logrotate.patch
>
>
> The logrotate script uses
> {code}kill -SIGALRM `cat /var/run/hudson.pid`{code}
> which works fine for the bash builtin, but fails for /bin/kill, which only
> accepts
> {code}usage: kill [ -s signal | -p ] [ -a ] pid ...
>kill -l [ signal ]{code}
> on CentOS 5.
> Using kill -s SIGALRM would make both variants happy and increase portability.
--
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-13122) Last modification date of files in a zip are not the original timestamps
[ https://issues.jenkins-ci.org/browse/JENKINS-13122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161856#comment-161856 ] dogfood commented on JENKINS-13122: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/] [FIXED JENKINS-13122] Last modification date of files in a zip are not the original timestamps (Revision 3ddd6bfc2bbfc8e2d4e6f6e22f00b32fb623843d) Result = SUCCESS Seiji Sogabe : [3ddd6bfc2bbfc8e2d4e6f6e22f00b32fb623843d|https://github.com/jenkinsci/jenkins/commit/3ddd6bfc2bbfc8e2d4e6f6e22f00b32fb623843d] Files : * core/src/main/java/hudson/util/io/ZipArchiver.java * changelog.html > Last modification date of files in a zip are not the original timestamps > > > Key: JENKINS-13122 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13122 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current >Reporter: Cees Bos >Assignee: sogabe > > When do have archiving for a build, then the files on the master have the > original timestamps of the file (same as on the slave). > But when you download it in a zip with '(all files in zip)' then the last > modification date of file is the datetime of that moment, instead of original. > We have a job which archives a number of logfiles. Normally you can order it > on datetime to get the last logfile, but when you download it in a zip > ordering is impossible. -- 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-12457) 'Age' column on 'Test Result' tab may show incorrect value when a test suite divided into multiple junit files
[
https://issues.jenkins-ci.org/browse/JENKINS-12457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161857#comment-161857
]
dogfood commented on JENKINS-12457:
---
Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png!
[jenkins_ui-changes_branch
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
Revert "[FIXED JENKINS-12457] 'Age' column on 'Test Result' tab may show
incorrect value when a test suite divided into multiple junit files" (Revision
7fba652710e64f6dce00e2e186e77ee2a39bd445)
[Re-FIXED JENKINS-12457] 'Age' column on 'Test Result' tab may show incorrect
value when a test suite divided into multiple junit files (Revision
d9e87705e8d693bc9d028e1da8c614c0fb736cd3)
Result = SUCCESS
Christoph Kutzinski :
[7fba652710e64f6dce00e2e186e77ee2a39bd445|https://github.com/jenkinsci/jenkins/commit/7fba652710e64f6dce00e2e186e77ee2a39bd445]
Files :
* core/src/test/resources/hudson/tasks/junit/eclipse-plugin-test-report.xml
* core/src/main/java/hudson/tasks/junit/TestResult.java
* core/src/main/java/hudson/tasks/junit/SuiteResult.java
* core/src/test/java/hudson/tasks/junit/TestResultTest.java
* core/src/main/java/hudson/tasks/junit/CaseResult.java
Christoph Kutzinski :
[d9e87705e8d693bc9d028e1da8c614c0fb736cd3|https://github.com/jenkinsci/jenkins/commit/d9e87705e8d693bc9d028e1da8c614c0fb736cd3]
Files :
*
core/src/test/resources/hudson/tasks/junit/JENKINS-12457/TestSuite_b_duplicate.xml
* core/src/test/java/hudson/tasks/junit/TestResultTest.java
* changelog.html
* core/src/test/resources/hudson/tasks/junit/JENKINS-12457/TestSuite_b.xml
* core/src/main/java/hudson/tasks/junit/CaseResult.java
* core/src/test/resources/hudson/tasks/junit/JENKINS-12457/TestSuite_a2.xml
* core/src/test/resources/hudson/tasks/junit/JENKINS-12457/TestSuite_a1.xml
* core/src/main/java/hudson/tasks/junit/TestResult.java
> 'Age' column on 'Test Result' tab may show incorrect value when a test suite
> divided into multiple junit files
> --
>
> Key: JENKINS-12457
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12457
> Project: Jenkins
> Issue Type: Improvement
> Components: junit
>Affects Versions: current
>Reporter: Greg Temchenko
>Assignee: kutzi
>
> Somebody described the problem a year ago here:
> http://jenkins.361315.n4.nabble.com/Problem-with-Age-column-on-Test-Results-tab-td3172208.html
> {quote}
> I have a problem with 'Age' column on 'Test Results' tab. For couple of my
> tests, all the time this column has value equals '1', despite the fact that
> those tests start failing earlier than one build ago. When I switch to
> 'History' tab, in 'Test Result' column there is a 'Regression' value for all
> builds, and it should be 'Regression' value only for the first build and
> 'Failed' for next builds.
> {quote}
> For me this happens because I have many junit xmls that containing the same
> test suite name.
> In this case hudson.tasks.junit.CaseResult.getPreviousResult() gets the only
> last junit xml result and if it's not failed then the Age column won't be
> calculated properly.
--
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-13105) allow j/k navigation for search results
[ https://issues.jenkins-ci.org/browse/JENKINS-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161858#comment-161858 ] dogfood commented on JENKINS-13105: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/] [JENKINS-13105] for keyboard shortcuts plugin, allow j/k navigation for search results (Revision 5a0f1aa3a4da962bf29ebca6a4556f1617045005) changelog entry for JENKINS-13105 (Revision 0414b057a14c2c74a32eeab182df532ca7d16673) Result = SUCCESS Jesse Farinacci : [5a0f1aa3a4da962bf29ebca6a4556f1617045005|https://github.com/jenkinsci/jenkins/commit/5a0f1aa3a4da962bf29ebca6a4556f1617045005] Files : * core/src/main/resources/hudson/search/Search/search-failed.jelly Olivier Lamy : [0414b057a14c2c74a32eeab182df532ca7d16673|https://github.com/jenkinsci/jenkins/commit/0414b057a14c2c74a32eeab182df532ca7d16673] Files : * changelog.html > allow j/k navigation for search results > --- > > Key: JENKINS-13105 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13105 > Project: Jenkins > Issue Type: New Feature > Components: keyboard-shortcuts >Reporter: jieryn >Assignee: jieryn > > e.g. results page for :: > http://ci.jenkins-ci.org/view/Plugins/search/?q=perforce -- 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-13195) New Breadcrumb bar covers search suggestions
[ https://issues.jenkins-ci.org/browse/JENKINS-13195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161852#comment-161852 ] dogfood commented on JENKINS-13195: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/] [Fix JENKINS-13195] New Breadcrumb bar covers search suggestions (Revision 3c5d7cc38aace954e08fbe4968427db132d30a2d) Result = SUCCESS Vincent Latombe : [3c5d7cc38aace954e08fbe4968427db132d30a2d|https://github.com/jenkinsci/jenkins/commit/3c5d7cc38aace954e08fbe4968427db132d30a2d] Files : * war/src/main/webapp/css/style.css * changelog.html > New Breadcrumb bar covers search suggestions > > > Key: JENKINS-13195 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13195 > Project: Jenkins > Issue Type: Bug > Components: core > Environment: Tested on Chrome (Ubuntu) Firefox (Ubuntu) and IE > (Windows) >Reporter: Marc Robinson >Priority: Minor > > When using the search box the search suggestions box is drawn behind the > breadcrumb bar. The result is the first few search suggestions cannot be > viewed. -- 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-12994) Quiet period is blocking other jobs in queue
[ https://issues.jenkins-ci.org/browse/JENKINS-12994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161859#comment-161859 ] dogfood commented on JENKINS-12994: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/] [FIX JENKINS-12994] Quiet period is blocking other jobs in queue (Revision 394e9d6c0488fae6834d97a158a018abb31f3179) Update changelog for JENKINS-12994 (Revision 07b3f2cccb077df85617f2748f9b329528bc263b) Result = SUCCESS Vincent Latombe : [394e9d6c0488fae6834d97a158a018abb31f3179|https://github.com/jenkinsci/jenkins/commit/394e9d6c0488fae6834d97a158a018abb31f3179] Files : * core/src/main/java/hudson/model/Queue.java Vincent Latombe : [07b3f2cccb077df85617f2748f9b329528bc263b|https://github.com/jenkinsci/jenkins/commit/07b3f2cccb077df85617f2748f9b329528bc263b] Files : * changelog.html > Quiet period is blocking other jobs in queue > > > Key: JENKINS-12994 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12994 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: teetoivo >Priority: Critical > > Starting from version 1.452, a job in queue waiting for the quiet period to > pass is blocking all other jobs that have been queued after it. > Example: > # Job A has quiet period set to 10 seconds > # Job B has quiet period set to 300 seconds > # Job C has quiet period set to 100 seconds > # Jobs get queued in A-B-C order. > # Job A starts executing after 10 seconds > # After 100 seconds, status of job C changes to "pending - Waiting for next > available executor" even if free executors are available > # After 300 seconds both jobs B and C start executing > This problem is hardly visible when short quiet periods are used but becomes > problematic with longer quiet periods or plugins like Naginator that will > increase the quiet period to hours if the builds fail enough. > Version 1.451 is the last release where this problem isn't visible. From > public releases, at least 1.452 and 1.454 are affected. -- 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-13165) Cloning workspace loses hidden files/directories
[ https://issues.jenkins-ci.org/browse/JENKINS-13165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161860#comment-161860 ] dogfood commented on JENKINS-13165: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/] [JENKINS-13165] Added a test to reproduce the problem to no avail. (Revision 2b5a24c9b0ec6c3f1feedde080aa3196f419ae40) Result = SUCCESS Kohsuke Kawaguchi : [2b5a24c9b0ec6c3f1feedde080aa3196f419ae40|https://github.com/jenkinsci/jenkins/commit/2b5a24c9b0ec6c3f1feedde080aa3196f419ae40] Files : * test/src/test/java/hudson/FileSystemProvisionerTest.java > Cloning workspace loses hidden files/directories > > > Key: JENKINS-13165 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13165 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Linux >Reporter: owenmehegan >Assignee: Kohsuke Kawaguchi > > I upgraded to Jenkins 1.456 today, and now my jobs that use the Clone > Workspace plugin are having problems because the workspace tar.gz that is > created when the job completes no longer includes the .git directory. In > 1.449, which I ended up downgrading back to, the default setting for files to > include always pulls that in. I've verified this by running tar -tzf on the > workspace.tar.gz; in 1.449 .git is there, in 1.456 it isn't. > I wasn't able to force Jenkins to include it either. I tried putting "**/, > **/.git" and other variations on that in the list of files to include, but > none of them seemed to work. -- 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-13454) Optimize the plugin manager
[ https://issues.jenkins-ci.org/browse/JENKINS-13454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161861#comment-161861 ] dogfood commented on JENKINS-13454: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/] [FIXED JENKINS-13454] Optimize the plugin manager (Revision e465f7202e42b0cb196e98c2e21abedcb85e60d4) Result = SUCCESS unknown : [e465f7202e42b0cb196e98c2e21abedcb85e60d4|https://github.com/jenkinsci/jenkins/commit/e465f7202e42b0cb196e98c2e21abedcb85e60d4] Files : * core/src/main/java/hudson/model/UpdateSite.java > Optimize the plugin manager > --- > > Key: JENKINS-13454 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13454 > Project: Jenkins > Issue Type: Improvement > Components: update-center > Environment: Jenkins 1.459, Oracle JDK 1.7, Windows XP >Reporter: evernat >Assignee: evernat > Attachments: monitoring.png > > > In "Manage Jenkins", the plugin manager (aka update center) is rather slow. > Slow is about 3 to 6 seconds on my windows laptop. > The http requests of the plugin manager are mostly the slowest of all, as can > be seen in the joined screenshot of the monitoring plugin. > The screenshot also shows that those http requests have a high cpu usage. > The cause of the issue is that for each plugin, the > UpdateSite.getPlugin(String) and getData() methods read and parse all the > plugins data from the "updates/default.json" file each time. > So the more plugins are available, the slower it is. > I will submit a pull request. -- 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-13476) Broken user experience when searching on /pluginManager/available
[ https://issues.jenkins-ci.org/browse/JENKINS-13476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161863#comment-161863 ] dogfood commented on JENKINS-13476: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/] [FIXED JENKINS-13476] added filter to the update center. (Revision 26974746d68043825f02abbc0c8ab6200e8d465f) Result = SUCCESS Kohsuke Kawaguchi : [26974746d68043825f02abbc0c8ab6200e8d465f|https://github.com/jenkinsci/jenkins/commit/26974746d68043825f02abbc0c8ab6200e8d465f] Files : * changelog.html > Broken user experience when searching on /pluginManager/available > - > > Key: JENKINS-13476 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13476 > Project: Jenkins > Issue Type: Bug > Components: ui-changes >Affects Versions: current > Environment: Jenkins 1.460 >Reporter: sebastian_bergmann > Attachments: screenshot.png > > > 1. Browse to /pluginManager/available > 2. CTRL+F (Find in Mozilla Firefox) > 3. Enter Git, for instance > 4. Browser scrolls to the location of the search result > 5. Search result is hidden behind the "Install ..." / "Download ..." overlay -- 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-3681) Hide Empty Tabs (Views) in the GUI
[ https://issues.jenkins-ci.org/browse/JENKINS-3681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161862#comment-161862 ] dogfood commented on JENKINS-3681: -- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/] [FIXED JENKINS-3681] Added View.READ permission. (Revision 85e13303f8cfbebeb7dab347fda8ccf4069070b6) Result = SUCCESS Kohsuke Kawaguchi : [85e13303f8cfbebeb7dab347fda8ccf4069070b6|https://github.com/jenkinsci/jenkins/commit/85e13303f8cfbebeb7dab347fda8ccf4069070b6] Files : * core/src/main/java/hudson/model/ViewGroupMixIn.java * core/src/main/resources/hudson/model/Messages.properties * core/src/main/java/hudson/security/AuthorizationStrategy.java * changelog.html * core/src/main/java/hudson/model/View.java > Hide Empty Tabs (Views) in the GUI > -- > > Key: JENKINS-3681 > URL: https://issues.jenkins-ci.org/browse/JENKINS-3681 > Project: Jenkins > Issue Type: Improvement > Components: gui >Affects Versions: current > Environment: Platform: All, OS: All >Reporter: rnell > > I'd like the ability to hide tabs that have no visible jobs. We use Project > Based Security to limit development access to only their projects. I don't > like > that developers can still see all tabs used by the other groups, even though > they are empty due to the security settings. -- 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-13282) ui-changes breadcrumbs should stick to top
[
https://issues.jenkins-ci.org/browse/JENKINS-13282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161865#comment-161865
]
dogfood commented on JENKINS-13282:
---
Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png!
[jenkins_ui-changes_branch
#21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/]
Result = SUCCESS
> ui-changes breadcrumbs should stick to top
> --
>
> Key: JENKINS-13282
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13282
> Project: Jenkins
> Issue Type: New Feature
> Components: ui-changes
>Reporter: OHTAKE Tomohiro
>Assignee: OHTAKE Tomohiro
>
> Comment by KK
> http://groups.google.com/group/jenkinsci-dev/browse_thread/thread/61d571f2be751121/659c24674d13542c?show_docid=659c24674d13542c
> {quote}
> - The menu of the top banner doesn't seem very useful to me. Right now it
> always shows the same 4 things from the action menu of the top page, which is
> probably not what you intended. But even if it changes per page, I think it'd
> end up just repeating what's on the left.
> - I liked our recent breadcrumb that sticks to the top of the page.
> {quote}
> I agree with him because:
> - Jenkins pages are highly hierarchical. Breadcrumbs may become longer
> especially when we use JUnit Test Result, Analysis Plugins and Nested View.
> - The first item of the breadcumbs provides a link to root. I don't think
> a.brand should be always visible.
> - I seldom click "USER_NAME | log out" links.
--
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-13185) Computer.getHostName() returns null when it is not
[ https://issues.jenkins-ci.org/browse/JENKINS-13185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161864#comment-161864 ] dogfood commented on JENKINS-13185: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_ui-changes_branch #21|http://ci.jenkins-ci.org/job/jenkins_ui-changes_branch/21/] Fix for JENKINS-13185: If there is a fallback host.name specified, it should return that and not null. (Revision 3629aebce4ee0a432baefa9e95cdc31a316a1c78) add changelog entry for [JENKINS-13185] (Revision 196aadc61eefecf92fd78bd96b1c98f221e8a179) Result = SUCCESS andrew : [3629aebce4ee0a432baefa9e95cdc31a316a1c78|https://github.com/jenkinsci/jenkins/commit/3629aebce4ee0a432baefa9e95cdc31a316a1c78] Files : * core/src/main/java/hudson/model/Computer.java Olivier Lamy : [196aadc61eefecf92fd78bd96b1c98f221e8a179|https://github.com/jenkinsci/jenkins/commit/196aadc61eefecf92fd78bd96b1c98f221e8a179] Files : * changelog.html > Computer.getHostName() returns null when it is not > -- > > Key: JENKINS-13185 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13185 > Project: Jenkins > Issue Type: Patch > Components: core >Affects Versions: current >Reporter: Andrew Stone >Priority: Minor > Attachments: getHostName.patch > > > The current version of Computer.getHostName() returns null even if the > fallback returns a value. -- 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-11114) Separate errors report on build report page by severity type.
[ https://issues.jenkins-ci.org/browse/JENKINS-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161866#comment-161866 ] SCM/JIRA link daemon commented on JENKINS-4: Code changed in jenkins User: Gregory Boissinot Path: src/main/java/org/jenkinsci/plugins/cppcheck/CppcheckResult.java src/main/java/org/jenkinsci/plugins/cppcheck/CppcheckSummary.java src/main/resources/org/jenkinsci/plugins/cppcheck/Messages.properties http://jenkins-ci.org/commit/cppcheck-plugin/f637c8350d3525978e31290989075a1ca0ed061a Log: Fix JENKINS-4 Compare: https://github.com/jenkinsci/cppcheck-plugin/compare/a605f92...f637c83 > Separate errors report on build report page by severity type. > - > > Key: JENKINS-4 > URL: https://issues.jenkins-ci.org/browse/JENKINS-4 > Project: Jenkins > Issue Type: Improvement > Components: cppcheck > Environment: Not important. >Reporter: Sergey Piatakov >Assignee: gbois >Priority: Minor > Attachments: current_report.png, proposed_report.jpeg > > > Separate errors report on build report page by severity type. -- 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-10880) Git plugin fails on remote Poll
[ https://issues.jenkins-ci.org/browse/JENKINS-10880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161867#comment-161867 ] dogfood commented on JENKINS-10880: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_main_trunk #1668|http://ci.jenkins-ci.org/job/jenkins_main_trunk/1668/] [JENKINS-10880] output the job when polling fails (Revision 7066daf3ee9d75d427918b068293e5b4ebbc98cd) Result = SUCCESS mguenther : [7066daf3ee9d75d427918b068293e5b4ebbc98cd|https://github.com/jenkinsci/jenkins/commit/7066daf3ee9d75d427918b068293e5b4ebbc98cd] Files : * core/src/main/java/hudson/triggers/SCMTrigger.java > Git plugin fails on remote Poll > --- > > Key: JENKINS-10880 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10880 > Project: Jenkins > Issue Type: Bug > Components: git >Affects Versions: current >Reporter: robertdw >Assignee: Kohsuke Kawaguchi >Priority: Minor > > If you enable remote polling in the Git Plugin, the project will never poll > successfully, and stops other projects polling as well. > In GitSCM, requiresWorkspaceForPolling() returns false if remotePoll is > enabled. > https://github.com/jenkinsci/git-plugin/blob/git-1.1.12/src/main/java/hudson/plugins/git/GitSCM.java#L582 > This mean that in the jenkins-core AbstractProject (at least on the LTS > branch), a null value is passed in for the workspace parameter to SCM.poll() > https://github.com/jenkinsci/jenkins/blob/jenkins-1.409.1/core/src/main/java/hudson/model/AbstractProject.java#L1305 > This ends up in 'compareRemoteRevisionWith' back in GitSCM. At line 651, the > call to 'workingDirectory(workspace)' returns null - because null was passed > in as a param from AbstractProject. This means that at line 657, the call to > !!workingDirectory.exists() results in a null pointer. > Suggested fix: remove the remotePoll, or make it require a workspace to do > the polling. > Stacktrace: > Sep 2, 2011 2:41:50 PM hudson.triggers.SCMTrigger$Runner runPolling > SEVERE: Failed to record SCM polling > java.lang.NullPointerException > at hudson.plugins.git.GitSCM.compareRemoteRevisionWith(GitSCM.java:657) > at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:354) > at hudson.scm.SCM.poll(SCM.java:371) > at hudson.model.AbstractProject.poll(AbstractProject.java:1305) > at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:420) > at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:449) > at hudson.triggers.SCMTrigger.run(SCMTrigger.java:103) > at hudson.triggers.SCMTrigger.run(SCMTrigger.java:83) > at hudson.triggers.Trigger$1.run(Trigger.java:229) > at hudson.DependencyRunner.run(DependencyRunner.java:73) > 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) -- 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-13524) Validate project naming regex immediately
[ https://issues.jenkins-ci.org/browse/JENKINS-13524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161868#comment-161868 ] dogfood commented on JENKINS-13524: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [jenkins_main_trunk #1668|http://ci.jenkins-ci.org/job/jenkins_main_trunk/1668/] [FIXED JENKINS-13524] Validate project naming regex immediately (Revision 5587d13f58b14bffa9f77f7433358e14add9bcfa) Result = SUCCESS Seiji Sogabe : [5587d13f58b14bffa9f77f7433358e14add9bcfa|https://github.com/jenkinsci/jenkins/commit/5587d13f58b14bffa9f77f7433358e14add9bcfa] Files : * core/src/main/resources/jenkins/model/ProjectNamingStrategy/PatternProjectNamingStrategy/config.groovy * core/src/main/resources/jenkins/model/Messages_ja.properties * core/src/main/resources/jenkins/model/Messages.properties * core/src/main/java/jenkins/model/ProjectNamingStrategy.java * changelog.html > Validate project naming regex immediately > - > > Key: JENKINS-13524 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13524 > Project: Jenkins > Issue Type: Improvement > Components: core >Reporter: Ben Golding >Assignee: sogabe >Priority: Minor > > Manage Jenkins --> Restrict project naming --> Strategy: Pattern --> Name > Pattern: > When trying to save the configuration, the regex should be checked for > correctness (e.g. matching parens) > Alternatively this could even be done in real time on the configuration page. > [Workaround: any regex errors will appear - and need to be fixed immediately > - when you try to configure/create a job] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11114) Separate errors report on build report page by severity type.
[ https://issues.jenkins-ci.org/browse/JENKINS-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gbois resolved JENKINS-4. - Resolution: Fixed > Separate errors report on build report page by severity type. > - > > Key: JENKINS-4 > URL: https://issues.jenkins-ci.org/browse/JENKINS-4 > Project: Jenkins > Issue Type: Improvement > Components: cppcheck > Environment: Not important. >Reporter: Sergey Piatakov >Assignee: gbois >Priority: Minor > Attachments: current_report.png, proposed_report.jpeg > > > Separate errors report on build report page by severity type. -- 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-11716) Renaming a job does not rename the build record root dir, for a Jenkins instance configured with this feature
[ https://issues.jenkins-ci.org/browse/JENKINS-11716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161869#comment-161869 ] Steve Roth commented on JENKINS-11716: -- This is still an issue with Jenkins v1.454. > Renaming a job does not rename the build record root dir, for a Jenkins > instance configured with this feature > - > > Key: JENKINS-11716 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11716 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current >Reporter: Steve Roth > > We have a Jenkins instance (1.438) using the 'Build Record Root Directory' > feature, so we can specify an alternate directory for storing build artifacts > outside of the JENKINS HOME directory. > This generally works fine. However, I noticed that when I rename a job, I > lose the previous build records. > I see a new build record directory is created, beneath the specified 'Build > Record Root Directory'. However, the old build directory also exists, > containing the previous records. They are not moved over to the new > directory. > In other words, when the 'Build Record Root Directory' feature is enabled, > renaming a project causes the project's build records to be lost. > Current workaround is to move the build record files over and use sed to > replace the project name in them, then restart Jenkins. -- 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-11716) When 'Build Record Root Directory' is enabled, renaming a job does not create a new BRRD dir for the renamed job, and does not rename/copy artifacts from the original BRRD
[
https://issues.jenkins-ci.org/browse/JENKINS-11716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Roth updated JENKINS-11716:
-
Summary: When 'Build Record Root Directory' is enabled, renaming a job
does not create a new BRRD dir for the renamed job, and does not rename/copy
artifacts from the original BRRD (was: Renaming a job does not rename the
build record root dir, for a Jenkins instance configured with this feature)
Description:
We have a Jenkins instance (1.438) using the 'Build Record Root Directory'
feature, so we can specify an alternate directory for storing build artifacts
outside of the JENKINS HOME directory.
The 'Build Record Root Directory' (set in configure system, then click
Advanced... button at the top), is set to
/scratch/jbuildroot/${ITEM_FULLNAME}/builds. The Workspace Root dir is set to
${ITEM_ROOTDIR}/workspace.
This generally works fine. However, I noticed that when I rename a job, I lose
the previous build records.
I see a new build record directory is created, beneath the specified 'Build
Record Root Directory'. However, the old build directory also exists,
containing the previous records. They are not moved over to the new directory.
In other words, when the 'Build Record Root Directory' feature is enabled,
renaming a project causes the project's build records to be lost.
Current workaround is to move the build record files over and use sed to
replace the project name in them, then restart Jenkins.
was:
We have a Jenkins instance (1.438) using the 'Build Record Root Directory'
feature, so we can specify an alternate directory for storing build artifacts
outside of the JENKINS HOME directory.
This generally works fine. However, I noticed that when I rename a job, I lose
the previous build records.
I see a new build record directory is created, beneath the specified 'Build
Record Root Directory'. However, the old build directory also exists,
containing the previous records. They are not moved over to the new directory.
In other words, when the 'Build Record Root Directory' feature is enabled,
renaming a project causes the project's build records to be lost.
Current workaround is to move the build record files over and use sed to
replace the project name in them, then restart Jenkins.
I noticed that in Jenkins v1.454, renaming a job does not even create the build
record root dir entry. For example, if I have build record root dir set to
/scratch/jbuildroot/${ITEM_FULLNAME}/builds and I rename a job 'foo' to 'bar',
then /scratch/jbuildroot/foo exists, but the rename does not create
/scratch/jbuildroot/bar.
I think in a previous version, this directory was at least created (though it
was empty), but in v1.454, I dont see it created anymore.
Updating the summary to reflect the new information.
> When 'Build Record Root Directory' is enabled, renaming a job does not create
> a new BRRD dir for the renamed job, and does not rename/copy artifacts from
> the original BRRD
> ---
>
> Key: JENKINS-11716
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11716
> Project: Jenkins
> Issue Type: Bug
> Components: core
>Affects Versions: current
>Reporter: Steve Roth
>
> We have a Jenkins instance (1.438) using the 'Build Record Root Directory'
> feature, so we can specify an alternate directory for storing build artifacts
> outside of the JENKINS HOME directory.
> The 'Build Record Root Directory' (set in configure system, then click
> Advanced... button at the top), is set to
> /scratch/jbuildroot/${ITEM_FULLNAME}/builds. The Workspace Root dir is set
> to ${ITEM_ROOTDIR}/workspace.
> This generally works fine. However, I noticed that when I rename a job, I
> lose the previous build records.
> I see a new build record directory is created, beneath the specified 'Build
> Record Root Directory'. However, the old build directory also exists,
> containing the previous records. They are not moved over to the new
> directory.
> In other words, when the 'Build Record Root Directory' feature is enabled,
> renaming a project causes the project's build records to be lost.
> Current workaround is to move the build record files over and use sed to
> replace the project name in them, then restart Jenkins.
--
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-11716) When 'Build Record Root Directory' is enabled, renaming a job does not create a new BRRD dir for the renamed job, and does not rename/copy artifacts from the original BRRD
[
https://issues.jenkins-ci.org/browse/JENKINS-11716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=158929#comment-158929
]
Steve Roth edited comment on JENKINS-11716 at 4/21/12 9:21 PM:
---
One shell script workaround for renaming the fileystem parts of job (presumes a
path like ${ITEM_FULLNAME}/builds is listed below. Save as 'renamejob.sh'.
First, backup your original job name directory, just in case.
Next, rename the job in the Jenkins UI.
Then run this script
Last, restart Jenkins (required).
Usage: renameJob.sh pathToBuildArtifactDir oldJobName newJobName
{code}
#!/bin/sh -eu
JOBROOT=$1
OLDJOB=$2
NEWJOB=$3
if [ ! -d $JOBROOT ]; then
echo "ERROR: directory at JOBROOT=$JOBROOT does not exist"
exit 1
fi
if [ ! -d $JOBROOT/$NEWJOB ]; then
mkdir -p $JOBROOT/$NEWJOB
#echo "ERROR: newjob directory at $JOBROOT/$NEWJOB does not exist"
#exit 1
fi
if [ ! -d $JOBROOT/$OLDJOB ]; then
echo "ERROR: oldjob directory at $JOBROOT/$OLDJOB does not exist"
exit 1
fi
echo "RENAMING JOB from $OLDJOB ==> $NEWJOB"
set +e
rm -rf $JOBROOT/$NEWJOB/builds/*
mv $JOBROOT/$OLDJOB/* $JOBROOT/$NEWJOB
set -e
echo "RENAMING OLD JOB TO END IN .old"
set +e
mv $JOBROOT/$OLDJOB $JOBROOT/${OLDJOB}.old
set -e
echo "UPDATING RUNS..."
for RUNDIR in `ls -d $JOBROOT/$NEWJOB/builds/2012*`; do
echo "... UPDATING RUN AT $RUNDIR"
if [ -f $JOBROOT/$RUNDIR/junitResult.xml ]; then
sed -i "s/$OLDJOB/$NEWJOB/g" $JOBROOT/$RUNDIR/junitResult.xml
fi
if [ -f $JOBROOT/$RUNDIR/build.xml ]; then
sed -i "s/$OLDJOB/$NEWJOB/g" $JOBROOT/$RUNDIR/build.xml
fi
done
echo "REMOVING .old JOB (this may fail if more work is needed)"
rmdir $JOBROOT/${OLDJOB}.old
{code}
was (Author: sroth):
One shell script workaround for renaming the fileystem parts of job
(presumes a path like ${ITEM_FULLNAME}/builds is listed below. Save as
'renamejob.sh'.
First, backup your original job name directory, just in case.
Next, rename the job in the Jenkins UI.
Then run this script
Last, restart Jenkins (required).
Usage: renameJob.sh oldJobName newJobName pathToBuildArtifactDir
#!/bin/sh -eu
OLDJOB=$1
NEWJOB=$2
JOBROOT=$3
if [ ! -d $JOBROOT ]; then
echo "ERROR: directory at JOBROOT=$JOBROOT does not exist"
exit 1
fi
if [ ! -d $JOBROOT/$NEWJOB ]; then
echo "ERROR: newjob directory at $JOBROOT/$NEWJOB does not exist"
exit 1
fi
if [ ! -d $JOBROOT/$OLDJOB ]; then
echo "ERROR: oldjob directory at $JOBROOT/$OLDJOB does not exist"
exit 1
fi
echo "RENAMING JOB from $OLDJOB ==> $NEWJOB"
set +e
rm -f $JOBROOT/last*
rm -rf $JOBROOT/$NEWJOB/builds/*
mv $JOBROOT/$OLDJOB/* $JOBROOT/$NEWJOB
set -e
echo "UPDATING RUNS..."
for RUNDIR in `ls -d $JOBROOT/$NEWJOB/builds/*-*-*`; do
echo "... UPDATING RUN AT $RUNDIR"
if [ -f $JOBROOT/$RUNDIR/junitResult.xml ]; then
sed -i "s/$OLDJOB/$NEWJOB/g" $JOBROOT/$RUNDIR/junitResult.xml
fi
if [ -f $JOBROOT/$RUNDIR/build.xml ]; then
sed -i "s/$OLDJOB/$NEWJOB/g" $JOBROOT/$RUNDIR/build.xml
fi
done
> When 'Build Record Root Directory' is enabled, renaming a job does not create
> a new BRRD dir for the renamed job, and does not rename/copy artifacts from
> the original BRRD
> ---
>
> Key: JENKINS-11716
> URL: https://issues.jenkins-ci.org/browse/JENKINS-11716
> Project: Jenkins
> Issue Type: Bug
> Components: core
>Affects Versions: current
>Reporter: Steve Roth
>
> We have a Jenkins instance (1.438) using the 'Build Record Root Directory'
> feature, so we can specify an alternate directory for storing build artifacts
> outside of the JENKINS HOME directory.
> The 'Build Record Root Directory' (set in configure system, then click
> Advanced... button at the top), is set to
> /scratch/jbuildroot/${ITEM_FULLNAME}/builds. The Workspace Root dir is set
> to ${ITEM_ROOTDIR}/workspace.
> This generally works fine. However, I noticed that when I rename a job, I
> lose the previous build records.
> I see a new build record directory is created, beneath the specified 'Build
> Record Root Directory'. However, the old build directory also exists,
> containing the previous records. They are not moved over to the new
> directory.
> In other words, when the 'Build Record Root Directory' feature is enabled,
> renaming a project causes the project's build records to be lost.
> Current workaround is to move the build record files over and use sed to
> replace the project name in them, then restart Jenkins.
--
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 in
[JIRA] (JENKINS-12364) Cannot drill down to source code with cppcheck when build source is checked out using SVN
[ https://issues.jenkins-ci.org/browse/JENKINS-12364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161871#comment-161871 ] SCM/JIRA link daemon commented on JENKINS-12364: Code changed in jenkins User: Gregory Boissinot Path: src/main/java/org/jenkinsci/CppcheckSourceContainer.java src/main/java/org/jenkinsci/plugins/cppcheck/CppcheckPublisher.java src/main/java/org/jenkinsci/plugins/cppcheck/CppcheckResult.java http://jenkins-ci.org/commit/cppcheck-plugin/e5d5192f0fe518adc7e85e1c45fbcebbd735c6ab Log: Fix JENKINS-12364 > Cannot drill down to source code with cppcheck when build source is checked > out using SVN > - > > Key: JENKINS-12364 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12364 > Project: Jenkins > Issue Type: Bug > Components: cppcheck >Affects Versions: current > Environment: Linux >Reporter: Chris Welch >Assignee: gbois >Priority: Minor > > Using the lastest cppcheck (v1.1). cppcheck is unable to produce linkable > references to the source code when Subversion is used to check out the code. > If you have a project that uses SVN, by default it is checked out into a sub > directory under the Jenkins workspace named as the last part of the > Subversion URL. This is document in Jenkins in the "If left empty" portion > of the optional module local directory: > "Specify a local directory (relative to the workspace root) where this module > is checked out. If left empty, the last path component of the URL is used as > the default, just like the svn CLI. A single period (.) may be used to check > out the project directly into the workspace rather than into a subdirectory." > So we have a project with a Subversion URL: > svn+ssh://svnhost/svnrep/branches/myproj_P2_0_0_cppcheck/myproj > As a result, our Jenkins workspace becomes: > /build/workspace/myproj_P2_0_0_cppcheck > and the source code is checked out in: > /build/workspace/myproj_P2_0_0_cppcheck/myproj > cppcheck is run from the Jenkins workspace: > /build/workspace/myproj_P2_0_0_cppcheck > and the cppcheck-results.xml file ends up in the Jenkins workspace: > /build/workspace/myproj_P2_0_0_cppcheck/cppcheck-results.xml > But, the cppcheck reporter is not using the Jenkins workspace as the root for > references in cppcheck-results.xml (/build/workspace/myproj_P2_0_0_cppcheck). > The cppcheck reporter is using the SVN check out location to generate the > report (/build/workspace/myproj_P2_0_0_cppcheck/myproj). > Here is an entry from the cppcheck-results.xml file: > id="s_tempStorageAssignment" line="34" msg="Implicitly only sto > rage pObj->pOutVar (type ST_ADC_POINT_T *) not released before assignment: > pObj->pOutVar = pOutObj A memory leak h > as been detected. Only-qualified storage is not released before the last > reference to it is lost. (Use -mustfreeonly to > inhibit warning)" severity="warning"/> > And the cppcheck plugin generates the following warning: > [Cppcheck] [WARNING] - The source file > 'file:/build/workspace/myproj_P2_0_0_cppcheck/myproj/myproj/ADI%20Sharc/Shared/EDFA/deviceClass.c' > doesn't exist on the slave. The ability to display its source code has been > removed. > Note the duplication of the myproj directory. The reporter is not using the > Jenkins workspace as the root directory. It is using the SVN check out > directory. The report generation should be built relative to the Jenkins > workspace, not to the SVN check out directory. > This should be easy to fix. The reporter should be using the present working > directory of the cppcheck-result.xml file as the path to prepend to the file > spec from the cppcheck-results.xml file. > For example, in this case, the reporter start up to examin the > cppcheck-results.xml file: > pwd > /build/workspace/myproj_P2_0_0_cppcheck > File in cppcheck-results.xml message: > file="/myproj/ADI Sharc/Shared/EDFA/deviceClass.c" > File path is: > pwd + cppcheck-results.xml file = > /build/workspace/myproj_P2_0_0_cppcheck/myproj/ADI > Sharc/Shared/EDFA/deviceClass.c -- 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-12364) Cannot drill down to source code with cppcheck when build source is checked out using SVN
[ https://issues.jenkins-ci.org/browse/JENKINS-12364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161872#comment-161872 ] SCM/JIRA link daemon commented on JENKINS-12364: Code changed in jenkins User: Gregory Boissinot Path: src/main/java/com/thalesgroup/hudson/plugins/cppcheck/CppcheckBuildAction.java src/main/java/org/jenkinsci/CppcheckSourceContainer.java src/main/java/org/jenkinsci/plugins/cppcheck/CppcheckPublisher.java src/main/java/org/jenkinsci/plugins/cppcheck/CppcheckResult.java src/main/java/org/jenkinsci/plugins/cppcheck/CppcheckSourceContainer.java http://jenkins-ci.org/commit/cppcheck-plugin/ba87566276c491cde5d621894e90dcca8f9fdb51 Log: Fix JENKINS-12364 > Cannot drill down to source code with cppcheck when build source is checked > out using SVN > - > > Key: JENKINS-12364 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12364 > Project: Jenkins > Issue Type: Bug > Components: cppcheck >Affects Versions: current > Environment: Linux >Reporter: Chris Welch >Assignee: gbois >Priority: Minor > > Using the lastest cppcheck (v1.1). cppcheck is unable to produce linkable > references to the source code when Subversion is used to check out the code. > If you have a project that uses SVN, by default it is checked out into a sub > directory under the Jenkins workspace named as the last part of the > Subversion URL. This is document in Jenkins in the "If left empty" portion > of the optional module local directory: > "Specify a local directory (relative to the workspace root) where this module > is checked out. If left empty, the last path component of the URL is used as > the default, just like the svn CLI. A single period (.) may be used to check > out the project directly into the workspace rather than into a subdirectory." > So we have a project with a Subversion URL: > svn+ssh://svnhost/svnrep/branches/myproj_P2_0_0_cppcheck/myproj > As a result, our Jenkins workspace becomes: > /build/workspace/myproj_P2_0_0_cppcheck > and the source code is checked out in: > /build/workspace/myproj_P2_0_0_cppcheck/myproj > cppcheck is run from the Jenkins workspace: > /build/workspace/myproj_P2_0_0_cppcheck > and the cppcheck-results.xml file ends up in the Jenkins workspace: > /build/workspace/myproj_P2_0_0_cppcheck/cppcheck-results.xml > But, the cppcheck reporter is not using the Jenkins workspace as the root for > references in cppcheck-results.xml (/build/workspace/myproj_P2_0_0_cppcheck). > The cppcheck reporter is using the SVN check out location to generate the > report (/build/workspace/myproj_P2_0_0_cppcheck/myproj). > Here is an entry from the cppcheck-results.xml file: > id="s_tempStorageAssignment" line="34" msg="Implicitly only sto > rage pObj->pOutVar (type ST_ADC_POINT_T *) not released before assignment: > pObj->pOutVar = pOutObj A memory leak h > as been detected. Only-qualified storage is not released before the last > reference to it is lost. (Use -mustfreeonly to > inhibit warning)" severity="warning"/> > And the cppcheck plugin generates the following warning: > [Cppcheck] [WARNING] - The source file > 'file:/build/workspace/myproj_P2_0_0_cppcheck/myproj/myproj/ADI%20Sharc/Shared/EDFA/deviceClass.c' > doesn't exist on the slave. The ability to display its source code has been > removed. > Note the duplication of the myproj directory. The reporter is not using the > Jenkins workspace as the root directory. It is using the SVN check out > directory. The report generation should be built relative to the Jenkins > workspace, not to the SVN check out directory. > This should be easy to fix. The reporter should be using the present working > directory of the cppcheck-result.xml file as the path to prepend to the file > spec from the cppcheck-results.xml file. > For example, in this case, the reporter start up to examin the > cppcheck-results.xml file: > pwd > /build/workspace/myproj_P2_0_0_cppcheck > File in cppcheck-results.xml message: > file="/myproj/ADI Sharc/Shared/EDFA/deviceClass.c" > File path is: > pwd + cppcheck-results.xml file = > /build/workspace/myproj_P2_0_0_cppcheck/myproj/ADI > Sharc/Shared/EDFA/deviceClass.c -- 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-12364) Cannot drill down to source code with cppcheck when build source is checked out using SVN
[ https://issues.jenkins-ci.org/browse/JENKINS-12364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] gbois resolved JENKINS-12364. - Resolution: Fixed > Cannot drill down to source code with cppcheck when build source is checked > out using SVN > - > > Key: JENKINS-12364 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12364 > Project: Jenkins > Issue Type: Bug > Components: cppcheck >Affects Versions: current > Environment: Linux >Reporter: Chris Welch >Assignee: gbois >Priority: Minor > > Using the lastest cppcheck (v1.1). cppcheck is unable to produce linkable > references to the source code when Subversion is used to check out the code. > If you have a project that uses SVN, by default it is checked out into a sub > directory under the Jenkins workspace named as the last part of the > Subversion URL. This is document in Jenkins in the "If left empty" portion > of the optional module local directory: > "Specify a local directory (relative to the workspace root) where this module > is checked out. If left empty, the last path component of the URL is used as > the default, just like the svn CLI. A single period (.) may be used to check > out the project directly into the workspace rather than into a subdirectory." > So we have a project with a Subversion URL: > svn+ssh://svnhost/svnrep/branches/myproj_P2_0_0_cppcheck/myproj > As a result, our Jenkins workspace becomes: > /build/workspace/myproj_P2_0_0_cppcheck > and the source code is checked out in: > /build/workspace/myproj_P2_0_0_cppcheck/myproj > cppcheck is run from the Jenkins workspace: > /build/workspace/myproj_P2_0_0_cppcheck > and the cppcheck-results.xml file ends up in the Jenkins workspace: > /build/workspace/myproj_P2_0_0_cppcheck/cppcheck-results.xml > But, the cppcheck reporter is not using the Jenkins workspace as the root for > references in cppcheck-results.xml (/build/workspace/myproj_P2_0_0_cppcheck). > The cppcheck reporter is using the SVN check out location to generate the > report (/build/workspace/myproj_P2_0_0_cppcheck/myproj). > Here is an entry from the cppcheck-results.xml file: > id="s_tempStorageAssignment" line="34" msg="Implicitly only sto > rage pObj->pOutVar (type ST_ADC_POINT_T *) not released before assignment: > pObj->pOutVar = pOutObj A memory leak h > as been detected. Only-qualified storage is not released before the last > reference to it is lost. (Use -mustfreeonly to > inhibit warning)" severity="warning"/> > And the cppcheck plugin generates the following warning: > [Cppcheck] [WARNING] - The source file > 'file:/build/workspace/myproj_P2_0_0_cppcheck/myproj/myproj/ADI%20Sharc/Shared/EDFA/deviceClass.c' > doesn't exist on the slave. The ability to display its source code has been > removed. > Note the duplication of the myproj directory. The reporter is not using the > Jenkins workspace as the root directory. It is using the SVN check out > directory. The report generation should be built relative to the Jenkins > workspace, not to the SVN check out directory. > This should be easy to fix. The reporter should be using the present working > directory of the cppcheck-result.xml file as the path to prepend to the file > spec from the cppcheck-results.xml file. > For example, in this case, the reporter start up to examin the > cppcheck-results.xml file: > pwd > /build/workspace/myproj_P2_0_0_cppcheck > File in cppcheck-results.xml message: > file="/myproj/ADI Sharc/Shared/EDFA/deviceClass.c" > File path is: > pwd + cppcheck-results.xml file = > /build/workspace/myproj_P2_0_0_cppcheck/myproj/ADI > Sharc/Shared/EDFA/deviceClass.c -- 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-13466) Custom environment variables not available when build started by an SCM change
[
https://issues.jenkins-ci.org/browse/JENKINS-13466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161873#comment-161873
]
gbois commented on JENKINS-13466:
-
Additionally, if you just install the envinject-plugin and active it, it has to
work.
> Custom environment variables not available when build started by an SCM change
> --
>
> Key: JENKINS-13466
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13466
> Project: Jenkins
> Issue Type: Bug
> Components: core, envinject
> Environment: not applicable
>Reporter: Robin Jarry
>Assignee: gbois
> Attachments: custom-env-master.jpg, custom-env-slave.jpg
>
>
> Hi there,
> I may have found a sneaky bug. Custom environment variables can be defined by
> the user into the general & nodes config:
> !custom-env-master.jpg!
> !custom-env-slave.jpg!
> When a build is triggered by an SCM change, those variables are not available
> for SCM plugins.
> Let's say that I have a field in my SCM plugin configured with this value:
> *$\{JOB_NAME\}\_$\{HOSTNAME}\_$\{NODE_TYPE\}* If the build is triggered by an
> SCM change I get this error:
> {code}
> Started by an SCM change
> Building remotely on vmo426
> [ClearCase] ### Begin source code retrieval ###
> cleartool error: Illegal characters found in view name : ${NODE_TYPE}. An
> environment variable may have not been resolved.
> Finished: FAILURE
> {code}
> Here is the code snipet from my plugin that does that:
> {code:Java}
> @Override
> public boolean checkout(AbstractBuild build, Launcher launcher, FilePath
> workspace,
> BuildListener listener, File changelogFile) throws IOException,
> InterruptedException
> {
> try {
> logger.log("### Begin source code retrieval ###");
> String resolvedViewName =
> build.getEnvironment(listener).expand(this.viewName);
>
> Pattern pattern = Pattern.compile("(\\$\\{.+?\\})");
> Matcher matcher = pattern.matcher(resolvedViewName);
> if (matcher.find()) {
> String message = "Illegal characters found in view name : %s. " +
> "An environment variable may have not been resolved.";
> throw new ClearToolError(String.format(message, matcher.group()));
> }
> {code}
> I removed *$\{NODE_TYPE\}* from my SCM configuration to let the build
> continue. And the user custom environment variables seem to be injected into
> the build environment after the SCM checkout.
> {code}
> Started by an SCM change
> Building remotely on vmo426
> [ClearCase] ### Begin source code retrieval ###
> ...
> [ClearCase] === End source code retrieval ===
> [polling_linux] $ /bin/sh -xe /tmp/hudson7589128551511062241.sh
> + env
> ...
> NODE_TYPE=SLAVE
> ...
> {code}
> Could this be fixed? :)
--
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
