[JIRA] (JENKINS-16407) Android Emulator plugin does not compile with Java 7
Matti Linnanvuori created JENKINS-16407 Android Emulator plugin does not compile with Java 7 Issue Type: Bug Affects Versions: current Assignee: Christopher Orr Components: android-emulator Created: 18/Jan/13 7:33 AM Description: matti@matti:~/projects/android-emulator-plugin$ mvn compile [INFO] Scanning for projects... [WARNING] [WARNING] Some problems were encountered while building the effective model for org.jvnet.hudson.plugins:android-emulator:hpi:2.8-SNAPSHOT [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ org.jvnet.hudson:hudson:1.7, /home/matti/.m2/repository/org/jvnet/hudson/hudson/1.7/hudson-1.7.pom, line 60, column 15 [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-plugin is missing. @ org.jvnet.hudson.plugins:plugin:1.377, /home/matti/.m2/repository/org/jvnet/hudson/plugins/plugin/1.377/plugin-1.377.pom, line 190, column 15 [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-enforcer-plugin is missing. @ org.jvnet.hudson:hudson:1.7, /home/matti/.m2/repository/org/jvnet/hudson/hudson/1.7/hudson-1.7.pom, line 48, column 15 [WARNING] 'distributionManagement.snapshotRepository.id' must not be 'local', this identifier is reserved for the local repository, using it for other repositories will corrupt your repository metadata. @ org.jvnet.hudson:hudson:1.7, /home/matti/.m2/repository/org/jvnet/hudson/hudson/1.7/hudson-1.7.pom, line 31, column 11 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. [WARNING] [INFO] [INFO] [INFO] Building Android Emulator Plugin 2.8-SNAPSHOT [INFO] Downloading: http://repo.jenkins-ci.org/public/org/apache/maven/plugins/maven-enforcer-plugin/maven-metadata.xml Downloaded: http://repo.jenkins-ci.org/public/org/apache/maven/plugins/maven-enforcer-plugin/maven-metadata.xml (590 B at 0.5 KB/sec) Downloading: http://repo.jenkins-ci.org/public/org/apache/maven/plugins/maven-compiler-plugin/maven-metadata.xml Downloaded: http://repo.jenkins-ci.org/public/org/apache/maven/plugins/maven-compiler-plugin/maven-metadata.xml (760 B at 2.4 KB/sec) Downloading: http://repo.jenkins-ci.org/public/org/apache/maven/plugins/maven-surefire-plugin/maven-metadata.xml Downloaded: http://repo.jenkins-ci.org/public/org/apache/maven/plugins/maven-surefire-plugin/maven-metadata.xml (2 KB at 3.7 KB/sec) Downloading: http://repo.jenkins-ci.org/public/org/apache/maven/plugins/maven-install-plugin/maven-metadata.xml Downloaded: http://repo.jenkins-ci.org/public/org/apache/maven/plugins/maven-install-plugin/maven-metadata.xml (503 B at 1.6 KB/sec) Downloading: http://repo.jenkins-ci.org/public/org/apache/maven/plugins/maven-resources-plugin/maven-metadata.xml Downloaded: http://repo.jenkins-ci.org/public/org/apache/maven/plugins/maven-resources-plugin/maven-metadata.xml (686 B at 2.2 KB/sec) Downloading: http://repo.jenkins-ci.org/public/org/kohsuke/access-modifier-checker/maven-metadata.xml Downloaded: http://repo.jenkins-ci.org/public/org/kohsuke/access-modifier-checker/maven-metadata.xml (389 B at 1.2 KB/sec) Downloading: http://repo.jenkins-ci.org/public/org/apache/maven/plugins/maven-deploy-plugin/maven-metadata.xml Downloaded: http://repo.jenkins-ci.org/public/org/apache/maven/plugins/maven-deploy-plugin/maven-metadata.xml (614 B at 2.0 KB/sec) Downloading: http://repo.jenkins-ci.org/public/org/kohsuke/stapler/stapler/maven-metadata.xml Downloading: http://repo.maven.apache.org/maven2/org/kohsuke/stapler/stapler/maven-metadata.xml Downloaded: http://repo.maven.apache.org/maven2/org/kohsuke/stapler/stapler/maven-metadata.xml (333 B at 2.6
[JIRA] (JENKINS-16391) Allow publication even if build failed
Francois Molinier commented on JENKINS-16391 Allow publication even if build failed Great news! Thanks a lot. 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-16374) BuildStepMonitor.STEP makes concurrent builds wait, could be changed to BuildStepMonitor.NONE
Nalin Makar commented on JENKINS-16374 BuildStepMonitor.STEP makes concurrent builds wait, could be changed to BuildStepMonitor.NONE I'll look into this soon. Right now I am busy fixing a bunch of other issues. 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-16406) Environment variables
ping he created JENKINS-16406 Environment variables Issue Type: New Feature Affects Versions: current Assignee: Gregory Boissinot Components: artifactdeployer Created: 18/Jan/13 6:37 AM Description: entry defines of Basedir and Remote directory the permitted use environment variables, defined in the node Project: Jenkins Priority: Major Reporter: ping he 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-16381) Disable button should be an overlay of the build button not a separate button.
Matthew Kruer commented on JENKINS-16381 Disable button should be an overlay of the build button not a separate button. I got it, and its simple, use the GTK icon set, grab the grey pause icon for disabled, and the grey play icon for running. Pause and Play make more sense and are universally known. 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-16405) suppert basedir, The basedir configuration is similar to the ArtifactDeployer plug-in provides
ping he created JENKINS-16405 suppert basedir, The basedir configuration is similar to the ArtifactDeployer plug-in provides Issue Type: New Feature Affects Versions: current Assignee: Unassigned Components: copyartifact Created: 18/Jan/13 12:41 AM Project: Jenkins Priority: Major Reporter: ping he 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-16404) email-ext regression trigger not firing when it should
lcgerke gerke created JENKINS-16404 email-ext regression trigger not firing when it should Issue Type: Bug Assignee: Slide-O-Mix Attachments: ScreenShot011.png, ScreenShot012.png, ScreenShot013.png Components: email-ext Created: 17/Jan/13 11:49 PM Description: I apologize in advance, because I can't imagine this isn't my problem. I have a simple project, the builds triggered successfully by a subversion callback. When an additional JUnit test fails, the "regression" trigger isn't fired. I attach screenshots of my email-ext config, the build info screen showing that the number of fails is "+1", and a screenshot of the console output from the build, showing that there was a fail, but "No emails were triggered." i'm sure i'm missing something very simple, but i've been staring at this for a while. i'd appreciate any help. thanks! Environment: linux jenkins 1.480.2 email-ext 2.25 Project: Jenkins Labels: email-ext Priority: Major Reporter: lcgerke gerke 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-12330) Occasionally,collecting findbugs analysis files will take very long time, event two more hours.
michael pechner reopened JENKINS-12330 Occasionally,collecting findbugs analysis files will take very long time, event two more hours. Happening to me on 1.480.2 Rackspace centos 5.8 machine. 4GB ram machine. Latest jetty. https Build working perfectly, but find bugs is stuck. java 1.6 ant 1.8 Change By: michael pechner (17/Jan/13 11:17 PM) Resolution: Cannot Reproduce Status: Resolved Reopened 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-16399) SCM documentation is incorrect
Gregory Boissinot resolved JENKINS-16399 as Fixed SCM documentation is incorrect Change By: Gregory Boissinot (17/Jan/13 10:26 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-16403) Web Services API v3
Kyle O'Connor created JENKINS-16403 Web Services API v3 Issue Type: Bug Affects Versions: current Assignee: Josh Vinson Components: coverity Created: 17/Jan/13 10:25 PM Description: I noticed the following in the the Coverity 6.5.1 Release Notes Important Coverity Connect information for 6.5.1: 47055 The Web Services API version v3 is depreciated in this release. This version will no longer be supported in the next release scheduled for the Spring 2013. I believe this plugin uses the v3 webservices. Will you be updating that before Spring 2013? Environment: Coverity Plugin 1.1.4 Coverity Version 6.5.1 Project: Jenkins Priority: Major Reporter: Kyle O'Connor 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-16399) SCM documentation is incorrect
SCM/JIRA link daemon commented on JENKINS-16399 SCM documentation is incorrect Code changed in jenkins User: Gregory Boissinot Path: src/main/resources/org/jenkinsci/plugins/envinject/EnvInjectBuildWrapper/help-scriptFilePath.html http://jenkins-ci.org/commit/envinject-plugin/15cfad15a1e66073a05aeab1b6f0c3e111791cc2 Log: Fix JENKINS-16399 Compare: https://github.com/jenkinsci/envinject-plugin/compare/95428b2fb1a7...15cfad15a1e6 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-16273) Slaves forbidden to request JNLP anonymously but no clear way to pass API token
Jesper Jensen edited a comment on JENKINS-16273 Slaves forbidden to request JNLP anonymously but no clear way to pass API token Based up @Trevor and @Richard instructions here is how I got the windows slaves to run as a service again: 1 - Stop service 2 - Uninstall the service if it exists dos (sc delete jenkinsslave-C__Jenkins) 3 - Delete the old jenkins-slave.exe, slave.jar and jenkins-slave.xml 4 - Start the web client and let it install the service 5 - Edit the jenkins-slave.xml so the it looks like this the important part is the jnlpCredentials -Xrs -jar "%BASE%\slave.jar" -jnlpCredentials : -jnlpUrl http:///computer//slave-agent.jnlp 6 - Stop your web client if it not already and restart your service. Mine are now running. Note it is very important that you delete your old slave.jar and get the new one via the web install. This works with version 1.499 To the developer please make a note that slave.jar needs to be updated on the slave when you make a new revision! 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-16273) Slaves forbidden to request JNLP anonymously but no clear way to pass API token
Jesper Jensen edited a comment on JENKINS-16273 Slaves forbidden to request JNLP anonymously but no clear way to pass API token Based up @Trevor and @Richard instructions here is how I got the windows slaves to run as a service again: 1 - Stop service 2 - Uninstall the service if it exists dos (sc delete jenkinsslave-C__Jenkins) 3 - Delete the old jenkins-slave.exe, slave.jar and jenkins-slave.xml 4 - Start the web client and let it install the service 5 - Edit the jenkins-slave.xml so the it looks like this the important part is the jnlpCredentials -Xrs -jar "%BASE%\slave.jar" -jnlpCredentials : -jnlpUrl http:///computer//slave-agent.jnlp 6 - Stop your web client if it not already and restart your service. Mine are now running. 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-16273) Slaves forbidden to request JNLP anonymously but no clear way to pass API token
alexlombardi commented on JENKINS-16273 Slaves forbidden to request JNLP anonymously but no clear way to pass API token @Pei-Tang Huang My serice name is JenkinsSlave1. I have used the IP address of the server it is running on as you suggest but that fails with this message: ERROR: Message not found for errorCode: 0x1031 org.jinterop.dcom.common.JIException: Message not found for errorCode: 0x1031 at org.jinterop.winreg.smb.JIWinRegStub.winreg_OpenHKCR(JIWinRegStub.java:123) at org.jinterop.dcom.core.JIComServer.initialise(JIComServer.java:479) at org.jinterop.dcom.core.JIComServer.(JIComServer.java:427) at org.jvnet.hudson.wmi.WMI.connect(WMI.java:59) at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:218) at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:204) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.net.MalformedURLException: For input string: "xuy56qrH@10.41.98.169" at java.net.URL.(Unknown Source) at jcifs.smb.SmbFile.(SmbFile.java:444) at jcifs.smb.SmbNamedPipe.(SmbNamedPipe.java:134) at rpc.ncacn_np.RpcTransport.attach(RpcTransport.java:89) at rpc.Stub.attach(Stub.java:104) at rpc.Stub.call(Stub.java:109) at org.jinterop.winreg.smb.JIWinRegStub.winreg_OpenHKCR(JIWinRegStub.java:119) ... 10 more 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-16284) Failing to launch SSH slave agents after upgrade to 1.498
Jesse Glick updated JENKINS-16284 Failing to launch SSH slave agents after upgrade to 1.498 Change By: Jesse Glick (17/Jan/13 9:19 PM) Description: After upgrading to 1.498 and running the rekey process seemingly successfully, I get errors when trying to launch SSH Linux slaves. "This node is offline because Jenkins failed to launch the slave agent on it. See log for more details". Clicking on the "see log for more details" link just gives an empty page with a spinning wheel.In my various attempts to find a workaround, I did the following, all to no avail. The problem persists.- Downgrade to 1.494- Delete and reconfigure slaves- Reboot both master and slave machines several timesI also have a windows slave and experienced the issue described here [ in JENKINS-16273 |https://issues.jenkins-ci.org/browse/JENKINS-16273] , but I was able to resolve it by deleting and reconfiguring that particular slave. 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-16284) Failing to launch SSH slave agents after upgrade to 1.498
Jesse Glick updated JENKINS-16284 Failing to launch SSH slave agents after upgrade to 1.498 Change By: Jesse Glick (17/Jan/13 9:18 PM) Component/s: ruby-runtime 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-16284) Failing to launch SSH slave agents after upgrade to 1.498
Eric Wallengren commented on JENKINS-16284 Failing to launch SSH slave agents after upgrade to 1.498 I was able to get launching working again by removing the ruby-runtime plugin. Looks like someone will need to examine interoperability between ruby-runtime and ssh-slaves. 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-16342) asynchPeople very slow when using Gravatar & Subversion plugins
kutzi commented on JENKINS-16342 asynchPeople very slow when using Gravatar & Subversion plugins > SubversionMailAddressResolverImpl should probably be rewritten to perform its calculations in a long-running process and cache them. Or maybe this should just be deleted and the problem solved in a different way. Absolutely +1 for deleting this - as well as in all other SCM plugin where something analogue is implemented! These MailAddressResolvers are implemented in a so ridiculous inefficient way and their usefulness is IMHO very very limited. 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-16264) Posting config.xml to master node advertised to work
Jesse Glick commented on JENKINS-16264 Posting config.xml to master node advertised to work One other note: /computer/(master)/configure is meaningful, and distinct from /configure—you can configure number of executors, labels, and node properties for the master computer. But /computer/(master)/config.xml displays all of $JENKINS_HOME/config.xml which includes a lot of stuff unrelated to the use of master as a computer. 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-16394) Subversion polling broken
SCM/JIRA link daemon commented on JENKINS-16394 Subversion polling broken Code changed in jenkins User: Christoph Kutzinski Path: src/main/java/hudson/scm/CompareAgainstBaselineCallable.java src/main/java/hudson/scm/SVNLogFilter.java src/main/java/hudson/scm/SubversionSCM.java src/test/java/hudson/scm/CompareAgainstBaselineCallableTest.java http://jenkins-ci.org/commit/subversion-plugin/f55151b609bb2616955dadfcfa6d30270b05a82a Log: JENKINS-16394 refactored callable to compare the revisions into a named class and added regression test that it's serializable 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-15440) Emailing users at the end of a failed build very slow for big Jenkins instance using subversion
Jesse Glick commented on JENKINS-15440 Emailing users at the end of a failed build very slow for big Jenkins instance using subversion As mentioned in JENKINS-16342 I agree that this needs to be either rewritten or deleted outright. 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-16395) The path parameter in the REST API should support wildcard '*'.
Jesse Glick commented on JENKINS-16395 The path parameter in the REST API should support wildcard '*'. What path parameter? Do you mean tree? And is this not an RFE? 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-16393) "Unable to call join" build failures
Jesse Glick updated JENKINS-16393 "Unable to call join" build failures Change By: Jesse Glick (17/Jan/13 8:34 PM) Labels: remoting 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-14193) EnvInject doesn't pass variables defined in prebuild step if maven project is used
Markus Meisterernst
edited a comment on JENKINS-14193
EnvInject doesn't pass variables defined in prebuild step if maven project is used
Hi again,
as Jaime pointed out, the problem stems from the fact that a variable is to be resolved dynamically from outside to the environment.
In my case I wanted to set a variable from a call to git ("git describe" to get hold of the revision count from the latest label/tag).
I therefore executed a Shell script, redirected the output to a file and read in the Property file to inject the property to the Environment.
My intend was to pass it to a "parameterized" maven build like the following: clean install deploy -Drevision=${Revison}.
>From the build console output I can see that it doesn't resolve the variable ${Revision}. The Environment, however, has this Parameter perfectly resolved and set.
So, the workaround you suggested won't work in my case.
Currently we stick to the BUILD_NUMBER which is resolved magically enough (mvn clean install deploy -Drevision=${BUILD_NUMBER}).
Ok, it's a workaround, a nasty one as it is linear increasing with no real connection to git and versioning/branching stuff.
As I'm quite new to the Jenkins eco-system I ask myself, if it is best to write a plugin for my case ...
Or else (what would make much more sense) if you could give me guidance on where about to apply a fix so I could offer you some time to analyse and help out to improve the EnvInject plugin.
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-16402) HTML in Set Build Description no longer honored
alexlombardi created JENKINS-16402 HTML in Set Build Description no longer honored Issue Type: Bug Affects Versions: current Assignee: huybrechts Components: description-setter Created: 17/Jan/13 8:23 PM Description: HTML that was added as part of the build process to the build description, to allow users to click and link to extrnal information/tool with information specific to each successful build, is no longer honored, despite neither a change to the produced description output or the description setter plugin. Environment: Running Jenkins on 2K3 server using Master-Slave configuration. Master and all slaves are windows services. Project: Jenkins Priority: Major Reporter: alexlombardi 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-14193) EnvInject doesn't pass variables defined in prebuild step if maven project is used
Markus Meisterernst
edited a comment on JENKINS-14193
EnvInject doesn't pass variables defined in prebuild step if maven project is used
Hi again,
as Jaime pointed out, the problem stems from the fact that a variable is to be resolved dynamically from outside to the environment.
In my case I wanted to set a variable from a call to git ("git describe" to get hold of the revision count from the latest label/tag).
I therefore executed a Shell script, redirected the output to a file and read in the Property file to inject the property to the Environment.
My intend was to pass it to a "parameterized" maven build like the following: clean install deploy -Drevision=${Revison}.
>From the build console output I can see that it doesn't resolve the variable ${Revision}. The Environment, however, has this Parameter perfectly resolved and set.
So, the workaround you suggested won't work in my case.
Currently we stick to the BUILD_NUMBER which is resolved magically enough (mvn clean install deploy -Drevision=${BUILD_NUMBER}).
Ok, it's a workaround, a nasty one as it is linear increasing with no real connection to git and versioning/branching stuff.
As I'm quite new ot the Jenkins eco-system I ask myself, if it is best to write a plugin for my case ...
Or else (what would make much more sense) if you could give me guidance on where about to apply a fix so I could offer you some time to analyse and help out to improve the EnvInject plugin.
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-14193) EnvInject doesn't pass variables defined in prebuild step if maven project is used
Markus Meisterernst
edited a comment on JENKINS-14193
EnvInject doesn't pass variables defined in prebuild step if maven project is used
Hi again,
as Jaime pointed out, the problem stems from the fact that a variable is to be resolved dynamically from outside to the environment.
In my case I wanted to set a variable from a call to git ("git describe" to get hold of the revision count from the latest label).
I therefore executed a Shell script, redirected the output to a file and read in the Property file to inject the property to the Environment.
My intend was to pass it to a "parameterized" maven build like the following: clean install deploy -Drevision=${Revison}.
>From the build console output I can see that it doesn't resolve the variable ${Revision}. The Environment, however, has this Parameter perfectly resolved and set.
So, the workaround you suggested won't work in my case.
Currently we stick to the BUILD_NUMBER which is resolved magically enough (mvn clean install deploy -Drevision=${BUILD_NUMBER}).
Ok, it's a workaround, a nasty one as it is linear increasing with no real connection to git and versioning/branching stuff.
As I'm quite new ot the Jenkins eco-system I ask myself, if it is best to write a plugin for my case ...
Or else (what would make much more sense) if you could give me guidance on where about to apply a fix so I could offer you some time to analyse and help out to improve the EnvInject plugin.
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-14193) EnvInject doesn't pass variables defined in prebuild step if maven project is used
Markus Meisterernst
commented on JENKINS-14193
EnvInject doesn't pass variables defined in prebuild step if maven project is used
Hi again,
as Jaime pointed out, the problem stems from the fact that a variable is to be resolved dynamically from outside to the environment.
In my case I wanted to set a variable from a call to git ("git describe" to get hold of the revision number from the latest label).
I therefore executed a Shell script, redirected the output to a file and read in the Property file to inject the property to the Environment.
My intend was to pass it to a "parameterized" maven build like the following: clean install deploy -Drevision=${Revison}.
>From the build console output I can see that it doesn't resolve the variable ${Revision}. The Environment, however, has this Parameter perfectly resolved and set.
So, the workaround you suggested won't work in my case.
Currently we stick to the BUILD_NUMBER which is resolved magically enough (mvn clean install deploy -Drevision=${BUILD_NUMBER}).
Ok, it's a workaround, a nasty one as it is linear increasing with no real connection to git and versioning/branching stuff.
As I'm quite new ot the Jenkins eco-system I ask myself, if it is best to write a plugin for my case ...
Or else (what would make much more sense) if you could give me guidance on where about to apply a fix so I could offer you some time to analyse and help out to improve the EnvInject plugin.
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-14685) Subversion Plugin should be able to ignore property only commits (eps. Mergeinfos)
SCM/JIRA link daemon commented on JENKINS-14685 Subversion Plugin should be able to ignore property only commits (eps. Mergeinfos) Code changed in jenkins User: Christoph Kutzinski Path: src/test/java/hudson/scm/SubversionSCMTest.java http://jenkins-ci.org/commit/subversion-plugin/a169a06ec7c551052e5376dfbf3c9f593523645d Log: Merge pull request #31 from pauxus/JENKINS-14685-fixed-testcases Corrected Unit Tests for JENKINS-14685 Compare: https://github.com/jenkinsci/subversion-plugin/compare/e23fff3db379...a169a06ec7c5 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-14685) Subversion Plugin should be able to ignore property only commits (eps. Mergeinfos)
SCM/JIRA link daemon commented on JENKINS-14685 Subversion Plugin should be able to ignore property only commits (eps. Mergeinfos) Code changed in jenkins User: Stephan Pauxberger Path: src/test/java/hudson/scm/SubversionSCMTest.java http://jenkins-ci.org/commit/subversion-plugin/a4b1b19f49a1c028cd07d0a4e92ec3be17687351 Log: Corrected Unit Tests for JENKINS-14685 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-16401) Repostiroy URL and Repository ID fields of the Post-Build Action seeings mysteriously go blank
Nihar Amin updated JENKINS-16401 Repostiroy URL and Repository ID fields of the Post-Build Action seeings mysteriously go blank Change By: Nihar Amin (17/Jan/13 7:30 PM) Description: Jenkins Version - 1.4.80Uploading: http://maven.platform.tm.tmcs:8081/nexus/service/local/staging/deploy/maven2/com/ticketmaster/wallet/wallet-parent/5.0.0-SNAPSHOT/ wallet-parent-5.0.0-20130111.191842-1.pom ERROR: Failed to deploy artifacts: Could not transfer artifact com.ticketmaster.wallet:wallet-parent:pom:5.0.0-20130111. 191842 1910042 -1 from/to staging (http://maven.platform.tm.tmcs:8081/nexus/service/local/staging/deploy/maven2/): Failed to transfer file: http://maven.platform.tm.tmcs:8081/nexus/service/local/staging/deploy/maven2/com/ticketmaster/wallet/wallet-parent/5.0.0-SNAPSHOT/wallet-parent-5.0.0-20130111. 191842 10082042 -1.pom. Return code is: 400, ReasonPhrase:Bad RequestLately we have been seeing some issues with 3 of our projects which leads to build failure and they are related to configuration bug. After doing some investigation, we found in all cases that the Repository URL, and Repository ID fields of the Post-Build Actions settings mysteriously had been set blank in the jenkins job. In none of these cases do members of our team recall making any changes to the job, and certainly did not modify these fields, in this last case we do know that a team member had viewed the job page, but also that *no* changes were made, let alone applied or saved. The failure is always in these two fields and its always the same - the fields go blank. After build failure, if we reset these two fields with correct values it works fine but a few days later it goes blank again. The fact that this blanking behavior affects the same two fields every time is a sign of configuration bug. Can you please provide some feedback? Also it'd be great if Jenkins job configurations could be saved as text and examined.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-16401) Repostiroy URL and Repository ID fields of the Post-Build Action seeings mysteriously go blank
Nihar Amin created JENKINS-16401 Repostiroy URL and Repository ID fields of the Post-Build Action seeings mysteriously go blank Issue Type: Bug Assignee: mdonohue Components: configurationslicing Created: 17/Jan/13 7:28 PM Description: Jenkins Version - 1.4.80 Uploading: http://maven.platform.tm.tmcs:8081/nexus/service/local/staging/deploy/maven2/com/ticketmaster/wallet/wallet-parent/5.0.0-SNAPSHOT/wallet-parent-5.0.0-20130111.191842-1.pom ERROR: Failed to deploy artifacts: Could not transfer artifact com.ticketmaster.wallet:wallet-parent:pom:5.0.0-20130111.191842-1 from/to staging (http://maven.platform.tm.tmcs:8081/nexus/service/local/staging/deploy/maven2/): Failed to transfer file: http://maven.platform.tm.tmcs:8081/nexus/service/local/staging/deploy/maven2/com/ticketmaster/wallet/wallet-parent/5.0.0-SNAPSHOT/wallet-parent-5.0.0-20130111.191842-1.pom. Return code is: 400, ReasonPhrase:Bad Request Lately we have been seeing some issues with 3 of our projects which leads to build failure and they are related to configuration bug. After doing some investigation, we found in all cases that the Repository URL, and Repository ID fields of the Post-Build Actions settings mysteriously had been set blank in the jenkins job. In none of these cases do members of our team recall making any changes to the job, and certainly did not modify these fields, in this last case we do know that a team member had viewed the job page, but also that no changes were made, let alone applied or saved. The failure is always in these two fields and its always the same - the fields go blank. After build failure, if we reset these two fields with correct values it works fine but a few days later it goes blank again. The fact that this blanking behavior affects the same two fields every time is a sign of configuration bug. Can you please provide some feedback? Also it'd be great if Jenkins job configurations could be saved as text and examined. Thanks Project: Jenkins Priority: Minor Reporter: Nihar Amin 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-8013) Baseline listbox suggestion
Warren Racz commented on JENKINS-8013 Baseline listbox suggestion The following should work: -fmt '%Nd %XPn\n' Results will contain MMDD.HHMMSS baseline: before each baseline name which would need to be sorted to determine order and removed before presented to the user... 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-14856) Slave Registered Remote Controls not identified in Jenkins Selenium Grid
rejesi closed JENKINS-14856 as Cannot Reproduce Slave Registered Remote Controls not identified in Jenkins Selenium Grid Closing this issue as it was probably user error. Change By: rejesi (17/Jan/13 6:56 PM) Status: Open Closed Resolution: Cannot Reproduce 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-12272) Get the error when creating the view "cleartool mkview -tag $view-name $view-name" with plugin 1.7.4, additional view-name added at the end of command line
Warren Racz
commented on JENKINS-12272
Get the error when creating the view "cleartool mkview -tag $view-name $view-name" with plugin 1.7.4, additional view-name added at the end of command line
I too am faced with an issue where I need to be able to use -host -hpath -gpath in the mkview options. I am not a committer of the code, but I'll contribute by attempting to suggest a possible resolution...
I believe the problem could be rectified in
https://svn.jenkins-ci.org/trunk/hudson/plugins/clearcase-ucm-baseline/src/main/java/com/michelin/cio/hudson/plugins/clearcaseucmbaseline/ClearToolUcmBaseline.java
// HUDSON-6409
if(StringUtils.isNotBlank(mkviewOptionalParam)) {
cmd.addTokenized(Util.replaceMacro(mkviewOptionalParam, variableResolver));
}
// HUDSON-8168
// cleartool mkview ...
// { –stg/loc { view-stgloc-name | –aut/o }
// | [ –hos/t hostname –hpa/th host-storage-pname –gpa/th global-storage-pname ] dynamic-view-storage-pname }
if(!StringUtils.contains(mkviewOptionalParam, "-stg")) {
cmd.add(viewName);
}
If it's safe to assume that you only append the view name when there are no optional arguments passed in then I'd suggest this fix:
// HUDSON-6409, HUDSON-8168, JENKINS-12272
if(StringUtils.isNotBlank(mkviewOptionalParam)) {
cmd.addTokenized(Util.replaceMacro(mkviewOptionalParam, variableResolver));
} else {
cmd.add(viewName);
}
Otherwise I think something like this should resolve it:
// HUDSON-6409
if(StringUtils.isNotBlank(mkviewOptionalParam)) {
cmd.addTokenized(Util.replaceMacro(mkviewOptionalParam, variableResolver));
}
// HUDSON-8168, JENKINS-122272
// cleartool mkview ...
// { –stg/loc { view-stgloc-name | –aut/o }
// | [ –hos/t hostname –hpa/th host-storage-pname –gpa/th global-storage-pname ] dynamic-view-storage-pname }
if (!StringUtils.contains(mkviewOptionalParam, "-stg") && !StringUtils.contains(mkviewOptionalParam, "-host") && !StringUtils.contains(mkviewOptionalParam, "-hpath") && !StringUtils.contains(mkviewOptionalParam, "-gpath")) {
cmd.add(viewName);
}
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-16397) Loading asynchPeople calls (synch) People constructor
dogfood commented on JENKINS-16397 Loading asynchPeople calls (synch) People constructor Integrated in jenkins_main_trunk #2197 [FIXED JENKINS-16397] Just displaying /asynchPeople constructed the expensive People object merely to decide whether or not to display the “REST API” link. (Revision 063acce1e1886b8f30ba8657b1dbe7c7804e7796) Result = SUCCESS Jesse Glick : 063acce1e1886b8f30ba8657b1dbe7c7804e7796 Files : core/src/main/java/hudson/model/View.java 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-14856) Slave Registered Remote Controls not identified in Jenkins Selenium Grid
rejesi commented on JENKINS-14856 Slave Registered Remote Controls not identified in Jenkins Selenium Grid I believe that somehow it was user error. It resolved and started showing properly after a week or so. I have since stopped using this plugin. I will close this issue. 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-15809) Failed to scout hudson.plugins.robot.tokens.RobotPassPercentageTokenMacro
shinsato commented on JENKINS-15809 Failed to scout hudson.plugins.robot.tokens.RobotPassPercentageTokenMacro I just started seeing this error today. It kills the Jenkins server. Not finding solutions elsewhere, but I was able to fix it by deleting jenkins/plugins/robot and letting it unpack the robot.jpi file again. 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-16391) Allow publication even if build failed
Johannes Ohlemacher commented on JENKINS-16391 Allow publication even if build failed i fully agree, its already on my todo list since a couple of weeks I will add a configuration option for the next release. 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-16400) HealthReports Does Not Include All Clover Result Values
rejesi created JENKINS-16400 HealthReports Does Not Include All Clover Result Values Issue Type: Improvement Assignee: stephenconnolly Components: clover, core Created: 17/Jan/13 5:51 PM Description: Hi, we are using the html-with-health-and-console.jelly file in the email-ext plugin to display the metrics health results in the build results email. The problem is that it only displays the "Clover Coverage Statements" value in the email. Is there any way to get the other two "Conditionals" and "Methods" values to show as well? When trying to do some debugging and I can only find a cachedBuildHealthReports arrayList, and it only shows the "Clover Coverage Statements" and not the other two, but all three values show up in the build UI pages. Am I missing something or are the other two result values not available via the HealthReport? Project: Jenkins Priority: Minor Reporter: rejesi 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-16175) Dashboard not showing job status
Richard Merrill commented on JENKINS-16175 Dashboard not showing job status Sorry, didn't find the initial issue in my search before posting this one. I notice that the other issue (and others which duplicate it) don't indicate any progress on determining exactly what is causing the problem, much less a fix for 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-16375) show job difference does not work, url escaped twice
Kathi Stutz assigned JENKINS-16375 to Kathi Stutz show job difference does not work, url escaped twice Change By: Kathi Stutz (17/Jan/13 5:29 PM) Assignee: Mirko Friedenhagen Kathi Stutz 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-16397) Loading asynchPeople calls (synch) People constructor
SCM/JIRA link daemon commented on JENKINS-16397 Loading asynchPeople calls (synch) People constructor Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/java/hudson/model/View.java http://jenkins-ci.org/commit/jenkins/063acce1e1886b8f30ba8657b1dbe7c7804e7796 Log: [FIXED JENKINS-16397] Just displaying /asynchPeople constructed the expensive People object merely to decide whether or not to display the “REST API” link. 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-16397) Loading asynchPeople calls (synch) People constructor
SCM/JIRA link daemon resolved JENKINS-16397 as Fixed Loading asynchPeople calls (synch) People constructor Change By: SCM/JIRA link daemon (17/Jan/13 5:16 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-16399) SCM documentation is incorrect
Walter Kacynski updated JENKINS-16399 SCM documentation is incorrect Change By: Walter Kacynski (17/Jan/13 4:57 PM) Summary: SCM documetnation documentation is incorrect 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-16399) SCM documetnation is incorrect
Walter Kacynski created JENKINS-16399 SCM documetnation is incorrect Issue Type: Bug Assignee: Gregory Boissinot Attachments: SCM documentation.png Components: envinject Created: 17/Jan/13 4:56 PM Description: In the section "Inject environment variables to the build process" The docs for Properties file state that it is executed after SCM checkout, which is correct. The docs for Script File Path state before SCM checkout, which is incorrect. Project: Jenkins Priority: Major Reporter: Walter Kacynski 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-16398) Relative pre-build Script paths don't work
Walter Kacynski created JENKINS-16398 Relative pre-build Script paths don't work Issue Type: Bug Assignee: Gregory Boissinot Attachments: Absolute Path Required.png Components: envinject Created: 17/Jan/13 4:52 PM Description: I'm using both a properties file path and script file path in a pre-build section. The properties file path resolves to the relative workspace correctly however, when using a script file it does not. One must enter a fully qualified path. NON WORKING: 11:26:56 Changelog calculated successfully. 11:26:56 Run condition [Boolean condition] enabling prebuild for step [Execute Windows batch command] 11:26:56 No emails were triggered. 11:26:56 [EnvInject] - Executing scripts and injecting environment variables after the SCM step. 11:26:57 [EnvInject] - Injecting as environment variables the properties file path 'properties/environment.properties' 11:26:57 [EnvInject] - Variables injected successfully. 11:26:57 [EnvInject] - Injecting as environment variables the properties content 11:26:57 AO_APPLICATION=WebSphereBuilds 11:26:57 AO_ENVIRONMENT=SND 11:26:57 11:26:57 [EnvInject] - Variables injected successfully. 11:26:57 Executing 'setupClasspath.bat'. 11:26:57 [SND-WebSphereBuilds] $ setupClasspath.bat 11:26:57 [EnvInject] - [ERROR] - [EnvInject] - [ERROR] - Problems occurs on injecting env vars as a build wrap: Error occurs on execution script file path. 11:26:57 Run condition [Boolean condition] enabling perform for step [Execute Windows batch command] 11:26:57 [SND-WebSphereBuilds] $ cmd /c call E:\TEMP\hudson614402344419560499.bat WORKING: 11:30:19 Run condition [Boolean condition] enabling prebuild for step [Execute Windows batch command] 11:30:19 No emails were triggered. 11:30:19 [EnvInject] - Executing scripts and injecting environment variables after the SCM step. 11:30:19 [EnvInject] - Injecting as environment variables the properties file path 'properties/environment.properties' 11:30:19 [EnvInject] - Variables injected successfully. 11:30:19 [EnvInject] - Injecting as environment variables the properties content 11:30:19 AO_APPLICATION=WebSphereBuilds 11:30:19 AO_ENVIRONMENT=SND 11:30:19 11:30:19 [EnvInject] - Variables injected successfully. 11:30:19 Executing 'E:/JenkinsWAND/workspace/SND-WebSphereBuilds/bin/setupClasspath.bat'. 11:30:19 [SND-WebSphereBuilds] $ E:/JenkinsWAND/workspace/SND-WebSphereBuilds/bin/setupClasspath.bat 11:30:19 [EnvInject] - Script executed successfully. 11:30:19 [locks-and-latches] Checking to see if we really have the locks 11:30:19 [locks-and-latches] Have all the locks, build can start 11:30:19 [EnvInject] - Injecting environment variables from a build step. 11:30:19 [EnvInject] - Injecting as environment variables the properties file path 'E:/JenkinsWAND/workspace/SND-WebSphereBuilds/properties/classpath.properties' 11:30:19 [EnvInject] - Variables injected successfully. Project: Jenkins Priority: Major Reporter: Walter Kacynski 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-9891) Duplicated plugin entries
Jesse Glick updated JENKINS-9891 Duplicated plugin entries Change By: Jesse Glick (17/Jan/13 4:31 PM) Component/s: perfpublisher Component/s: core 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-16397) Loading asynchPeople calls (synch) People constructor
Jesse Glick commented on JENKINS-16397 Loading asynchPeople calls (synch) People constructor layout.jelly tests it.api!=null. Making People. lazy is impractical since the information is a field (ugh), but avoiding construction of People until the last minute may work. 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-15045) Support Github commit status API
Jesse Glick commented on JENKINS-15045 Support Github commit status API https://github.com/jenkinsci/github-plugin/pull/23 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-16394) Subversion polling broken
kutzi assigned JENKINS-16394 to kutzi Subversion polling broken Change By: kutzi (17/Jan/13 4:27 PM) Assignee: Brent Atkinson kutzi 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-16396) validate provider URL
SCM/JIRA link daemon resolved JENKINS-16396 as Fixed validate provider URL Change By: SCM/JIRA link daemon (17/Jan/13 4:11 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-16396) validate provider URL
SCM/JIRA link daemon commented on JENKINS-16396 validate provider URL Code changed in jenkins User: Kohsuke Kawaguchi Path: src/main/java/hudson/plugins/openid/OpenIdSsoSecurityRealm.java src/main/resources/hudson/plugins/openid/OpenIdSsoSecurityRealm/config.jelly http://jenkins-ci.org/commit/openid-plugin/177515e02bb0f9fa6d5dc493f753f6cd9beee0b7 Log: [FIXED JENKINS-16396] Added form validation to the provider URL 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-16394) Subversion polling broken
SCM/JIRA link daemon commented on JENKINS-16394 Subversion polling broken Code changed in jenkins User: Christoph Kutzinski Path: src/main/java/hudson/scm/DefaultSVNLogFilter.java src/main/java/hudson/scm/NullSVNLogFilter.java src/main/java/hudson/scm/SVNLogFilter.java src/main/java/hudson/scm/SubversionSCM.java http://jenkins-ci.org/commit/subversion-plugin/e23fff3db3791d7b2a9aefaf49092b5e5df7a68e Log: [FIXED JENKINS-16394] Polling broken because of not serializable DefaultSVNLogFilter 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-16394) Subversion polling broken
SCM/JIRA link daemon resolved JENKINS-16394 as Fixed Subversion polling broken Change By: SCM/JIRA link daemon (17/Jan/13 4:11 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-14951) In a Matrix job, Environment Script variables are not expanded in a Parameterized Build Trigger
cjo9900 commented on JENKINS-14951 In a Matrix job, Environment Script variables are not expanded in a Parameterized Build Trigger This issue also occurs with the EnvInject plugin which does a similar behaviour to environment-script plugin https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin 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-16342) asynchPeople very slow when using Gravatar & Subversion plugins
Jesse Glick updated JENKINS-16342 asynchPeople very slow when using Gravatar & Subversion plugins Serious enough to potentially merit backport to 1.480.x. Change By: Jesse Glick (17/Jan/13 3:41 PM) Priority: Major Critical 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-16397) Loading asynchPeople calls (synch) People constructor
Jesse Glick created JENKINS-16397 Loading asynchPeople calls (synch) People constructor Issue Type: Bug Assignee: Jesse Glick Components: core Created: 17/Jan/13 3:41 PM Description: Browsing /asynchPeople seemed to block even though the page load should be immediate. Capturing a thread dump showed "Handling GET /asynchPeople/ : http-8080-8" Id=35 Group=main RUNNABLE at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:220) at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264) at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) - locked java.io.FileReader@5520101d at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked java.io.FileReader@5520101d at java.io.BufferedReader.readLine(BufferedReader.java:362) at hudson.plugins.git.GitChangeLogParser.parse(GitChangeLogParser.java:44) at hudson.plugins.git.GitChangeLogParser.parse(GitChangeLogParser.java:21) at hudson.model.AbstractBuild.calcChangeSet(AbstractBuild.java:842) at hudson.model.AbstractBuild.getChangeSet(AbstractBuild.java:816) at hudson.model.View$People.getUserInfo(View.java:680) at hudson.model.View$People.(View.java:658) at hudson.model.View$AsynchPeople.getApi(View.java:835) at sun.reflect.GeneratedMethodAccessor327.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125) at org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314) at org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185) at org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75) 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.ASTNENode.value(ASTNENode.java:55) at org.apache.commons.jexl.parser.ASTExpression.value(ASTExpression.java:54) at org.apache.commons.jexl.parser.ASTExpressionExpression.value(ASTExpressionExpression.java:56) at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) at hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:72) at org.apache.commons.jelly._expression_.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61) at org.apache.commons.jelly._expression_.ExpressionSupport.evaluateAsBoolean(ExpressionSupport.java:71) at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:97) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:81) at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:63) at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker
[JIRA] (JENKINS-16396) validate provider URL
Kohsuke Kawaguchi created JENKINS-16396 validate provider URL Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: openid Created: 17/Jan/13 3:30 PM Description: Validate the provider URL before the form gets submitted, as it results in a nasty problem. Project: Jenkins Priority: Major Reporter: Kohsuke Kawaguchi 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-16395) The path parameter in the REST API should support wildcard '*'.
Kohsuke Kawaguchi created JENKINS-16395 The path parameter in the REST API should support wildcard '*'. Issue Type: Bug Assignee: Unassigned Components: core Created: 17/Jan/13 3:26 PM Description: Like path=foo[*] or maybe even path=*[name] Project: Jenkins Priority: Major Reporter: Kohsuke Kawaguchi 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-14951) In a Matrix job, Environment Script variables are not expanded in a Parameterized Build Trigger
cjo9900 commented on JENKINS-14951 In a Matrix job, Environment Script variables are not expanded in a Parameterized Build Trigger Issues still occurs when the env is stored on matrix builds. It seems that on the matrix builds the Captured Environment Action is not being created for the parent. Even with the Captured Environment Action being created for the parent the issue is still seen. The problem here is that build wrappers setup()[1] are not called in a MatrixBuild doRun() (build class for the parent of the matrix project). MatrixBuild extends from AbstractBuild not Build class. Where as it is called for the individual Matrix Runs [2] which do not override the doRun() method of Build so calling the wrapper and adding the environment. MatrixRun extends Build which extends AbstractBuild So this also raises the issue that if run with "Run Only On Parent" is checked then none of the variables as avaliable in the child jobs, always giving the "ERROR: [environment-script] Unable to load persisted environment from matrix parent job, not injecting any variables" in the logs. [1] https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/matrix/MatrixBuild.java#L340 [2] https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/Build.java#L154 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-14143) Can't build project with jdk 5 when jenkins runs on tomcat 7
Ophélie Salm reopened JENKINS-14143 Can't build project with jdk 5 when jenkins runs on tomcat 7 Hi, I'm reopening this issue because it really seams to be a defect. I encountered the same problem running Jenkins LTS 1.480.2 on Tomcat 7 with JDK6 I want to build a maven project with the maven 2/3 job type using a JDK 1.5. Here is the complete stack trace i get : java.io.IOException: Remote call on Channel to Maven [C:\Applications\Java\JDK\JDK1.5.0/bin/java, -Dm3plugin.lib=E:\.jenkins\plugins\artifactory\WEB-INF\lib, -cp, E:\.jenkins\plugins\maven-plugin\WEB-INF\lib\maven3-agent-1.2.jar;C:\maven\boot\plexus-classworlds-2.4.jar, org.jvnet.hudson.maven3.agent.Maven3Main, C:\maven, C:\TomcatInstance\JENKINS\webapps\ci\WEB-INF\lib\remoting-2.17.jar, E:\.jenkins\plugins\maven-plugin\WEB-INF\lib\maven3-interceptor-1.2.jar, 51083] failed at hudson.remoting.Channel.call(Channel.java:673) at hudson.maven.ProcessCache$MavenProcess.call(ProcessCache.java:156) at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:791) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499) at hudson.model.Run.execute(Run.java:1502) 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: java.lang.ClassFormatError: Failed to load org.kohsuke.stapler.Stapler at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:154) at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:131) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) at hudson.model.Result.(Result.java:191) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:164) at $Proxy2.(Unknown Source) at sun.reflect.GeneratedSerializationConstructorAccessor37.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Constructor.java:501) at java.io.ObjectStreamClass.newInstance(ObjectStreamClass.java:896) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1704) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1910) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1834) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at java.util.HashMap.readObject(HashMap.java:1067) 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:592) at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1812) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1910) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1834) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at hudson.remoting.UserRequest.deserialize(UserRequest.java:182) at hudson.remoting.UserRequest.perform(UserRequest.java:98) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) at java.util.concurrent.FutureTask.run(FutureTask.java:123) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.ClassFormatError: Failed to load javax.servlet.http.HttpServle
[JIRA] (JENKINS-16394) Subversion polling broken
kutzi
updated JENKINS-16394
Subversion polling broken
Change By:
kutzi
(17/Jan/13 3:10 PM)
Description:
Repository polling is broken in the (not yet released) version 1.45This seems to be related to this commit: https://github.com/jenkinsci/subversion-plugin/blob/a3583f4378576d8932eaeb9514799df6225c7e60/src/main/java/hudson/scm/DefaultSVNLogFilter.java
{code}
Subversion Polling LogStarted on Jan 17, 2013 2:51:36 PMFATAL: Unable to serialize hudson.scm.SubversionSCM$1@785d4fe4java.io.IOException: Unable to serialize hudson.scm.SubversionSCM$1@785d4fe4 at hudson.remoting.UserRequest.serialize(UserRequest.java:166) at hudson.remoting.UserRequest.(UserRequest.java:62) at hudson.remoting.Channel.call(Channel.java:667) at hudson.scm.SubversionSCM.compareRemoteRevisionWith(SubversionSCM.java:1274) at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:355) at hudson.scm.SCM.poll(SCM.java:372) at hudson.model.AbstractProject.poll(AbstractProject.java:1324) at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:420) at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:449) at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662)Caused by: java.io.NotSerializableException: hudson.scm.DefaultSVNLogFilter at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) at hudson.remoting.UserRequest._serialize(UserRequest.java:155) at hudson.remoting.UserRequest.serialize(UserRequest.java:164) ... 15 moreDone. Took 1.6 secNo changes
{code}
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-16394) Subversion polling broken
kutzi updated JENKINS-16394 Subversion polling broken Change By: kutzi (17/Jan/13 3:01 PM) Description: Repository polling is borken broken in the (not yet released) version 1.45This seems to be related to this commit: https://github.com/jenkinsci/subversion-plugin/blob/a3583f4378576d8932eaeb9514799df6225c7e60/src/main/java/hudson/scm/DefaultSVNLogFilter.javaSubversion Polling LogStarted on Jan 17, 2013 2:51:36 PMFATAL: Unable to serialize hudson.scm.SubversionSCM$1@785d4fe4java.io.IOException: Unable to serialize hudson.scm.SubversionSCM$1@785d4fe4 at hudson.remoting.UserRequest.serialize(UserRequest.java:166) at hudson.remoting.UserRequest.(UserRequest.java:62) at hudson.remoting.Channel.call(Channel.java:667) at hudson.scm.SubversionSCM.compareRemoteRevisionWith(SubversionSCM.java:1274) at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:355) at hudson.scm.SCM.poll(SCM.java:372) at hudson.model.AbstractProject.poll(AbstractProject.java:1324) at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:420) at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:449) at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662)Caused by: java.io.NotSerializableException: hudson.scm.DefaultSVNLogFilter at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) at hudson.remoting.UserRequest._serialize(UserRequest.java:155) at hudson.remoting.UserRequest.serialize(UserRequest.java:164) ... 15 moreDone. Took 1.6 secNo changes 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-16394) Subversion polling broken
kutzi created JENKINS-16394 Subversion polling broken Issue Type: Bug Assignee: Unassigned Components: subversion Created: 17/Jan/13 3:01 PM Description: Repository polling is borken in the (not yet released) version 1.45 This seems to be related to this commit: https://github.com/jenkinsci/subversion-plugin/blob/a3583f4378576d8932eaeb9514799df6225c7e60/src/main/java/hudson/scm/DefaultSVNLogFilter.java Subversion Polling Log Started on Jan 17, 2013 2:51:36 PM FATAL: Unable to serialize hudson.scm.SubversionSCM$1@785d4fe4 java.io.IOException: Unable to serialize hudson.scm.SubversionSCM$1@785d4fe4 at hudson.remoting.UserRequest.serialize(UserRequest.java:166) at hudson.remoting.UserRequest.(UserRequest.java:62) at hudson.remoting.Channel.call(Channel.java:667) at hudson.scm.SubversionSCM.compareRemoteRevisionWith(SubversionSCM.java:1274) at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:355) at hudson.scm.SCM.poll(SCM.java:372) at hudson.model.AbstractProject.poll(AbstractProject.java:1324) at hudson.triggers.SCMTrigger$Runner.runPolling(SCMTrigger.java:420) at hudson.triggers.SCMTrigger$Runner.run(SCMTrigger.java:449) at hudson.util.SequentialExecutionQueue$QueueEntry.run(SequentialExecutionQueue.java:118) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.io.NotSerializableException: hudson.scm.DefaultSVNLogFilter at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330) at hudson.remoting.UserRequest._serialize(UserRequest.java:155) at hudson.remoting.UserRequest.serialize(UserRequest.java:164) ... 15 more Done. Took 1.6 sec No changes Project: Jenkins Priority: Blocker Reporter: kutzi 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-16394) Subversion polling broken
kutzi assigned JENKINS-16394 to Brent Atkinson Subversion polling broken Change By: kutzi (17/Jan/13 3:01 PM) Assignee: Brent Atkinson 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-3002) TFS Support to get labels
Francesco Gapito edited a comment on JENKINS-3002 TFS Support to get labels can you please send your changes to me at francesco.gap...@gmail.com? Thank you very much! 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-3002) TFS Support to get labels
Francesco Gapito commented on JENKINS-3002 TFS Support to get labels can you please change your changes to francesco.gap...@gmail.com? Thank you very much! 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-10038) Pass on changes to triggered project
nuadhu1 commented on JENKINS-10038 Pass on changes to triggered project This RFE looks similar to one I filed recently: JENKINS-16311 - "Feature to display contributory upstream job changes in downstream builds.". Also includes the triggered changes as mentioned in JENKINS-1957. 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-16393) "Unable to call join" build failures
Krzysztof Malinowski created JENKINS-16393 "Unable to call join" build failures Issue Type: Bug Assignee: Unassigned Components: core Created: 17/Jan/13 2:42 PM Description: It happens that builds fail with something like: FATAL: Unable to call join. Invalid object ID 1583 java.lang.IllegalStateException: Unable to call join. Invalid object ID 1583 at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:269) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:256) 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:326) 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) This reduces chance to get successful matrix build. In this particular instance 4 out of 10 configurations in matrix build failed with this stacktrace upon requesting changes from scm. Environment: Jenkins 1.498 on RHEL 5 x86_64 Project: Jenkins Priority: Major Reporter: Krzysztof Malinowski 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-15763) Publisher hudson.tasks.Mailer aborted due to exception
kutzi commented on JENKINS-15763 Publisher hudson.tasks.Mailer aborted due to exception @christopeM: no, it isn't 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
Ognjen Bubalo commented on JENKINS-16010 Plugin consumes too much memory Jenkins serializes the objects with XStream into the build.xml. We need a bigger refactor, so we would not serialize the coverage objects, instead we would use maybe the Jenkins's new database plugin for storing. Ref: https://wiki.jenkins-ci.org/display/JENKINS/Database+Plugin 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-9258) "Remember me on this computer", still getting asked to log in after a few hours
gatrot commented on JENKINS-9258 "Remember me on this computer", still getting asked to log in after a few hours Agreed, but I'd prefer a hack over months and months of annoyance for hundreds of developers. Unfortunately, I don't have time to fix the underlying issue. 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
Ognjen Bubalo started work on JENKINS-16010 Plugin consumes too much memory Change By: Ognjen Bubalo (17/Jan/13 2:23 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-9258) "Remember me on this computer", still getting asked to log in after a few hours
James Howe commented on JENKINS-9258 "Remember me on this computer", still getting asked to log in after a few hours Stephane Odul's solution is just a hack though. The problem is not that the session expires, it's that the remember me feature does not do anything to make you a new one. I agree though that it is the most annoying thing about Jenkins and really needs proper dev attention ASAP. 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-16392) Hardware properties like hw.ramSize and vm.heapSize should be set in hardware-qemu.ini instead of config.ini for newer Android SDKs
Uwe Kubosch created JENKINS-16392 Hardware properties like hw.ramSize and vm.heapSize should be set in hardware-qemu.ini instead of config.ini for newer Android SDKs Issue Type: Bug Affects Versions: current Assignee: Christopher Orr Components: android-emulator Created: 17/Jan/13 2:22 PM Description: Setting hardware properties in config.ini has no effect on newer versions of the Android SDK. Project: Jenkins Priority: Blocker Reporter: Uwe Kubosch 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-11461) FATAL: hudson.remoting.RequestAbortedException: java.net.SocketException: Connection reset
aleksas commented on JENKINS-11461 FATAL: hudson.remoting.RequestAbortedException: java.net.SocketException: Connection reset Similar problem Jenklins 1.492 Master, Node Java: v1.7 OS: Win Server 2008 R2 Slave.jar version: 2.18 FATAL: hudson.remoting.RequestAbortedException: java.net.SocketException: Connection reset hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.net.SocketException: Connection reset at hudson.remoting.Request.call(Request.java:174) at hudson.remoting.Channel.call(Channel.java:665) at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158) at $Proxy58.join(Unknown Source) at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:915) at hudson.Launcher$ProcStarter.join(Launcher.java:360) at hudson.plugins.msbuild.MsBuildBuilder.perform(MsBuildBuilder.java:164) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804) at hudson.model.Build$BuildExecution.build(Build.java:199) at hudson.model.Build$BuildExecution.doRun(Build.java:160) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:586) at hudson.model.Run.execute(Run.java:1518) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: hudson.remoting.RequestAbortedException: java.net.SocketException: Connection reset at hudson.remoting.Request.abort(Request.java:299) at hudson.remoting.Channel.terminate(Channel.java:725) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69) Caused by: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(Unknown Source) at java.net.SocketInputStream.read(Unknown Source) at java.io.BufferedInputStream.fill(Unknown Source) at java.io.BufferedInputStream.read(Unknown Source) at java.io.ObjectInputStream$PeekInputStream.peek(Unknown Source) at java.io.ObjectInputStream$BlockDataInputStream.peek(Unknown Source) at java.io.ObjectInputStream$BlockDataInputStream.peekByte(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at hudson.remoting.Command.readFrom(Command.java:90) at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) 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-15199) Slaves turns to "Dead" state after connecting to remote machine
Magnus Larsson edited a comment on JENKINS-15199 Slaves turns to "Dead" state after connecting to remote machine It seems to work for me now. My "SSH Slave Plugin" was out-of-date (v2.1). I upgraded to 2.2 and my Dead slave nodes went away. I'm now running v1.499 with no 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-9258) "Remember me on this computer", still getting asked to log in after a few hours
gatrot commented on JENKINS-9258 "Remember me on this computer", still getting asked to log in after a few hours This is the most annoying thing about Jenkins at our company. I have a pull request that incorporates Stephane Odul's session timeout suggestion (with a default of two days). Please comment on the pull request if you'd like to see it approved. The more comments, the more popular, the better chance it has to make it in to the main line. Thanks! https://github.com/jenkinsci/jenkins/pull/674 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-15199) Slaves turns to "Dead" state after connecting to remote machine
Magnus Larsson commented on JENKINS-15199 Slaves turns to "Dead" state after connecting to remote machine It seems to work for me now. My "SSH Slave Plugin" was out-of-date (v2.1). I upgraded to 2.2 and my Dead slave nodes went away. 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-15763) Publisher hudson.tasks.Mailer aborted due to exception
christopheM commented on JENKINS-15763 Publisher hudson.tasks.Mailer aborted due to exception I guess its is a duplicate of https://issues.jenkins-ci.org/browse/JENKINS-15440 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-16390) Loading user configuration form invokes MailAddressResolvers
Oliver Gondža commented on JENKINS-16390 Loading user configuration form invokes MailAddressResolvers https://github.com/jenkinsci/mailer-plugin/pull/3 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-16391) Allow publication even if build failed
Francois Molinier created JENKINS-16391 Allow publication even if build failed Issue Type: Improvement Assignee: Johannes Ohlemacher Components: valgrind Created: 17/Jan/13 1:05 PM Description: Before publishing the results, the plugin checks that the build result is not ABORTED or FAILURE. The trouble with checking for failure is that other publishers can set the status to FAILURE, but the valgrind xml is still available. In that case it is impossible to show the result of valgrind. Could you consider removing this restriction, maybe via a configuration option? Project: Jenkins Priority: Major Reporter: Francois Molinier 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-16390) Loading user configuration form invokes MailAddressResolvers
Oliver Gondža created JENKINS-16390 Loading user configuration form invokes MailAddressResolvers Issue Type: Improvement Assignee: Oliver Gondža Components: core Created: 17/Jan/13 12:59 PM Description: Invoking MailAddressResolvers from UI should generally be discouraged due to the unpredictable load time caused by number of registered resolvers. Environment: mailer-plugin Project: Jenkins Priority: Major Reporter: Oliver Gondža 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-16389) Emailing users at the end of a failed build very slow for big Jenkins instance using CVS
kutzi updated JENKINS-16389 Emailing users at the end of a failed build very slow for big Jenkins instance using CVS Change By: kutzi (17/Jan/13 12:39 PM) Description: Basically the same issue as JENKINS-15440, only for CVS.Description was mainly copied from there. At the end of a failing build, the hudson.tasks.MailSender.buildCulpritList determines who to email. The problem comes when hudson.scm.MailAddressResolverImpl.findMailAddressFor determines the email address of the user by finding all builds a user has committed to. This is done by iterating over every single Jenkins project (hudson.model.User.getProjects() first finds all projects and then uses AbstractProject.hasParticipant - which reads the changelog to see if the user participated).For a large system (we have tens of thousands of builds), this is not at all efficient. Unfortunately findMailAddressFor takes a user and not a project (as the obvious implementation would be to work out the email address from the commit). Also, the results aren't cached and so this is run for every user every time. I'm not sure if this can be resolved with just a fix to the subversion-plugin 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-16389) Emailing users at the end of a failed build very slow for big Jenkins instance using CVS
kutzi updated JENKINS-16389 Emailing users at the end of a failed build very slow for big Jenkins instance using CVS Change By: kutzi (17/Jan/13 12:37 PM) Description: At the end of a failing build, the hudson.tasks.MailSender.buildCulpritList determines who to email. The problem comes when hudson.scm. SubversionMailAddressResolverImpl MailAddressResolverImpl .findMailAddressFor determines the email address of the user by finding all builds a user has committed to. This is done by iterating over every single Jenkins project (hudson.model.User.getProjects() first finds all projects and then uses AbstractProject.hasParticipant - which reads the changelog to see if the user participated).For a large system (we have tens of thousands of builds), this is not at all efficient. Unfortunately findMailAddressFor takes a user and not a project (as the obvious implementation would be to work out the email address from the commit). Also, the results aren't cached and so this is run for every user every time. I'm not sure if this can be resolved with just a fix to the subversion-plugin 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-16389) Emailing users at the end of a failed build very slow for big Jenkins instance using CVS
kutzi created JENKINS-16389 Emailing users at the end of a failed build very slow for big Jenkins instance using CVS Issue Type: Bug Affects Versions: current Assignee: kutzi Components: subversion Created: 17/Jan/13 12:36 PM Description: At the end of a failing build, the hudson.tasks.MailSender.buildCulpritList determines who to email. The problem comes when hudson.scm.SubversionMailAddressResolverImpl.findMailAddressFor determines the email address of the user by finding all builds a user has committed to. This is done by iterating over every single Jenkins project (hudson.model.User.getProjects() first finds all projects and then uses AbstractProject.hasParticipant - which reads the changelog to see if the user participated). For a large system (we have tens of thousands of builds), this is not at all efficient. Unfortunately findMailAddressFor takes a user and not a project (as the obvious implementation would be to work out the email address from the commit). Also, the results aren't cached and so this is run for every user every time. I'm not sure if this can be resolved with just a fix to the subversion-plugin Environment: Jenkins 1.447 LTS Subversion 1.35 Although both Jenkins and subversion plugin are not latest version, I have browsed github for latest versions and I believe this issue to still be present. Project: Jenkins Labels: performance Priority: Minor Reporter: kutzi 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-16389) Emailing users at the end of a failed build very slow for big Jenkins instance using CVS
kutzi updated JENKINS-16389 Emailing users at the end of a failed build very slow for big Jenkins instance using CVS Change By: kutzi (17/Jan/13 12:37 PM) Environment: Jenkins 1.447 LTS Subversion 1.35Although both Jenkins and subversion plugin are not latest version, I have browsed github for latest versions and I believe this issue to still be present. Component/s: cvs Component/s: subversion 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-15440) Emailing users at the end of a failed build very slow for big Jenkins instance using subversion
kutzi commented on JENKINS-15440 Emailing users at the end of a failed build very slow for big Jenkins instance using subversion This just completely killed our server, because this also seems to be triggered by requests to //job/JOBNAME/api/json I have to figure out where these request come from, but generally I think that this resolving 'feature' is after all a very bad idea. I'd really like to remove it altogether as I cannot really think of any scenario where this would have been actually useful (given the legacy state of the previously used hard-coded svn repositories) 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-15440) Emailing users at the end of a failed build very slow for big Jenkins instance using subversion
kutzi commented on JENKINS-15440 Emailing users at the end of a failed build very slow for big Jenkins instance using subversion Note that the same applies for the cvs-plugin which still - AFAIK - comes preinstalled with Jenkins. So just fixing this for svn doesn't help as long as cvs-plugin is enabled 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-16373) email-ext can't access SVN_REVISION_1
Slide-O-Mix resolved JENKINS-16373 as Not A Defect email-ext can't access SVN_REVISION_1 Change By: Slide-O-Mix (17/Jan/13 12:30 PM) Status: Open Resolved Resolution: Not A Defect 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-16234) Plugin does not currently work for Clearcase Base
SCM/JIRA link daemon commented on JENKINS-16234 Plugin does not currently work for Clearcase Base Code changed in jenkins User: Vincent Latombe Path: src/main/java/hudson/plugins/clearcase/AbstractClearCaseScm.java src/main/java/hudson/plugins/clearcase/ClearCaseInstallation.java src/main/java/hudson/plugins/clearcase/ClearCaseSCM.java src/main/java/hudson/plugins/clearcase/ClearCaseUcmSCM.java src/main/java/hudson/plugins/clearcase/ClearToolExec.java src/main/java/hudson/plugins/clearcase/MkViewParameters.java src/main/java/hudson/plugins/clearcase/PluginImpl.java src/main/java/hudson/plugins/clearcase/viewstorage/DefaultViewStorage.java src/main/java/hudson/plugins/clearcase/viewstorage/ServerViewStorage.java src/main/java/hudson/plugins/clearcase/viewstorage/SpecificViewStorage.java src/main/java/hudson/plugins/clearcase/viewstorage/ViewStorage.java src/main/java/hudson/plugins/clearcase/viewstorage/ViewStorageDescriptor.java src/main/java/hudson/plugins/clearcase/viewstorage/ViewStorageFactory.java src/main/resources/hudson/plugins/clearcase/AbstractClearcaseScm/help-overrideViewStorage.html src/main/resources/hudson/plugins/clearcase/AbstractClearcaseScm/help-viewStorage.html src/main/resources/hudson/plugins/clearcase/AbstractClearcaseScm/overrideViewStorage.jelly src/main/resources/hudson/plugins/clearcase/ClearCaseInstallation/global.jelly src/main/resources/hudson/plugins/clearcase/ClearCaseInstallation/help-defaultViewStorage.html src/main/resources/hudson/plugins/clearcase/ClearCaseSCM/config.jelly src/main/resources/hudson/plugins/clearcase/ClearCaseUcmSCM/config.jelly src/main/resources/hudson/plugins/clearcase/viewstorage/ServerViewStorage/config.jelly src/main/resources/hudson/plugins/clearcase/viewstorage/ServerViewStorage/help-assignedLabelString.html src/main/resources/hudson/plugins/clearcase/viewstorage/ServerViewStorage/help-server.html src/main/resources/hudson/plugins/clearcase/viewstorage/SpecificViewStorage/config.jelly src/main/resources/hudson/plugins/clearcase/viewstorage/ViewStorage/config.jelly src/test/java/hudson/plugins/clearcase/ClearCaseSCMDummy.java src/test/java/hudson/plugins/clearcase/ClearCaseSCMTest.java src/test/java/hudson/plugins/clearcase/viewstorage/DefaultViewStorageTest.java src/test/java/hudson/plugins/clearcase/viewstorage/ServerViewStorageTest.java src/test/java/hudson/plugins/clearcase/viewstorage/SpecificViewStorageTest.java http://jenkins-ci.org/commit/clearcase-plugin/2c5413b2782250aaa2a56db254a7d7d5998fd1ec Log: Merge pull request #19 from jenkinsci/JENKINS-16234 [Jenkins 16234] Support no argument for View Location in mkview Compare: https://github.com/jenkinsci/clearcase-plugin/compare/7a9db8216496...2c5413b27822 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-15920) Boolean parameter becomes string
cjo9900 assigned JENKINS-15920 to cjo9900 Boolean parameter becomes string Change By: cjo9900 (17/Jan/13 12:00 PM) Assignee: huybrechts cjo9900 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-15920) Boolean parameter becomes string
cjo9900 commented on JENKINS-15920 Boolean parameter becomes string Added pull request for boolean parameters https://github.com/jenkinsci/parameterized-trigger-plugin/pull/32 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-16125) Variables cannot be resolved in "Projects to build" field when trigger is a post-build action
cjo9900 commented on JENKINS-16125 Variables cannot be resolved in "Projects to build" field when trigger is a post-build action I think you have hit the issue that has already been fixed in commit https://github.com/jenkinsci/parameterized-trigger-plugin/commit/16586248c382ef417e0aaa1d2cdb00baee87ec18 which has not yet been released. Where the Environment variables are not correct, due to using the Dependancy Graph to trigger the downstream builds which always runs on master therefore does not get the correct env variables. 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-16125) Variables cannot be resolved in "Projects to build" field when trigger is a post-build action
cjo9900 assigned JENKINS-16125 to cjo9900 Variables cannot be resolved in "Projects to build" field when trigger is a post-build action Change By: cjo9900 (17/Jan/13 11:58 AM) Assignee: huybrechts cjo9900 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-16369) Matrix job triggers job multiple times
cjo9900 commented on JENKINS-16369 Matrix job triggers job multiple times I assume that this is using the trigger other projects build step within the matrix job. In this case the build step is run for every configuration that the main project is configured for, as each environment is different and have the different axis values which can be used to trigger other projects with these parameters. So is working as expected in this case. However to trigger the both matrix jobs only once have a upstream job of both matrix jobs and trigger them both from that, and setup parameters in that, passed to both jobs. i.e. Matrix_trigger -> matrix_1 \> matrix_2 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-16388) Regarding SVN_REVISION_1 and SVN_URL_1
Eric Brito commented on JENKINS-16388 Regarding SVN_REVISION_1 and SVN_URL_1 The second thing is working, ignore 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-16373) email-ext can't access SVN_REVISION_1
Eric Brito
commented on JENKINS-16373
email-ext can't access SVN_REVISION_1
Actually, ${ENV, var="SVN_REVISION_1"} DOES work. I was aborting the project in order to force the email SVN_REVISION_1 was never created. Sorry for wasting your time.
But if you do have some time, I still haven't been able to use these correctly (email has all these lines, none seem to be working):
${CHANGES, showPaths="true", format="%a: %r %p \n--\ %m\", pathFormat="\n\t- %p"}
${CHANGES, showPaths="true", format="%a: %r %p %m\", pathFormat="\t%p\n"}
${CHANGES, showPaths="true", showDependencies="false", format="%a: %r %p \n--\"%m\", pathFormat="\n\t- %p"}
${CHANGES, "true", "false", "%a: %r %p \n--\ %m\", "\n\t- %p"}
${CHANGES, "true", "true", "%a: %r %p %m\", "\n\t- %p"}
${BUILD_LOG_MULTILINE_REGEX, "error", "10", "true", null, "false", null}
${BUILD_LOG_MULTILINE_REGEX, "error", "10", "true"}
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-16384) Blocking on downstream projects
cjo9900 commented on JENKINS-16384 Blocking on downstream projects Can you add the config.xml files from the 4 jobs, in particular the ... section. And as the jobs are separate and there is no actual lick between them other than the upstream/downstream relationship there is no cause to prevent the jobs from running at the same time unless that advanced option is enabled. See Advanced section in project A config and enable the block when downstream is building item and see if that fixes the 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
