[JIRA] (JENKINS-15228) Impossible to kill job run by dist-fork
Alex Vesely created JENKINS-15228 Impossible to kill job run by dist-fork Issue Type: Bug Assignee: Unassigned Components: distfork Created: 19/Sep/12 6:30 AM Description: The only way to kill a job run by dist-fork is to press the red 'X' button in Jenkins. The functionality to abort the job from the script that started it is missing. Is you kill (or terminate) the java process that called dist-fork (java -jar jenkins-cli.jar ... dist-fork proc.sh), the job will continue to execute on Jenkins. Environment: SLES 10 Project: Jenkins Priority: Major Reporter: Alex Vesely 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-13614) archiving artefacts from remote MacOS X, IBM AIX slave fails
Chris Graham commented on JENKINS-13614 archiving artefacts from remote MacOS X, IBM AIX slave fails Clearly this is not a slave issue, as it occurs on my master (I have no slaves). It is a host OS issue and this issue, which appears to be the 'master' issue for all of the duplicates. I would suggest that the simplest fix is to check for the existance of the readlink command and use it if available, otherwise revery to the old functionality. Or, find yet another approach. This is a critical issue as it causes good builds to be listed as failed. 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-15227) changelog.xml is NOT a xml style file
Sayid Ma
updated JENKINS-15227
changelog.xml is NOT a xml style file
Change By:
Sayid Ma
(19/Sep/12 4:16 AM)
Description:
Afer using GIT plugin, the changelog.xml under jobs/job_name/date_time/ is as text/plain style file not a xml style file which leads to interpretion issue by using a jelly script to publish the git commits logs
CHANGES ${spc}Revision ${cs.revision} by ${aUser.displayName}: ${cs.user}: (${cs.msgAnnotated}) ${spc}${p.editType.name} ${p.value}No Changes email display: Revision 1127083ecf3db6518d6788c746ae082e8bf50447 by :(modify 9 files for testing) edit edit edit edit edit edit edit edit edit
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-8618) would like to use one instance per build
John Dyer commented on JENKINS-8618 would like to use one instance per build I actually would like this as well, but I havnt been able to figure out how to do it. Right now I have Jenkins creating an instance with a single executor and I start Job1 which is taged to run on that new node. I then start Job2 which is taged to start on the same slave but it seems to wait for that executor on the first slave to finish. How can I make it scale up another slave for Job2? 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-15024) Inline authentication prevents incremental updates
Jesse Glick resolved JENKINS-15024 as Not A Defect Inline authentication prevents incremental updates Unfortunately if you clone https://username:passw...@repository.com your .hg/hgrc in the workspace will be just [paths] default = https://usern...@repository.com meaning that a subsequent hg pull from the plugin will prompt for a password (and fail since it is run noninteractively). So while it may be annoying to have your workspace checked out anew, this is better than not being able to update at all. Of course nicest would be to somehow integrate with the Credentials plugin so that you could store your password securely on Jenkins master, transmitting it to the slave just long enough to be passed somehow to pull and other commands, perhaps using a masked --config auth.something.password=… parameter. But this is a matter for a separate, and broader, RFE. In the meantime the best bet is to preconfigure authentication on those nodes which will be running Mercurial commands. Change By: Jesse Glick (19/Sep/12 3:27 AM) Status: In Progress 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-15024) Inline authentication prevents incremental updates
Jesse Glick started work on JENKINS-15024 Inline authentication prevents incremental updates Change By: Jesse Glick (19/Sep/12 3:17 AM) 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-15024) Inline authentication prevents incremental updates
Jesse Glick assigned JENKINS-15024 to Jesse Glick Inline authentication prevents incremental updates Change By: Jesse Glick (19/Sep/12 3:13 AM) Assignee: Kohsuke Kawaguchi Jesse Glick 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-15227) changelog.xml is NOT a xml style file
Sayid Ma created JENKINS-15227 changelog.xml is NOT a xml style file Issue Type: Bug Affects Versions: current Assignee: Alan Harder Components: changelog-history, git Created: 19/Sep/12 2:40 AM Description: Afer using GIT plugin, the changelog.xml under jobs/job_name/date_time/ is as text/plain style file not a xml style file which leads to interpretion issue by using a jelly script to publish the git commits logs Project: Jenkins Priority: Critical Reporter: Sayid Ma 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-15024) Inline authentication prevents incremental updates
cowwoc commented on JENKINS-15024 Inline authentication prevents incremental updates Alexandre, See http://www.selenic.com/mercurial/hgrc.5.html#auth for a simple workaround (but yes, this should be fixed in Jenkins because this approach makes it clustering harder). 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-15226) Log recorders do not work reliably
dogfood commented on JENKINS-15226 Log recorders do not work reliably Integrated in jenkins_main_trunk #1937 [FIXED JENKINS-15226] Log recorders do not work reliably. (Revision f9583b89c47833b86c1d3b88c0515d0adfd69192) Result = SUCCESS Jesse Glick : f9583b89c47833b86c1d3b88c0515d0adfd69192 Files : core/src/main/java/hudson/logging/LogRecorder.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-15184) Naginator Plugin will not retry upon test failure
markewaite commented on JENKINS-15184 Naginator Plugin will not retry upon test failure Refer to http://jenkins.361315.n4.nabble.com/retry-build-upon-failure-td4640190.html for a possible root cause of this problem. That report states that if the defaults are not modified in the definition of the retry (no default time is set, no delay offset), then a null pointer exception is written to jenkins.log (at least on a Debian 64 bit stable operating system with a newly installed Jenkins 1.466.2 and the most recent Naginator 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-15226) Log recorders do not work reliably
SCM/JIRA link daemon commented on JENKINS-15226 Log recorders do not work reliably Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/java/hudson/logging/LogRecorder.java http://jenkins-ci.org/commit/jenkins/f9583b89c47833b86c1d3b88c0515d0adfd69192 Log: [FIXED JENKINS-15226] Log recorders do not work reliably. 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-15226) Log recorders do not work reliably
SCM/JIRA link daemon resolved JENKINS-15226 as Fixed Log recorders do not work reliably Change By: SCM/JIRA link daemon (19/Sep/12 12:52 AM) 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-15226) Log recorders do not work reliably
Jesse Glick created JENKINS-15226 Log recorders do not work reliably Issue Type: Bug Assignee: Unassigned Components: core Created: 19/Sep/12 12:50 AM Description: Seems that http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6274920 is causing log messages to be sent only erratically, depending on the whims of the garbage collector. Project: Jenkins Labels: logging Priority: Major Reporter: Jesse Glick 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-15206) Displaying /people can consume huge resources
Jesse Glick commented on JENKINS-15206 Displaying /people can consume huge resources https://github.com/jenkinsci/jenkins/pull/570 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-5714) Additional options for tfs plugin such as overwrite and forced
Kyle O'Connor
edited a comment on JENKINS-5714
Additional options for tfs plugin such as overwrite and forced
Yes, when you are doing a incremental get ("use update" is checked for this plugin) and you specify "/overwrite" and "/force", it ceases to be an incremental get at that point. Just "/overwrite" may be okay to fix OP's problem but "/force" will cause all files to be retrieved not just the changed files. So we definitely cannot use "/overwrite" and "/force" options in conjunction with "use update".
@OP, it sounds like you need to run a clean first if you are going to use incremental check outs. If you find yourself marking your source-files as not read-only then you will have problems because TFS relies on that flag to function properly.
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-5714) Additional options for tfs plugin such as overwrite and forced
Kyle O'Connor
commented on JENKINS-5714
Additional options for tfs plugin such as overwrite and forced
Yes, when you are doing a incremental get ("use update" is checked for this plugin) and you specify "/overwrite" and "/force", it ceases to be an incremental get at that point. Just "/overwrite" may be okay to fix OP's problem but "/force" will cause all files to be retrieved not just the changed files. So we definitely cannot use "/overwrite" and "/force" options in conjunction with "use update".
@OP, it sounds like you need to run a clean first if you are doing to use incremental check outs. If you find yourself marking your source-files as not read-only then you will have problems because TFS relies on that flag to function properly.
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-4709) Add exclusion regions in TFS polling and checkout
Kyle O'Connor edited a comment on JENKINS-4709 Add exclusion regions in TFS polling and checkout I don't think the patch based on the SVN impl is the way to go. This needs to be implemented using TFS "cloaking". See here: http://msdn.microsoft.com/en-us/library/ms181378(v=vs.100).aspx The Jenkins TFS SCM plugin configuration page should simply ask for a list of folders (TFS Server paths) you want to be excluded from the SCM checkout and then run the tf workfold /cloak command on this folder list. It only has to be run once when the workspace is initially created (unless the configuration changes, but since this plugin already supports recreating the workspace in that case, you would also just make the call to cloak all folders again at that point). See here for the command syntax: http://msdn.microsoft.com/en-us/library/0fa04bx6(v=vs.100).aspx This should be pretty simple to implement. Let me know if there are other questions about TFS SCM. 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-4709) Add exclusion regions in TFS polling and checkout
Kyle O'Connor commented on JENKINS-4709 Add exclusion regions in TFS polling and checkout I don't think the patch based on the SVN impl is the way to go. This needs to be implemented using TFS "cloaking". See here: http://msdn.microsoft.com/en-us/library/ms181378(v=vs.100).aspx The Jenkins TFS SCM plugin configuration page should simply ask for a list of folders (TFS Server paths) you want to be excluded from the SCM checkout and then run the tf workfold /cloak command on this folder list. It only has to be run once when the workspace is initially created (unless the configuration changes, but since this plugin already supports recreating the workspace in that case, you would also just make the call to cloak all folders again at that point). See here for the command syntax: http://msdn.microsoft.com/en-us/library/0fa04bx6(v=vs.100).aspx Let me know if there are other questions about TFS SCM. 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-9608) NPE when computing build results in NumBuildsStatsBuilder
Kyle O'Connor closed JENKINS-9608 as Duplicate NPE when computing build results in NumBuildsStatsBuilder Change By: Kyle O'Connor (18/Sep/12 9:32 PM) Status: Reopened Closed Resolution: Duplicate This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14935) NPE when computing number of builds for column display in NumBuildsStats
Kyle O'Connor closed JENKINS-14935 as Duplicate NPE when computing number of builds for column display in NumBuildsStats Change By: Kyle O'Connor (18/Sep/12 9:32 PM) Status: Open Closed Resolution: Duplicate This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15225) The failing test age counters should ignore "grey" builds
Eugene Panaitov updated JENKINS-15225 The failing test age counters should ignore "grey" builds Change By: Eugene Panaitov (18/Sep/12 9:31 PM) Description: The age of a failing test is very useful for tracking changes that caused the bug. The problem with the age value is that the start point of bug lifespan is counted from the latests * successful completed * build.Very often builds fail for that or another reason (build icon is grey) which resets all the ages.My proposal is to make the age function ignore faulty and interrupted builds and continue incrementing ages with every completed build.It will look likebuild 1 (completed) - age 1build 2 (completed) - age 2build 3 (failed, slave ran out of memory) - age is still 2build 4 (completed) - age 3.build 5 (interrupted) - age is still 3.build 6 (completed) - age 4.It does not sound difficult to fix. Unfortunately the only way that I found to fix this is to contribute to jenkins code and re-compile it for our environment. Am I right about that or there's a shorter path? 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-15067) NullPointerException using project-stats-plugin
Kyle O'Connor updated JENKINS-15067 NullPointerException using project-stats-plugin I can confirm that the problem exists in the latest version of project-stats-plugin because it does not check if the job is currently building before trying to access number of build results. Change By: Kyle O'Connor (18/Sep/12 9:29 PM) Assignee: Marco Ambu Affects Version/s: current 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-9608) NPE when computing build results in NumBuildsStatsBuilder
Kyle O'Connor updated JENKINS-9608 NPE when computing build results in NumBuildsStatsBuilder Problem is in latest project-stats-plugin because it does not check if the job is currently building before trying to access number of build results. Change By: Kyle O'Connor (18/Sep/12 9:25 PM) Priority: Critical Major Component/s: project-stats Component/s: dashboard-view 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-14935) NPE when computing number of builds for column display in NumBuildsStats
Kyle O'Connor updated JENKINS-14935 NPE when computing number of builds for column display in NumBuildsStats Problem is in latest project-stats-plugin because it does not check if the job is currently building before trying to access number of build results. Change By: Kyle O'Connor (18/Sep/12 9:26 PM) Component/s: dashboard-view 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-14787) Perforce plugin does not substitute all variables when polling for new changes
Richard Lee commented on JENKINS-14787 Perforce plugin does not substitute all variables when polling for new changes Discussed in another bug, but in case others have run into this issue, P4PASSWD also does not currently appear to be substituted during polling. 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-15224) Commit messages are not configurable and do not accept user input
Seth Goings closed JENKINS-15224 as Duplicate Commit messages are not configurable and do not accept user input Opened: https://issues.jfrog.org/jira/browse/HAP-341 Change By: Seth Goings (18/Sep/12 9:13 PM) Status: Open Closed Assignee: yossis Seth Goings Resolution: Duplicate This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15225) The failing test age counters should ignore "grey" builds
Eugene Panaitov created JENKINS-15225 The failing test age counters should ignore "grey" builds Issue Type: Improvement Assignee: stephenconnolly Components: cobertura, junit Created: 18/Sep/12 9:12 PM Description: The age of a failing test is very useful for tracking changes that caused the bug. The problem with the age value is that the start point of bug lifespan is counted from the latests successful build. Very often builds fail for that or another reason (build icon is grey) which resets all the ages. My proposal is to make the age function ignore faulty and interrupted builds and continue incrementing ages with every completed build. It will look like build 1 (completed) - age 1 build 2 (completed) - age 2 build 3 (failed, slave ran out of memory) - age is still 2 build 4 (completed) - age 3. build 5 (interrupted) - age is still 3. build 6 (completed) - age 4. It does not sound difficult to fix. Unfortunately the only way that I found to fix this is to contribute to jenkins code and re-compile it for our environment. Am I right about that or there's a shorter path? Due Date: 18/Dec/12 12:00 AM Project: Jenkins Priority: Major Reporter: Eugene Panaitov 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-11786) Could we use masked password variable in Perforce Depot->Password
Rob Petti commented on JENKINS-11786 Could we use masked password variable in Perforce Depot->Password JENKINS-14787 covers this. I've got a branch with experimental changes that might resolve the issue, but I haven't had the chance to test it yet. 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-14969) Perforce / Source Code Plugin Doesn't Perform Variable Expansion on Environment Variable When Evaluating if Workspace Exists
Rob Petti assigned JENKINS-14969 to Unassigned Perforce / Source Code Plugin Doesn't Perform Variable Expansion on Environment Variable When Evaluating if Workspace Exists Change By: Rob Petti (18/Sep/12 9:08 PM) Assignee: Rob Petti 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-15209) Only update perforce label if it's not locked.
Rob Petti commented on JENKINS-15209 Only update perforce label if it's not locked. What use would an option for this be? You can't update the label if it's locked, so maybe the plugin should just not attempt to update locked labels at all. 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-11786) Could we use masked password variable in Perforce Depot->Password
Richard Lee commented on JENKINS-11786 Could we use masked password variable in Perforce Depot->Password Ah.. I must have overlooked that. Is there a bug on that I can follow? Or should I file a new one? 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-11786) Could we use masked password variable in Perforce Depot->Password
Rob Petti commented on JENKINS-11786 Could we use masked password variable in Perforce Depot->Password Yes, I did mention above that I wasn't 100% sure it worked for polling. 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-11786) Could we use masked password variable in Perforce Depot->Password
Richard Lee commented on JENKINS-11786 Could we use masked password variable in Perforce Depot->Password Hmmm-ier. If I force the job to build (i.e. not from polling), it succeeds. I think there's something in the perforce polling step that is not pulling the password from masked password global variables? After the forced build succeeds, the perforce ticket is valid for some period of time and so the polling step succeeds from there on out because it doesn't need the password: Perforce Polling Log Started on Sep 18, 2012 1:43:51 PM Looking for changes... Using node: Jenkins Using master perforce client: rdlee-interlaken-jenkins-iris-mainline-dev-flash_as3 [jenkins] $ /usr/local/bin/p4 workspace -o rdlee-interlaken-jenkins-iris-mainline-dev-flash_as3 [jenkins] $ /usr/local/bin/p4 counter change [jenkins] $ /usr/local/bin/p4 -s changes -s submitted //rdlee-interlaken-jenkins-iris-mainline-dev-flash_as3/...@596624,@596654 No changes found. Done. Took 0.64 sec No 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-11786) Could we use masked password variable in Perforce Depot->Password
Richard Lee commented on JENKINS-11786 Could we use masked password variable in Perforce Depot->Password Huh... well, the password printed by the groovy script is definitely correct, and if I cut-n-paste it into a shell window to log in to perforce, it works, so don't think it's the perforce server. It's failing very early, in perforce polling before the job is even run: Perforce Polling Log Started on Sep 18, 2012 1:37:51 PM Looking for changes... Using node: Jenkins Using master perforce client: rdlee-interlaken-jenkins-iris-mainline-dev-flash_as3 [jenkins] $ /usr/local/bin/p4 workspace -o rdlee-interlaken-jenkins-iris-mainline-dev-flash_as3 [jenkins] $ /usr/local/bin/p4 login -p [jenkins] $ /usr/bin/p4 login -p Caught Exception communicating with perforce.Login attempt failed: Password invalid. FATAL: Unable to communicate with perforce. Check log file for: Login attempt failed: Password invalid. java.io.IOException: Unable to communicate with perforce. Check log file for: Login attempt failed: Password invalid. at hudson.plugins.perforce.PerforceSCM.compareRemoteRevisionWith(PerforceSCM.java:1169) at hudson.scm.SCM._compareRemoteRevisionWith(SCM.java:356) at hudson.scm.SCM.poll(SCM.java:373) at hudson.model.AbstractProject._poll(AbstractProject.java:1415) at hudson.model.AbstractProject.poll(AbstractProject.java:1335) 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:619) Done. Took 1.9 sec No 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-15201) Add support for the track-origins valgrind option
Johannes Ohlemacher resolved JENKINS-15201 as Fixed Add support for the track-origins valgrind option Thanks. I added support for those auxiliary information (and for --track-origin option) with version 0.15. Each element can be followed by a complete stacktrace (with multiple stack frames) and is displayed individually after the regular stacktrace. A summary of the auxiliary information (just the messages, no stacktraces) is shown at the top of the page. Change By: Johannes Ohlemacher (18/Sep/12 8:39 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-15173) Valgrind plugin "Valgrind Results" link on project root page does not always link to the most recent build
Johannes Ohlemacher resolved JENKINS-15173 as Fixed Valgrind plugin "Valgrind Results" link on project root page does not always link to the most recent build fixed with version 0.15 "Valgrind Result" links to the most recent build that has valid valgrind results Change By: Johannes Ohlemacher (18/Sep/12 8:32 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-11786) Could we use masked password variable in Perforce Depot->Password
Rob Petti commented on JENKINS-11786 Could we use masked password variable in Perforce Depot->Password The groovy provided above calls the exact same function that's used to get the password. If the password being used is being rejected, then it's likely the fault of the perforce server. It's also not a load order issue, because the perforce plugin specifically looks for global properties to use for substitution. 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-11786) Could we use masked password variable in Perforce Depot->Password
Richard Lee commented on JENKINS-11786 Could we use masked password variable in Perforce Depot->Password Hmm... I'm still having periodic problems with this. I get it working for a while, but then when I change the global perforce password, it then starts failing again. Running the groovy script shows that it is getting the correct password, but the perforce server disagrees. Could this be due to some plugin load ordering 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-15222) FTP Publisher broken for concurrent builds
Axel Heider updated JENKINS-15222 FTP Publisher broken for concurrent builds Change By: Axel Heider (18/Sep/12 7:23 PM) Description: Job confinuration [x] "Execute concurrent builds if necessary" Restrict where this project can be run: MyNode Post Build: Send build artifacts over FTP "*.tar.bz2"The "Send build artifacts over FTP" postbuild-step appears to be broken with concurrent builds. It appears to waits until all concurrent builds are done before any FTP upload happens. However, wthe the workspace can be overwritten by another concurrent build, so the wrong data gets uploaded. See logs, below, we end up with "JOB2/JOB3.tar.bz2" on the FTP server As you can see from the logs, the postbuild step itself appear steps in general appears to be ok, as the Groovy Postbuild postbuild step happens in time, just the FtpPublisher is waiting for every concurrent build to finish before continuing Job 1: takes very long16:32:49 Building remotely on Machine1 in workspace "Test"16:32:49 this job takes very long16:43:31 done creaated JOB1.tar.bz216:43:31 Groovy Postbuild step16:43:31 Send build artifacts over FTP Step: JOB1/*.tar.bz216:43:31 Finished: SUCCESSJob 2: fast job on 2nd workspace16:32:57 Building remotely on Machine1 in workspace "Test@2"16:32:57 fast job16:33:04 done creaated JOB2.tar.bz216:33:04 Groovy Postbuild step16:43:31 Send build artifacts over FTP Step: JOB2/*.tar.bz216:43:31 Finished: SUCCESSJob 3 another fast job on the 2nd workspace16:33:05 Building remotely on Machine1 in workspace "Test@2"16:33:05 fast job on the16:33:09 done, created JOB3.tar.bz216:33:10 Groovy Postbuild step16:43:31 Send build artifacts over FTP Step JOB3/*.tar.bz216:43:32 Finished: SUCCESSOn the FTP server these files end up JOB1/JOB1.tar.bz2 JOB2/JOB3.tar.bz2 JOB3/JOB3.tar.bz2 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-15222) FTP Publisher broken for concurrent builds
Axel Heider updated JENKINS-15222 FTP Publisher broken for concurrent builds Change By: Axel Heider (18/Sep/12 7:20 PM) Summary: Concurrent Build Workspaces overlap FTP Publisher broken for concurrent builds Affects Version/s: current Environment: Linux, jenkins Jenkins 1. 461 482 Priority: Blocker 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-15222) Concurrent Build Workspaces overlap
Axel Heider commented on JENKINS-15222 Concurrent Build Workspaces overlap Update to latest Jenkins 1.482 and using the setup from JENKINS-14283 shows the same 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-7033) Job in build queue is not executed
Axel Heider closed JENKINS-7033 as Cannot Reproduce Job in build queue is not executed Change By: Axel Heider (18/Sep/12 7:17 PM) Status: Resolved Closed 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-7033) Job in build queue is not executed
Axel Heider resolved JENKINS-7033 as Cannot Reproduce Job in build queue is not executed Have not seen this for a long time now, assume it was some internal race condition that has ben resolved. Change By: Axel Heider (18/Sep/12 7:16 PM) Status: Open Resolved 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-5408) Quoting Issue with JDK Installer with Windows Slave
Jerry Qassar commented on JENKINS-5408 Quoting Issue with JDK Installer with Windows Slave Another possibility to look at would be to use /norestart rather than REBOOT=ReallySuppress. 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-14978) Maven Deployment Linker does not support 'dynamic' Project name (upstream uploader)
Larry Shatzer, Jr. assigned JENKINS-14978 to Dominik Bartholdi Maven Deployment Linker does not support 'dynamic' Project name (upstream uploader) Change By: Larry Shatzer, Jr. (18/Sep/12 6:59 PM) Assignee: Larry Shatzer, Jr. Dominik Bartholdi 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-5408) Quoting Issue with JDK Installer with Windows Slave
Jerry Qassar edited a comment on JENKINS-5408 Quoting Issue with JDK Installer with Windows Slave Mr. Kawaguchi: This problem is also occurring with JDK 7_06 (configuration: Latest Jenkins, Solaris master, Windows 7 32-bit slave). An example from console output for our build is as follows: c:\jenkins\tools\JDK\jdk-1.7.0_06\jdk.exe /s /v /qn /L \"c:\jenkins\tools\JDK\jdk-1.7.0_06\jdk.exe.install.log\" REBOOT=ReallySuppress INSTALLDIR=\"c:\jenkins\tools\JDK\jdk-1.7.0_06\" results in an msiexec dialog (which means a hung installation). Testing indicates that the INSTALLDIR property is the property which is considered invalid. By removing the escapes on the quotes and executing c:\jenkins\tools\JDK\jdk-1.7.0_06\jdk.exe /s /v /qn /L \"c:\jenkins\tools\JDK\jdk-1.7.0_06\jdk.exe.install.log\" REBOOT=ReallySuppress INSTALLDIR="c:\jenkins\tools\JDK\jdk-1.7.0_06" The install completes successfully and we can continue with the build process. (EDIT: I don't think this syntax is exactly correct, either, as I still ended up with an msiexec process hanging. /v and /qn should no longer be necessary either, and you should be able to do this entirely with: c:\jenkins\tools\JDK\jdk-1.7.0_06\jdk.exe /s /L "c:\jenkins\tools\JDK\jdk-1.7.0_06\jdk.exe.install.log" REBOOT=ReallySuppress INSTALLDIR="c:\jenkins\tools\JDK\jdk-1.7.0_06" with a potential setting of ADDLOCAL for just the source course and other necessary features.) The quote escape method used in the original comment, and the spec you mention, are relics from the very old versions of msiexec that were pushed out when JDK 1.5 was new. If you look at the new installers and the pages regarding their use, you can see that a) many of the options are no longer necessary and b) quote escaping for the setting of INSTALLDIR has not been needed for a very long time. It may still be needed for the /L parameter because of the possibility of spaces in your path, but I actually think the quotes are enough now. In any case, it seems like the single quotes have been removed from the installer call, but not the escapes. Without one, you really shouldn't need the other. 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-13127) Automatic Install blocks forever
Daniel Beck commented on JENKINS-13127 Automatic Install blocks forever Given the stack trace, it looks like your internet connection just hiccupped. It directly read (blocking) from the input stream of the file download. https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/FilePath.java#L715 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-15024) Inline authentication prevents incremental updates
Alexandre Chambriat commented on JENKINS-15024 Inline authentication prevents incremental updates Definitively a blocker issue for using this plugin. Specially when using Hg on hosted server for kind of big projects. 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-15162) Unable to archive artifacts from "JClouds Single-Use Slave"
Adam Rofer commented on JENKINS-15162 Unable to archive artifacts from "JClouds Single-Use Slave" I'm going to try https://wiki.jenkins-ci.org/display/JENKINS/Copy+To+Slave+Plugin - this looks like it does what I want above... 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-15202) Permanent building / consider removing latest changes
anb0s commented on JENKINS-15202 Permanent building / consider removing latest changes Now it's clear to me: hasNewConfigSpec() is also called for dynamic views. We're using snapshot views only. For snapshot views there is no such feature in this plugin. I readed the ClearCase docs about "time rules" now and understand how it works. Generally time rules option can be used with snapshot views too. I'm software developer and user of ClearCase. I'm also working on this in my free time and share it with our dev team. I spended a lot of time to understand how this plugin is working. Yes the main reason for my work and pull request are needed features for our wokflow: JENKINS-8305: using ClearCase plugin without config spec and load rules field (load them from files) JENKINS-8949: Provide list of folders and/or files for polling (lshistory) changeset can be generated from updt files after checkout in snapshot views My pull request introduced some fixes and new features. It was easier for me test all things together and push at once. In future i will try to make more commits, so it should easier to merge and test. Yes, feedback is always welcome to find the right way 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-5408) Quoting Issue with JDK Installer with Windows Slave
Jerry Qassar edited a comment on JENKINS-5408 Quoting Issue with JDK Installer with Windows Slave Mr. Kawaguchi: This problem is also occurring with JDK 7_06 (configuration: Latest Jenkins, Solaris master, Windows 7 32-bit slave). An example from console output for our build is as follows: c:\jenkins\tools\JDK\jdk-1.7.0_06\jdk.exe /s /v /qn /L \"c:\jenkins\tools\JDK\jdk-1.7.0_06\jdk.exe.install.log\" REBOOT=ReallySuppress INSTALLDIR=\"c:\jenkins\tools\JDK\jdk-1.7.0_06\" results in an msiexec dialog (which means a hung installation). Testing indicates that the INSTALLDIR property is the property which is considered invalid. By removing the escapes on the quotes and executing c:\jenkins\tools\JDK\jdk-1.7.0_06\jdk.exe /s /v /qn /L \"c:\jenkins\tools\JDK\jdk-1.7.0_06\jdk.exe.install.log\" REBOOT=ReallySuppress INSTALLDIR="c:\jenkins\tools\JDK\jdk-1.7.0_06" The install completes successfully and we can continue with the build process. I understand your desire to conform to the JDK instructions, but the fact of the matter is that Oracle changes their installer methodology--often. The quote escape method used in the original comment, and the spec you mention, are relics from the very old versions of msiexec that were pushed out when JDK 1.5 was new. If you look at the new installers and the pages regarding their use, you can see that a) many of the options are no longer necessary and b) quote escaping for the setting of INSTALLDIR has not been needed for a very long time. It may still be needed for the /L parameter because of the possibility of spaces in your path, but I actually think the quotes are enough now. In any case, it seems like the single quotes have been removed from the installer call, but not the escapes. Without one, you really shouldn't need the other. 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-5408) Quoting Issue with JDK Installer with Windows Slave
Jerry Qassar commented on JENKINS-5408 Quoting Issue with JDK Installer with Windows Slave Mr. Kawaguchi: This problem is also occurring with JDK 7_06 (configuration: Latest Jenkins, Solaris master, Windows 7 32-bit slave). An example from console output for our build is as follows: c:\jenkins\tools\JDK\jdk-1.7.0_06\jdk.exe /s /v /qn /L \"c:\jenkins\tools\JDK\jdk-1.7.0_06\jdk.exe.install.log\" REBOOT=ReallySuppress INSTALLDIR=\"c:\jenkins\tools\JDK\jdk-1.7.0_06\" results in an msiexec dialog (which means a hung installation). Testing indicates that the INSTALLDIR property is the property which is considered invalid. By removing the escapes on the quotes and executing c:\jenkins\tools\JDK\jdk-1.7.0_06\jdk.exe /s /v /qn /L \"c:\jenkins\tools\JDK\jdk-1.7.0_06\jdk.exe.install.log\" REBOOT=ReallySuppress INSTALLDIR="c:\jenkins\tools\JDK\jdk-1.7.0_06" The install completes successfully and we can continue with the build process. I understand your desire to conform to the JDK instructions, but the fact of the matter is that Oracle changes their installer methodology--often. The quote escape method used in the original comment, and the spec you mention, are relics from the very old versions of msiexec that were pushed out when JDK 1.5 was new. If you look at the new installers and the pages regarding their use, you can see that a) many of the options are no longer necessary and b) quote escaping has not been needed for a very long time. In any case, it seems like the single quotes have been removed from the installer call, but not the escapes. Without one, you really shouldn't need the other. 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-15224) Commit messages are not configurable and do not accept user input
Seth Goings updated JENKINS-15224 Commit messages are not configurable and do not accept user input Change By: Seth Goings (18/Sep/12 5:33 PM) Description: In my environment we use git hooks to make sure that commit messages contain JIRA issues... however, I found that the artifactory release plugin doesn't accept my changes to the commit messages (either tag/branch creation, or next version comment).You can see in Screen1.png I specify commit messages:EI-1040: blah blahBut in Screen2.png, the commit is denied by our git hook due to the lack of a JIRA issue. [artifactory-release] Release version 1.0.0 is the actual commit message.Besides this fact, it would be nice if I could specify a default commit message (or template) that would auto populate these commit messages for me without having to edit them when I'm actually staging a 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-15224) Commit messages are not configurable and do not accept user input
Seth Goings updated JENKINS-15224 Commit messages are not configurable and do not accept user input Change By: Seth Goings (18/Sep/12 5:33 PM) Description: In my environment we use git hooks to make sure that commit messages contain JIRA issues... however, I found that the artifactory release plugin doesn't accept my changes to the commit messages (either tag/branch creation, or next version comment).You can see in Screen1.png I specify commit messages:EI-1040: blah blahBut in Screen2.png, the commit is denied by our git hook due to the lack of a JIRA issue . [artifactory-release] Release version 1.0.0 is the actual commit message. Besides this fact, it would be nice if I could specify a default commit message (or template) that would auto populate these commit messages for me without having to edit them when I'm actually staging a 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-15224) Commit messages are not configurable and do not accept user input
Seth Goings created JENKINS-15224 Commit messages are not configurable and do not accept user input Issue Type: Bug Assignee: yossis Attachments: Screen1.png, Screen2.png Components: artifactory Created: 18/Sep/12 5:29 PM Description: In my environment we use git hooks to make sure that commit messages contain JIRA issues... however, I found that the artifactory release plugin doesn't accept my changes to the commit messages (either tag/branch creation, or next version comment). You can see in Screen1.png I specify commit messages: EI-1040: blah blah But in Screen2.png, the commit is denied by our git hook. Besides this fact, it would be nice if I could specify a default commit message (or template) that would auto populate these commit messages for me without having to edit them when I'm actually staging a release. Project: Jenkins Priority: Major Reporter: Seth Goings 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-7214) FilePath.validateAntFileMask too slow for /configure
Jesse Glick assigned JENKINS-7214 to Jesse Glick FilePath.validateAntFileMask too slow for /configure Change By: Jesse Glick (18/Sep/12 5:18 PM) Assignee: Jesse Glick 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-15206) Displaying /people can consume huge resources
Jesse Glick started work on JENKINS-15206 Displaying /people can consume huge resources Change By: Jesse Glick (18/Sep/12 5:18 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-15223) One user can overwhelm jenkins via ArtifactArchiver.doCheckArtifacts()
Jesse Glick resolved JENKINS-15223 as Duplicate One user can overwhelm jenkins via ArtifactArchiver.doCheckArtifacts() Change By: Jesse Glick (18/Sep/12 5:15 PM) Status: Open Resolved Resolution: Duplicate This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15223) One user can overwhelm jenkins via ArtifactArchiver.doCheckArtifacts()
recampbell created JENKINS-15223 One user can overwhelm jenkins via ArtifactArchiver.doCheckArtifacts() Issue Type: Bug Assignee: Unassigned Components: core Created: 18/Sep/12 4:39 PM Description: If a job has a very large workspace, and a very permissive artifact _expression_ (like */.jar), a user can single handledly bring down a Jenkins instance by tabbing in and out of the artifact field. Each time the user tabs out of the field, Jenkins does an ajax post, resultining in a recursive search of the filesystem. Jenkins should be smart enough to cancel previous ajax requests for validating the artifact glob _expression_, or use some other approach to prevent the entire system from going down. Project: Jenkins Priority: Major Reporter: recampbell 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-15176) Changelog not posted for 1.466.2 release
Jesse Glick assigned JENKINS-15176 to Kohsuke Kawaguchi Changelog not posted for 1.466.2 release Change By: Jesse Glick (18/Sep/12 4:27 PM) Assignee: 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-15214) Triggered build correctly receives git tag parameter but doesn't use it at all
William Ghelfi closed JENKINS-15214 as Not A Defect Triggered build correctly receives git tag parameter but doesn't use it at all invalid Change By: William Ghelfi (18/Sep/12 4:16 PM) Status: Resolved Closed 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-15222) Concurrent Build Workspaces overlap
Axel Heider updated JENKINS-15222 Concurrent Build Workspaces overlap Change By: Axel Heider (18/Sep/12 4:13 PM) Component/s: publish-over-ftp 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-15222) Concurrent Build Workspaces overlap
Axel Heider commented on JENKINS-15222 Concurrent Build Workspaces overlap Seeing a similar behavior with the "Publish Over FTP Plugin" and the "FTP-Publisher 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-15220) Quiet mode for clean checkout (not using update)
Deepak Mahale commented on JENKINS-15220 Quiet mode for clean checkout (not using update) Hi again, I get more than 1.8k lines of output like the following Started by user anonymous Building in workspace C:\Program Files\Jenkins\jobs\MV_Autobuild\workspace cvs checkout -P -r TEST_BRANCH_VS2008_MV_BRANCH -d MediaViewer NCR/ImageMark/MediaViewer cvs checkout: Updating MediaViewer cvs checkout: Updating MediaViewer/Make cvs checkout: Updating MediaViewer/ant_scripts cvs checkout: Updating MediaViewer/src cvs checkout: Updating MediaViewer/src/ConfigUpdator cvs checkout: Updating MediaViewer/src/Fleet cvs checkout: Updating MediaViewer/src/Fleet/Shared cvs checkout: Updating MediaViewer/src/Fleet/mvimpflt cvs checkout: Updating MediaViewer/src/MVDbCons Is the -q flag enabled by default? If yes than should i be getting this much of output? How can i check if the command has -q or -Q enabled? Thanks & Regards Deepak 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-15221) scm_sync_configuration do not synchronize changes made on disk
Frédéric Camblor updated JENKINS-15221 scm_sync_configuration do not synchronize changes made on disk This is a regression compared to previous versions. Marking it as critical Change By: Frédéric Camblor (18/Sep/12 4:05 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-15214) Triggered build correctly receives git tag parameter but doesn't use it at all
William Ghelfi resolved JENKINS-15214 as Not A Defect Triggered build correctly receives git tag parameter but doesn't use it at all There's an issue with another plugin (see comments), thus this ticket is to be considered as "invalid" at the moment. Change By: William Ghelfi (18/Sep/12 4:02 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-15222) Concurrent Build Workspaces overlap
Axel Heider created JENKINS-15222 Concurrent Build Workspaces overlap Issue Type: Bug Assignee: benjaminjaton Components: ftppublisher Created: 18/Sep/12 3:51 PM Description: Job confinuration [x] "Execute concurrent builds if necessary" Restrict where this project can be run: MyNode Post Build: Send build artifacts over FTP "*.tar.bz2" The "Send build artifacts over FTP" postbuild-step appears to be broken with concurrent builds. It appears to waits until all concurrent builds are done before any FTP upload happens. However, wthe workspace can be overwritten by another concurrent build, so the wrong data gets uploaded. See logs, below, we end up with "JOB2/JOB3.tar.bz2" on the FTP server As you can see from the logs, the postbuild step itself appear to be ok, as the Groovy Postbuild step happens in time, just the FtpPublisher is waiting for every concurrent build Job 1: takes very long 16:32:49 Building remotely on Machine1 in workspace "Test" 16:32:49 this job takes very long 16:43:31 done creaated JOB1.tar.bz2 16:43:31 Groovy Postbuild step 16:43:31 Send build artifacts over FTP Step: JOB1/*.tar.bz2 16:43:31 Finished: SUCCESS Job 2: fast job on 2nd workspace 16:32:57 Building remotely on Machine1 in workspace "Test@2" 16:32:57 fast job 16:33:04 done creaated JOB2.tar.bz2 16:33:04 Groovy Postbuild step 16:43:31 Send build artifacts over FTP Step: JOB2/*.tar.bz2 16:43:31 Finished: SUCCESS Job 3 another fast job on the 2nd workspace 16:33:05 Building remotely on Machine1 in workspace "Test@2" 16:33:05 fast job on the 16:33:09 done, created JOB3.tar.bz2 16:33:10 Groovy Postbuild step 16:43:31 Send build artifacts over FTP Step JOB3/*.tar.bz2 16:43:32 Finished: SUCCESS On the FTP server these files end up JOB1/JOB1.tar.bz2 JOB2/JOB3.tar.bz2 JOB3/JOB3.tar.bz2 Environment: Linux, jenkins 1.461 Project: Jenkins Priority: Blocker Reporter: Axel Heider 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-15214) Triggered build correctly receives git tag parameter but doesn't use it at all
William Ghelfi commented on JENKINS-15214 Triggered build correctly receives git tag parameter but doesn't use it at all Update: There's a "parent" issue with the git parameter plugin. Stay tuned while I check if this ticket is valid at all. 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-15202) Permanent building / consider removing latest changes
Vincent Latombe commented on JENKINS-15202 Permanent building / consider removing latest changes Hello Waldek, while I understand this can be seen as frustrating, unfortunately the clearcase plugin has a lot (too many ?) of features/options (because people have a lot of different workflows using clearcase base/ucm), so making changes CAN break some previously working stuff. Hopefully as said before, the regressions that you observed hopefully can be fixed quite easily without breaking the new features. That said, this is open source software, I'm developping this on my (few) free time, so feedback on new releases like you did is always welcome, as long as it is done in a constructive way. I also welcome patches/pull requests, although these seem to be less frequent than complaints (how strange ). 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-15202) Permanent building / consider removing latest changes
SCM/JIRA link daemon commented on JENKINS-15202 Permanent building / consider removing latest changes Code changed in jenkins User: Vincent Latombe Path: src/main/java/hudson/plugins/clearcase/ClearCaseSCM.java http://jenkins-ci.org/commit/clearcase-plugin/7b6d9121570b8eb3860cee17801664b241a74302 Log: JENKINS-15202 Do not trigger build if automatic time rule is used. 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-15214) Triggered build correctly receives git tag parameter but doesn't use it at all
William Ghelfi commented on JENKINS-15214 Triggered build correctly receives git tag parameter but doesn't use it at all Update: I just found out that the plugin worked only the very first time and only for the first job. Now Jenkins is ignoring any configuration of the plugin I throw at it for new jobs, while even the first job got problems: it's stucked with the very first value of the tag parameter I configured the first time, and any attempt to change it in subsequent builds is ignored by Jenkins. T_T I'm going to delete all the jobs, uninstall the plugin, reinstall / recreate all and letting you know. 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-15202) Permanent building / consider removing latest changes
Waldek M edited a comment on JENKINS-15202 Permanent building / consider removing latest changes Hello, Well, perhaps the "plenty" was an overstatement. Sorry, I was a bit emotional, because those 2 existing issues have blocked a team of ~20 persons for a day. I'm simply concerned: if just after upgrade I've discovered 2 issues that have broken long-existing functionality, I'm not really eager to take the risk again and upgrade. As for the automatic time rules: their description is in Advanced section of plugin configuration: Use time rule in config spec If checked, Hudson will use a time rule in the dynamic view's config spec, locking the view contents in as of the beginning of the build, even if files are changed on the branch during the build. When using CC dynamic view, it's actually an essential option. Otherwise, content of the build may change during its compilation - which is very likely for team with a CI branch, the more probable, the bigger the team is. It's mostly about adding a time rule at when updating the view's CS, eg: time 17-sep-12.11:53:51utc+ [... config spec set by user - the original from Jenkins UI ] end time Please note also that the original CS may contain time rules, too. I must though say that I like the new feature that allows setting config spec from file (I guess that was also part of the pull request?). I'm just very cautious and a bit afraid that perhaps there are some other changes that might not have been tested well enough: on snapshot and dynamic views, in standalone and master-slave, with Linux/Unix. Waldek 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-15202) Permanent building / consider removing latest changes
Waldek M commented on JENKINS-15202 Permanent building / consider removing latest changes Hello, Well, perhaps the "plenty" was an overstatement. Sorry, I was a bit emotional, because those 2 existing issues have blocked a team of ~20 persons for a day. I'm simply concerned: if just after upgrade I've discovered 2 issues that have broken long-existing functionality, I'm not really eager to take the risk again and upgrade. As for the automatic time rules: their description is in Advanced section of plugin configuration: Use time rule in config spec If checked, Hudson will use a time rule in the dynamic view's config spec, locking the view contents in as of the beginning of the build, even if files are changed on the branch during the build. When using CC dynamic view, it's actually an essential option. Otherwise, content of the build may change during its compilation - which is very likely for team with a CI branch, the more probable, the bigger the team is. I must though say that I like the new feature that allows setting config spec from file (I guess that was also part of the pull request?). I'm just very cautious and a bit afraid that perhaps there are some other changes that might not have been tested well enough: on snapshot and dynamic views, in standalone and master-slave, with Linux/Unix. Waldek 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-14565) Please add support for Cloudbees folder structure
Billy Foss commented on JENKINS-14565 Please add support for Cloudbees folder structure FYI, I found I could get it to work if I use the path in the job name FeatureBranches/FB0009/$PROMOTED_JOB_NAME Interesting that $PROMOTED_JOB_NAME does not include the full path, but $JOB_NAME does. It resolved to FeatureBranches/FB0009/DataProcessingModules/promoted/Deploy to Artifactory Also if I tried to specify a variable defined in the Folder (ie FOLDER=FeatureBranches/FB0009) the variable would not resolve. 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-15202) Permanent building / consider removing latest changes
anb0s commented on JENKINS-15202 Permanent building / consider removing latest changes Hello, i've created the pull request 11. I was in vacation last week and i'm surprised about fast integration and delivery. Thank You Vincent! About JENKINS-15196: it was "left over" from our test version, we simulated cleartool at test build machines and forget to remove this hack. The fallback to cleartool covered this problem. Sorry. About "new config spec detection": the difference between entered CSPEC and real view CSPEC always confusing our developers. It's not consistent if build was not triggered in this case and manually build was needed to "repair" blocked jobs at CI server. About "automatic time rules": we do not use time rules, i've actually no idea how it affects polling. May be you can explain how it works. I want to understand and fix this issue asap. I think we have some special workflows and maybe some other are not covered or broken. We've used the "old" version based at 1.3.5 (pull request 9) for long time (1 year) and did not expected such problems. Sorry for the inconvenience. Regards, Andre 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-11519) When chosing "Execute concurrent builds if necessary" extra workspaces created should use a different character than '@'
Axel Heider commented on JENKINS-11519 When chosing "Execute concurrent builds if necessary" extra workspaces created should use a different character than '@' Yes, please choose a differen char. 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-15173) Valgrind plugin "Valgrind Results" link on project root page does not always link to the most recent build
SCM/JIRA link daemon commented on JENKINS-15173 Valgrind plugin "Valgrind Results" link on project root page does not always link to the most recent build Code changed in jenkins User: Johannes Ohlemacher Path: src/main/java/org/jenkinsci/plugins/valgrind/ValgrindProjectAction.java http://jenkins-ci.org/commit/valgrind-plugin/8890bb6d15a69ff5010a04e2f2160e0adfe0bb57 Log: fixed JENKINS-15173: "Valgrind Result" is linked to the most recent build that has valid valgrind results Compare: https://github.com/jenkinsci/valgrind-plugin/compare/68a14cbfb24b...8890bb6d15a6 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-15213) email-ext 2.22+ allows any user with configure permission for a single job to circumvent Jenkins security
Slide-O-Mix commented on JENKINS-15213 email-ext 2.22+ allows any user with configure permission for a single job to circumvent Jenkins security Yes, in fact I don't even have access to SECURITY-35, so it would have never been seen. 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-15221) scm_sync_configuration do not synchronize changes made on disk
Wolfgang Hauser created JENKINS-15221 scm_sync_configuration do not synchronize changes made on disk Issue Type: Bug Affects Versions: current Assignee: Frédéric Camblor Components: scm-sync-configuration Created: 18/Sep/12 2:11 PM Description: If I change the configuration on disc, the changed files are NOT synchronized if I reload configuration from disk or restart Jenkins. The changed files should be synchronized to scm at restart/reload. Environment: Jenkins 1.482 Debian Lenny Project: Jenkins Priority: Major Reporter: Wolfgang Hauser 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-15220) Quiet mode for clean checkout (not using update)
Michael Clarke commented on JENKINS-15220 Quiet mode for clean checkout (not using update) As per your previous defect, the issue is being caused by CVS printing progress commands to System.err, and info commands to System.out. -Q/-q only affects System.out, we'd have to catch System.err and filter it if we wanted to restrict the output, but then we have to be careful that we're not hiding any error messages. This would be covered by the current 'Show All CVS Output' checkbox, but isn't something that can be modified by changing the CVS command we run. 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-15220) Quiet mode for clean checkout (not using update)
Michael Clarke closed JENKINS-15220 as Fixed Quiet mode for clean checkout (not using update) Change By: Michael Clarke (18/Sep/12 2:02 PM) Status: Open Closed Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15213) email-ext 2.22+ allows any user with configure permission for a single job to circumvent Jenkins security
Slide-O-Mix commented on JENKINS-15213 email-ext 2.22+ allows any user with configure permission for a single job to circumvent Jenkins security Thanks for bringing this up, most devs don't get copied on SECURITY issues, so that's why it hasn't been looked at. I'll at it soon. 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-14565) Please add support for Cloudbees folder structure
Billy Foss commented on JENKINS-14565 Please add support for Cloudbees folder structure We are seeing the following issue. We have a job in a folder. For the "promote" step we want to copy the artifact from this job and deploy it to Artifactory. Jobs outside the Cloudbees folders work fine, but Jobs that are inside a "Folder" get the following error trying to find the project to copy from. Promoting FeatureBranches . FB0009 . DataProcessingModules #5 Unable to find project for artifact copy: DataProcessingModules This may be due to incorrect project name or permission settings; see help for project name in job configuration. failed build hudson.plugins.copyartifact.CopyArtifact@45ddd0c7 SUCCESS 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-15220) Quiet mode for clean checkout (not using update)
Deepak Mahale created JENKINS-15220 Quiet mode for clean checkout (not using update) Issue Type: Improvement Affects Versions: current Assignee: Unassigned Components: cvs Created: 18/Sep/12 1:50 PM Description: When the 'use update' checkbox is unchecked, whole (generally unessential) output of cvs checkout gets printed to console. Suggested improvement: 'quiet mode' switch could be provided for -q or -Q option/flag. This switch will give user more control as during normal operation the cvs output can be restricted to a minimum; and during debug, everything can be blurted out to the console. Environment: Jenkins 1.8.2 CVS Plugin ver 2.5 Project: Jenkins Priority: Minor Reporter: Deepak Mahale 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-15219) Invalid markup generated when template cannot be loaded for Maven settings file
Jeff MAURY created JENKINS-15219 Invalid markup generated when template cannot be loaded for Maven settings file Issue Type: Bug Affects Versions: current Assignee: domi Components: config-file-provider Created: 18/Sep/12 1:39 PM Description: When a Maven settings config is created, in the case the template file cannot be loaded (very unlikely), the content is hardcoded but the markup is not valid Fix Versions: current Project: Jenkins Labels: config maven Priority: Trivial Reporter: Jeff MAURY 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-15202) Permanent building / consider removing latest changes
Vincent Latombe commented on JENKINS-15202 Permanent building / consider removing latest changes In my opinion, it is normal for the polling to trigger a build if the config spec has been changed by the user. As you said, when using automated time rules, this check shouldn't be enabled because the plugin actually controls the content of the config spec. When you say 'plenty' of blocking issues, are there more than JENKINS-15196 (already fixed) and this one? Although these can be considered as 'blocking', I also think that they are very easy to fix so I don't really see the point of rollbacking everything. 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-14045) Add ability to change dashboard diagrams time-scale "grain" for Trend charts
Andreyev Melo updated JENKINS-14045 Add ability to change dashboard diagrams time-scale "grain" for Trend charts Change By: Andreyev Melo (18/Sep/12 1:26 PM) Summary: Add ability to change dashboard diagrams time-scale "grain" for Trand Trend charts 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-15201) Add support for the track-origins valgrind option
David Ritter updated JENKINS-15201 Add support for the track-origins valgrind option I have attached a snippet of our XML output. I trimmed it down to just the entire element for the block that I included in my first comment. Change By: David Ritter (18/Sep/12 1:22 PM) Attachment: trace-origin.xml 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-15218) Dependency tree should be constrained to only contain relevant nodes in the path
David Ehrenberger created JENKINS-15218 Dependency tree should be constrained to only contain relevant nodes in the path Issue Type: Bug Assignee: wolfs Attachments: graphviewbug.png Components: depgraph-view Created: 18/Sep/12 1:21 PM Description: When on the job page for Test.Job.3 and I click the sidebar link for the dependency graph (URL looks something like http://jenkins.url/job/Test.Job.3/depgraph-view/?), the graph should not include Test.Job.4. Project: Jenkins Priority: Major Reporter: David Ehrenberger 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-13613) scm_sync_configuration may commit bulk changes in one change set
Frédéric Camblor commented on JENKINS-13613 scm_sync_configuration may commit bulk changes in one change set Yup this is not related to this issue. I forgot to test this before releasing, could you file an issue please ? 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-15201) Add support for the track-origins valgrind option
Johannes Ohlemacher commented on JENKINS-15201 Add support for the track-origins valgrind option Hi David, i am a bit confused by the two auxwhat elements in your xml output and by the way they are related to each other. Could you post the full xml code of the error? 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-13613) scm_sync_configuration may commit bulk changes in one change set
Wolfgang Hauser commented on JENKINS-13613 scm_sync_configuration may commit bulk changes in one change set If I change my configuration on disk and reload configuration from disk, the changes are NOT recognized by the plugin. Same, if I restart Jenkins. I would expect a synchronization, but nothing is done. Should this be a new Issue, or should this Issue be 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-15217) Wrong vertical scale in coverage report graph
Andrea Gualano created JENKINS-15217 Wrong vertical scale in coverage report graph Issue Type: Bug Affects Versions: current Assignee: Ognjen Bubalo Attachments: wrong_scale.png Components: jacoco Created: 18/Sep/12 11:58 AM Description: The vertical scale of the coverage graph is too small, so the "lineCovered" graph is not rendered (see attachment). May be related to JENKINS-15177 Environment: Ubuntu Server 12.04.1 LTS Project: Jenkins Priority: Minor Reporter: Andrea Gualano 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-14996) Jenkins does not find Mercurial that is on the PATH
Michael Hodgins commented on JENKINS-14996 Jenkins does not find Mercurial that is on the PATH This is affecting me too. I simply can't use Jenkins because if it. Is there a work around? 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-6452) Polling will fail if project has builds and build view is removed
anb0s resolved JENKINS-6452 as Fixed Polling will fail if project has builds and build view is removed fixed in >= 1.3.9 Change By: anb0s (18/Sep/12 11:42 AM) Status: In Progress Resolved Fix Version/s: current 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-11375) Provide Clearcase changed files to email-ext standard HTML jelly template
anb0s resolved JENKINS-11375 as Fixed Provide Clearcase changed files to email-ext standard HTML jelly template fixed in >= 1.3.8 Change By: anb0s (18/Sep/12 11:41 AM) Status: In Progress Resolved Fix Version/s: current 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-7481) ClearCase polling change degrades performance for large VOBs
anb0s resolved JENKINS-7481 as Fixed ClearCase polling change degrades performance for large VOBs fixed in >= 1.3.9 Change By: anb0s (18/Sep/12 11:41 AM) Status: Open Resolved Fix Version/s: current 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-8305) using ClearCase plugin without config spec and load rules field (load them from files)
anb0s stopped work on JENKINS-8305 using ClearCase plugin without config spec and load rules field (load them from files) Change By: anb0s (18/Sep/12 11:39 AM) Status: In Progress Open 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-8305) using ClearCase plugin without config spec and load rules field (load them from files)
anb0s resolved JENKINS-8305 as Fixed using ClearCase plugin without config spec and load rules field (load them from files) fixed in >= 1.3.9 Change By: anb0s (18/Sep/12 11:40 AM) Status: Open Resolved Fix Version/s: current 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
