[JIRA] (JENKINS-16003) Override default values for parameters
Orgad Shaneh created JENKINS-16003 Override default values for parameters Issue Type: Improvement Affects Versions: current Assignee: Unassigned Components: parameters Created: 02/Dec/12 1:34 PM Description: It would be very useful if default values for parameterized build could be overridden using querystring or post request (like /BuildWithParameters) This is useful when some of the parameters are already known when executing the build, but some are left for the users to choose. /BuildWithParameters does not allow any interaction. Project: Jenkins Priority: Major Reporter: Orgad Shaneh This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16004) Clone parameterized build
Orgad Shaneh created JENKINS-16004 Clone parameterized build Issue Type: Improvement Assignee: Unassigned Components: parameters Created: 02/Dec/12 1:42 PM Description: It would be useful to clone a previous parameterized build (i.e. start a new build with same values for the parameters), allowing to change values before actually building. Project: Jenkins Priority: Major Reporter: Orgad Shaneh This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15976) Provided maven settings.xml in maven builder is lost
domi commented on JENKINS-15976 Provided maven settings.xml in maven builder is lost Since version 2.3 of the config-file-provider requires core 1.491 and the field "settingsConfigId" is deprecated and internally not used anymore. It only is read during startup to do the migration form the old to the new format. Instead of the old 'settingsConfigId' you should see a a new tag "settings" and/or "globalSettings" which will contain the same id as in the original one. The new tags will by stored in the config.xml when a the job gets saved the first time again (this is the same time when the old field gets removed from within the config.xml). If the job does not get resaved by a user, then the same information is used, but only in memory. So during startup a migration from the old format to the new format is done in memory and if a user opens the configuration screen of the job, then he sees the memory representation of the job and therefore the new config is visible for him. If he presses save, then the new model is saved and the old "settignsConfigId" is removed. From your description I'm not able to tell whether your configuration is broken or if you just don't like the location of the settings.xml configuration in the UI. Does your job still work or not? Did you reference a settings.xml provided by the config-file-provider plugin or did you define an explicit settings.xml in the old (removed) text field? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15782) InstantiationError when saving view configuration
domi updated JENKINS-15782 InstantiationError when saving view configuration Change By: domi (02/Dec/12 5:39 PM) Component/s: config-file-provider This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15782) InstantiationError when saving view configuration
domi commented on JENKINS-15782 InstantiationError when saving view configuration removing component config-file-provider, don't see anything pointing to it... This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15197) Add support for Maven toolchains configuration file
domi resolved JENKINS-15197 as Fixed Add support for Maven toolchains configuration file integrated in version 2.3 Change By: domi (02/Dec/12 5:43 PM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15979) "forgets" builds, workspace of renamed job
abayer resolved JENKINS-15979 as Duplicate "forgets" builds, workspace of renamed job Change By: abayer (02/Dec/12 6:00 PM) Status: Open Resolved Resolution: Duplicate This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15799) loosing matrix sub builds
abayer commented on JENKINS-15799 loosing matrix sub builds Confirmed that 1.484 brings back the builds, but 1.485 does not. There's nothing in the jenkins log to explain this - no exception, etc. I've seen this happen with matrix builds running on dynamic slaves and permanent slaves, with the same results. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15976) Provided maven settings.xml in maven builder is lost
Markus Hoofe
commented on JENKINS-15976
Provided maven settings.xml in maven builder is lost
I forgot to mention that i am using the "freestyle" project's maven builder. Apart from that i am using a newly installed jenkins with the newest version (1.492). So all i did was:
Installing "Jenkins" (1.492)
Installing "Config File Provider Plugin" (2.3)
Creating a "Maven settings.xml" configuration ("MySettings")
Creating a new "Freestyle Software Project" ("Test")
Adding a "Invoke top-level Maven targets" build step
Clicking the "Advanced..." button to reveal more settings
Selecting "provided settings.xml" file in "Settings file"
Selecting the former created "MySettings" configuration in "Provided Settings"
Running this job worked and i know the maven builder used the provided settings.xml, because it would not have worked otherwise (i added a server configuration for the deployment of artifacts). But as soon as i reopened the project configuration and clicked on "Save", the provided settings were lost! Thus the job failed due to the missing configuration AND i found out that any reference to the "MySettings" configuration was removed from "config.xml". The "settingsConfigId" element was still there, but it was empty!
This is a snippet of config.xml when i created the job and everything was fine:
clean install
maven-3.0.4
false
"org.jenkinsci.plugins.configfiles.maven.job.MvnSettingsProvider" plugin="config-file-provider@2.3">
org.jenkinsci.plugins.configfiles.maven.MavenSettingsConfig1354471384133
"jenkins.mvn.DefaultGlobalSettingsProvider"/>
And this happened AFTER i reopened it and saved it again (i did not change anything by the way, just clicked on "Save"):
clean install
maven-3.0.4
false
"org.jenkinsci.plugins.configfiles.maven.job.MvnSettingsProvider" plugin="config-file-provider@2.3">
"jenkins.mvn.DefaultGlobalSettingsProvider"/>
I also created a "Maven 2/3 Project" - which i cannot use in my context by the way - and here the same settings were NOT lost after reopening and saving! So it might have something to do with the freestyle software project.
I hope i cleared things up a bit and did not do something stupid, as i am new to jenkins. And thank you for fast response!
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11278) Can't set source code browser in the project config (http 403)
evernat edited a comment on JENKINS-11278 Can't set source code browser in the project config (http 403) duplicate of JENKINS-8710: "no proxy hosts" is now supported in the proxy configuration, since Jenkins 1.443 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11278) Can't set source code browser in the project config (http 403)
evernat resolved JENKINS-11278 as Duplicate Can't set source code browser in the project config (http 403) duplicates of JENKINS-8710: "no proxy hosts" is now supported in the proxy configuration, since Jenkins 1.443 Change By: evernat (02/Dec/12 7:34 PM) Status: Open Resolved Resolution: Duplicate This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-7056) On test specific page attachments should be filtered by the test name
Christopher Orr closed JENKINS-7056 as Fixed On test specific page attachments should be filtered by the test name Version 1.3 of the plugin has been released, which includes this fix. Change By: Christopher Orr (02/Dec/12 8:42 PM) Status: Open Closed Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13115) Same attachment can appear multiple times on "Test Result" page
Christopher Orr closed JENKINS-13115 as Fixed Same attachment can appear multiple times on "Test Result" page Version 1.3 of the plugin has been released, which includes this fix. Change By: Christopher Orr (02/Dec/12 8:42 PM) Status: Open Closed Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12123) Emma - Coverage results = 0 causes error in the reports
Steve Roth edited a comment on JENKINS-12123 Emma - Coverage results = 0 causes error in the reports I would bump up the priority on this, since rendering a view is extremely slow when these NPE are occurring. If I remove the emma column from the view config, then it renders almost instantaneously. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12123) Emma - Coverage results = 0 causes error in the reports
Steve Roth commented on JENKINS-12123 Emma - Coverage results = 0 causes error in the reports I would bump up the priority on this, since rendering a view is extremely slow when these NPE are occurring. I remove the emma column from the view config, then it renders almost instantaneously. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12123) Emma - Coverage results = 0 causes error in the reports
Steve Roth commented on JENKINS-12123 Emma - Coverage results = 0 causes error in the reports I am seeing this as well – logfile shows: Dec 2, 2012 2:13:58 PM hudson.ExpressionFactory2$JexlExpression evaluate WARNING: Caught exception evaluating: it.getPercent(job). Reason: java.lang.NullPointerException java.lang.NullPointerException at jenkins.plugins.emmacoveragecolumn.EmmaColumn.getPercentageFloat(EmmaColumn.java:82) at jenkins.plugins.emmacoveragecolumn.EmmaColumn.getLinePercent(EmmaColumn.java:66) at jenkins.plugins.emmacoveragecolumn.EmmaColumn.getPercent(EmmaColumn.java:37) 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.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:258) at org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:104) at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83) at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57) at org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51) at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) at hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:72) at org.apache.commons.jelly.tags.core.CoreTagLibrary$3.run(CoreTagLibrary.java:134) ... This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15940) WARNING: Caught exception evaluating: descriptor.getHelpFile(attrs.field). Reason: java.lang.NullPointerException
viral shah commented on JENKINS-15940 WARNING: Caught exception evaluating: descriptor.getHelpFile(attrs.field). Reason: java.lang.NullPointerException HI, This fix wasn't able to fix the issue for 15964. I think its a blocker issue . please try to have a look. Thanks Viral Shah This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15963) EnvInject properties not consistently used for SCM
Gregory Boissinot started work on JENKINS-15963 EnvInject properties not consistently used for SCM Change By: Gregory Boissinot (02/Dec/12 11:41 PM) Status: Open In Progress This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15963) EnvInject properties not consistently used for SCM
Gregory Boissinot commented on JENKINS-15963 EnvInject properties not consistently used for SCM Injected environment variables are only processed at build time. Therefore you can't use the future environment variables used to verify if the build has to be triggered. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13115) Same attachment can appear multiple times on "Test Result" page
Todd Mazierski commented on JENKINS-13115 Same attachment can appear multiple times on "Test Result" page Great, thanks Christopher! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-1295) switch for disabling/enabling downstream projects
dogfood commented on JENKINS-1295 switch for disabling/enabling downstream projects Integrated in jenkins_main_trunk #2118 JENKINS-1295 Disable trigger downstream for maven jobs (Revision c222acecaf0fe67d48711b9c298a85569b0a00fa) Result = UNSTABLE Vincent Latombe : c222acecaf0fe67d48711b9c298a85569b0a00fa Files : maven-plugin/src/main/resources/hudson/maven/MavenModuleSet/configure-entries.jelly maven-plugin/src/main/java/hudson/maven/MavenModuleSet.java maven-plugin/src/main/java/hudson/maven/MavenModule.java maven-plugin/src/main/resources/hudson/maven/MavenModuleSet/configure-entries_fr.properties changelog.html This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-8226) Add reviewers in gerrit when a build is successful
Andreas Borglin commented on JENKINS-8226 Add reviewers in gerrit when a build is successful Excellent! We were literally just about to start looking at this (yes, 4 months later ). Love the separate .owners file for different areas of the app. Brilliant. Any idea on when this will be merged into master and released? Thanks! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16005) Mercurial plugin assumes write access to installation directory
cowwoc commented on JENKINS-16005 Mercurial plugin assumes write access to installation directory I forgot to mention, my environment is Ubuntu 12.04, 64-bit edition. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16005) Mercurial plugin assumes write access to installation directory
cowwoc created JENKINS-16005 Mercurial plugin assumes write access to installation directory Issue Type: Bug Affects Versions: current Assignee: Jesse Glick Components: mercurial Created: 03/Dec/12 2:08 AM Description: The Mercurial incorrectly assumes write-access to the Mercurial installation directory, triggering the following exception: hudson.util.IOException2: Failed to create a temp file on /usr at hudson.FilePath.createTextTempFile(FilePath.java:1163) at hudson.FilePath.createTextTempFile(FilePath.java:1114) at hudson.tools.CommandInstaller.performInstallation(CommandInstaller.java:82) at hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:61) at hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107) at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:203) at hudson.plugins.mercurial.MercurialInstallation.forNode(MercurialInstallation.java:103) at hudson.plugins.mercurial.MercurialSCM.findHgExe(MercurialSCM.java:201) at hudson.plugins.mercurial.HgExe.(HgExe.java:80) at hudson.plugins.mercurial.MercurialSCM.clone(MercurialSCM.java:554) at hudson.plugins.mercurial.MercurialSCM.checkout(MercurialSCM.java:389) at hudson.model.AbstractProject.checkout(AbstractProject.java:1324) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:676) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:581) at hudson.model.Run.execute(Run.java:1518) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:477) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: hudson.util.IOException2: remote file operation failed: /usr at hudson.remoting.Channel@26528fa4:Ubuntu 12.04 at hudson.FilePath.act(FilePath.java:848) at hudson.FilePath.act(FilePath.java:825) at hudson.FilePath.createTextTempFile(FilePath.java:1141) ... 18 more My configuration is as follows: Installation directory = /usr Executable = INSTALLATION/bin/hg Installation Automatically using command: "sudo apt-get install mercurial" Jenkin's user does not have general access to /usr, nor to "sudo". It only has executable permissions in /usr/bin and "sudoers" permission to "apt-get". Expected behavior: write temporary files into the path specified by the "java.io.tmpdir" system property. Project: Jenkins Priority: Major Reporter: cowwoc This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16005) Mercurial plugin assumes write access to installation directory
cowwoc commented on JENKINS-16005 Mercurial plugin assumes write access to installation directory Workaround: Set "Installation directory" to Jenkins' home directory (which we have write access to) and "Tool Home" remains pointed to /usr. PS: What's the difference between "Installation directory" and "Tool Home"? There is no help tooltip for "Installation directory". This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15940) WARNING: Caught exception evaluating: descriptor.getHelpFile(attrs.field). Reason: java.lang.NullPointerException
sogabe commented on JENKINS-15940 WARNING: Caught exception evaluating: descriptor.getHelpFile(attrs.field). Reason: java.lang.NullPointerException It appears that there is no relation to JENKINS-15964. Perhaps one of the plugin you have installed causes problem. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16006) Re Deploy the previous artifact into weblogic servers
Anbarasan Nagalingam created JENKINS-16006 Re Deploy the previous artifact into weblogic servers Issue Type: Bug Assignee: ragesh_nair Components: rebuild Created: 03/Dec/12 4:01 AM Description: Dear Friends , I'm new to Continuous Integration,here i want to re build and redeploy the old artifact into my weblogic server with my old source code. I have tried pipeline plugin and build promotions plug in for my requirements. But i didn't get any solutions. Is there any possible to do this. If so, please do let me know. Thanks Anba Environment: Jenkins 1.485, Java 1.6, maven, Linux , weblogic servers and SVN Project: Jenkins Priority: Major Reporter: Anbarasan Nagalingam This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16007) Weblogic Deploy periodically not working
Anbarasan Nagalingam created JENKINS-16007 Weblogic Deploy periodically not working Issue Type: Bug Assignee: Unassigned Components: deploy Created: 03/Dec/12 5:53 AM Description: Dear Friends, I'm using Weblogic Deployer Plugin in my Jenkins for deploy artifact into Weblogic servers. I want to use deploy periodically for every one hour. What i did was that I just enabled check box Deploy periodically under Build Trigger and i gave */60 * * * * (cron syntax). And i have selected deploy peridically in Deployment policy under Deploy the artifact on a weblogic environment. But i got below error My Environment :: Java 1.6, Maven, Weblogic 10.3 SVN projectSucceeded smartquote:smartquote:1.0 sessionEnded [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 2:56.162s [INFO] Finished at: Mon Dec 03 04:09:44 UTC 2012 [INFO] Final Memory: 174M/339M [INFO] Projects to build: [MavenProject: smartquote:smartquote:1.0 @ /opt/sasuapps/smartquote/jenkins-install/.jenkins/jobs/Maven-sq/workspace/pom.xml] [JENKINS] Archiving /opt/sasuapps/smartquote/jenkins-install/.jenkins/jobs/Maven-sq/workspace/pom.xml to /opt/sasuapps/smartquote/jenkins-install/.jenkins/jobs/Maven-sq/modules/smartquote$smartquote/builds/2012-12-03_04-06-33/archive/smartquote/smartquote/1.0/smartquote-1.0.pom [JENKINS] Archiving /opt/sasuapps/smartquote/jenkins-install/.jenkins/jobs/Maven-sq/workspace/target/smartquote-1.0.war to /opt/sasuapps/smartquote/jenkins-install/.jenkins/jobs/Maven-sq/modules/smartquote$smartquote/builds/2012-12-03_04-06-33/archive/smartquote/smartquote/1.0/smartquote-1.0.war Waiting for Jenkins to finish collecting data channel stopped [WeblogicDeploymentPlugin] - Not properly build causes expected (configured=org.jenkinsci.plugins.deploy.weblogic.trigger.DeploymentTrigger) (currents=hudson.triggers.TimerTrigger$TimerTriggerCause@5) : The plugin execution is disabled. [INFO] [INFO] DEPLOYMENT DISABLED [INFO] Build step 'Deploy the artifact on a Weblogic environment' changed build result to FAILURE Skipping Cobertura coverage report as build was not UNSTABLE or better ... Finished: FAILURE So, Could please tell me how to use deploy periodically for maven projects. Thanks Aaba Project: Jenkins Priority: Major Reporter: Anbarasan Nagalingam This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16008) .Net based Builds are failing on Slave machine
valibaba shaik created JENKINS-16008 .Net based Builds are failing on Slave machine Issue Type: Bug Assignee: Kohsuke Kawaguchi Attachments: Mesa 4.0.txt, MESA Queue Time 0002.00.txt, Probe Part lock.txt Components: build-timeout, subversion Created: 03/Dec/12 6:17 AM Description: Please help me to resolve this issues. I have attached log files for your reference. These builds are failing with similar set of error messages. Due Date: 07/Dec/12 12:00 AM Environment: Master is hosted on Linux OS, Slave machine is running on Winodws7. Fix Versions: current Project: Jenkins Priority: Major Reporter: valibaba shaik This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16009) Unable to launch cocoa application through post build script
Sharone Sequeira created JENKINS-16009 Unable to launch cocoa application through post build script Issue Type: Bug Assignee: Gregory Boissinot Attachments: configuration.png, exception.png, script.zip, testApp.zip Components: postbuildscript Created: 03/Dec/12 6:17 AM Description: I have a sample NSApplication to be launched through post build shell script. The shell script tries to open the application with the argument provided. But this fails to load the UI (nib file) and gives an error message "Terminating app due to uncaught exception NSInternalInconsistencyException, reason: Error (1002) creating CGSWindow". The screenshot of the exception and also the configuration is attached. I am also attaching the test app(testApp.zip) and the script file(script.zip) used. Environment: MAC OS X 10.6, Xcode 3.2.6, Project: Jenkins Labels: exception mac Priority: Blocker Reporter: Sharone Sequeira This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16010) Plugin consumes too much memory
Mickael Istria
created JENKINS-16010
Plugin consumes too much memory
Issue Type:
Bug
Affects Versions:
current
Assignee:
Ognjen Bubalo
Components:
jacoco
Created:
03/Dec/12 7:17 AM
Description:
Imported from GitHub: https://github.com/jenkinsci/jacoco-plugin/issues/12
Report by Greg Temchenko ("soid" on GitHub)
I broke down my Jenkins trying to use this plugin. It turned out that plugin stores the entire coverage in XML format in build.xml file in jenkins (Unknown macro: {Jenkins} /jobs/Unknown macro: {Project} /builds/Unknown macro: {Build} /build.xml). Boolean values about covered/uncovered lines stored there as XML tags with indentation for readability
true
Thus my 600K code coverage .exec bin file consumed more than 700M on the hard disk for the build.xml.
This is a half of the problem. Further Jenkins keeps all builds information including mentioned above build.xml in RAM. That's how I've caught OutOfMemory exceptions in Jenkins and got it broken.
And a comment from Jesse Glick ("jglick")
For what it’s worth Kohsuke & I recently did some minor memory usage fixes in the Cobertura plugin, and I experimented with more: https://github.com/jenkinsci/cobertura-plugin/compare/master...trove
This issue makes the plugin forbidden to installation on JBoss Jenkins instance.
Project:
Jenkins
Priority:
Critical
Reporter:
Mickael Istria
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16010) Plugin consumes too much memory
Mickael Istria
updated JENKINS-16010
Plugin consumes too much memory
Change By:
Mickael Istria
(03/Dec/12 7:18 AM)
Description:
Imported from GitHub: https://github.com/jenkinsci/jacoco-plugin/issues/12Report by Greg Temchenko ("soid" on GitHub){quote}I broke down my Jenkins trying to use this plugin. It turned out that plugin stores the entire coverage in XML format in build.xml file in jenkins (
{Jenkins}
JENKINS_HOME
/jobs/
{
[
Project
}
]
/builds/
{
[
Build
}
]
/build.xml). Boolean values about covered/uncovered lines stored there as XML tags with indentation for readability :)trueThus my 600K code coverage .exec bin file consumed more than 700M on the hard disk for the build.xml.This is a half of the problem. Further Jenkins keeps all builds information including mentioned above build.xml in RAM. That's how I've caught OutOfMemory exceptions in Jenkins and got it broken.{quote}And a comment from Jesse Glick ("jglick"){quote}For what it’s worth Kohsuke & I recently did some minor memory usage fixes in the Cobertura plugin, and I experimented with more: https://github.com/jenkinsci/cobertura-plugin/compare/master...trove{quote}This issue makes the plugin forbidden to installation on JBoss Jenkins instance.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16008) .Net based Builds are failing on Slave machine
valibaba shaik assigned JENKINS-16008 to Unassigned .Net based Builds are failing on Slave machine Change By: valibaba shaik (03/Dec/12 7:32 AM) Assignee: valibaba shaik This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-16008) .Net based Builds are failing on Slave machine
valibaba shaik assigned JENKINS-16008 to valibaba shaik .Net based Builds are failing on Slave machine Change By: valibaba shaik (03/Dec/12 7:32 AM) Assignee: Kohsuke Kawaguchi valibaba shaik This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15702) InstantiationError: hudson.scm.AbstractCvs
Suresh Nelamangala commented on JENKINS-15702 InstantiationError: hudson.scm.AbstractCvs Dec 3, 2012 2:28:18 AM jenkins.InitReactorRunner$1 onAttained INFO: Started all plugins Dec 3, 2012 2:28:18 AM jenkins.InitReactorRunner$1 onAttained INFO: Augmented all extensions Dec 3, 2012 2:28:20 AM hudson.util.RobustReflectionConverter doUnmarshal WARNING: Failed to resolve a type java.lang.InstantiationError: hudson.scm.AbstractCvs at sun.reflect.GeneratedSerializationConstructorAccessor170.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Constructor.java:532) at com.thoughtworks.xstream.converters.reflection.Sun14ReflectionProvider.newInstance(Sun14ReflectionProvider.java:76) at hudson.util.RobustReflectionConverter.instantiateNewInstance(RobustReflectionConverter.java:335) at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:180) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76) at hudson.util.RobustReflectionConverter.unmarshalField(RobustReflectionConverter.java:292) at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:234) at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:181) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60) at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:71) at hudson.util.RobustCollectionConverter.populateCollection(RobustCollectionConverter.java:85) at com.thoughtworks.xstream.converters.collections.CollectionConverter.unmarshal(CollectionConverter.java:61) at hudson.util.RobustCollectionConverter.unmarshal(RobustCollectionConverter.java:76) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76) I have also been facing this error for some time now ... This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
