[JIRA] [core] (JENKINS-25694) Archive artifacts cannot start with ./, but Parameters from properties file can (dot slash)
Ken Beal commented on JENKINS-25694 Archive artifacts cannot start with ./, but Parameters from properties file can (dot slash) I don't have visibility into the inner workings of Jenkins. I can specify "./path/path/file" in one location and not in another. This is "Jenkins as a whole" being inconsistent. That's the way this is a bug. Surprising that I have to elucidate on this. 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-25694) Archive artifacts cannot start with ./, but Parameters from properties file can
Ken Beal created JENKINS-25694 Archive artifacts cannot start with ./, but Parameters from properties file can Issue Type: Bug Assignee: Unassigned Components: core Created: 19/Nov/14 6:05 PM Description: We had a build job that passed info to another build job. This file was not being archived, but I wanted to see its contents to determine where an issue had happened. So I copied the line from the "Parameters from properties file" (in "Trigger parameterized build on other projects"), and pasted it in "Files to archive". When I then ran a build, it failed with this somewhat amusing message: -- Archiving artifacts ERROR: No artifacts found that match the file pattern ".\depot\tokyo\upside\CI\AutoDeploy\data\ATF_data.txt". Configuration error? ERROR: ‘.\depot\tokyo\upside\CI\AutoDeploy\data\ATF_data.txt’ doesn’t match anything, but ‘depot\tokyo\upside\CI\AutoDeploy\data\ATF_data.txt’ does. Perhaps that’s what you mean? Build step 'Archive the artifacts' changed build result to FAILURE -- It looks like the way that it handles the leading ".\" may be different from how the Parameterized Trigger Plugin does. Project: Jenkins Priority: Minor Reporter: Ken Beal 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-25694) Archive artifacts cannot start with ./, but Parameters from properties file can (dot slash)
Ken Beal updated JENKINS-25694 Archive artifacts cannot start with ./, but Parameters from properties file can (dot slash) Change By: Ken Beal (19/Nov/14 6:06 PM) Summary: Archiveartifactscannotstartwith./,butParametersfrompropertiesfilecan (dotslash) Description: Wehadabuildjobthatpassedinfotoanotherbuildjob.Thisfilewasnotbeingarchived,butIwantedtoseeitscontentstodeterminewhereanissuehadhappened.SoIcopiedthelinefromtheParametersfrompropertiesfile(inTriggerparameterizedbuildonotherprojects),andpasteditinFilestoarchive.WhenIthenranabuild,itfailedwiththissomewhatamusingmessage:--ArchivingartifactsERROR:Noartifactsfoundthatmatchthefilepattern.\depot\tokyo\upside\CI\AutoDeploy\data\ATF_data.txt.Configurationerror?ERROR:‘.\depot\tokyo\upside\CI\AutoDeploy\data\ATF_data.txt’doesn’tmatchanything,but‘depot\tokyo\upside\CI\AutoDeploy\data\ATF_data.txt’does.Perhapsthat’swhatyoumean?BuildstepArchivetheartifactschangedbuildresulttoFAILURE--Itlookslikethewaythatithandlestheleading.\maybedifferentfromhowtheParameterizedTriggerPlugindoes. Addingdotslashinsummaryanddescription,asitseemsIcannotsearchfor.\(Ihadtrieddotslashbutdidntseeanythingrelevant,soifsomeoneelsedoesthesameactions,theyllfindthisone). 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [jobconfighistory-plugin] (JENKINS-25605) More easily map build instances to the configuration it was run it
Ken Beal created JENKINS-25605 More easily map build instances to the configuration it was run it Issue Type: New Feature Assignee: Mirko Friedenhagen Components: jobconfighistory-plugin Created: 13/Nov/14 7:32 PM Description: It would be useful to be able to see, at a glance, the configuration change lines with the build(s) that were done between them, interspersed. This way it would be easier to determine which build instances were run with which configuration change. One way could be to "draw lines" from the builds in the left column, to the configuration that build was run in, but I'm not sure whether line-drawing across columns can be done. The benefit to this is it wouldn't take any more screen real-estate. Another way is to put the builds that were run in between; in the below, each of the "#nn" would be a link to that build instance, like the builds in the left column; the "Build" line indicates that that (or those) build(s) was (were) done using the configuration line directly below it: Build #12, #13, #14 2014-11-11_17-31-35 Changed kbeal View as XML (RAW) 2014-11-11_17-30-29 Changed kbeal View as XML (RAW) Restore Build #11 2014-11-11_17-28-46 Changed kbeal View as XML (RAW) Restore 2014-11-10_18-46-38 Changed kbeal View as XML (RAW) Restore 2014-11-10_18-38-30 Changed kbeal View as XML (RAW) Restore Build #10, #9, #8 2014-11-10_18-37-43 Changed kbeal View as XML (RAW) Restore 2014-11-10_18-35-54 Changed kbeal View as XML (RAW) Restore Build #7 2014-11-10_18-32-34 Changed kbeal View as XML (RAW) Restore Build #6 2014-11-10_18-32-33 Changed kbeal View as XML (RAW) Restore Build #5 2014-11-10_18-32-32 Changed kbeal View as XML (RAW) Restore Build #4 2014-11-10_18-32-28 Created SYSTEM View as XML (RAW) Restore Build #3, #2, #1 2014-11-10_18-32-27 Changed kbeal View as XML (RAW) Restore Project: Jenkins Priority: Minor Reporter: Ken Beal 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [build-flow-plugin] (JENKINS-25529) Build Flow does not always run multiple jobs in parallel: requires parameters to be passed, and Execute concurrent in downstream job
Ken Beal commented on JENKINS-25529 Build Flow does not always run multiple jobs in parallel: requires parameters to be passed, and Execute concurrent in downstream job NOTE: job flowB does NOT NEED to have parameters defined in it. The requirement is that job flowA SENDS PARAMETERS to the flowB job (one can send unnamed parameters) AND that the parameters have different values. Starting three jobs like the above, but with "string: 1" in each of them, only one instance runs. A final potential edge case here: what if I run two jobs with "string: 1" and one with "string: 2"? That ran two instances of the same instance number and one instance of the consecutive number but of course, only one of the two with the same instance number actually ran. In other words, it said it started "flowB #11", "flowB #11", and "flowB #12", but only #11 and #12 ran, so it didn't actually run three jobs in parallel like it should have. 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [parameterized-trigger] (JENKINS-24257) Build A triggers build B 3 times via Parameterized Trigger Plugin; all three have same # in console output (but are consecutive)
Ken Beal
created JENKINS-24257
Build A triggers build B 3 times via Parameterized Trigger Plugin; all three have same # in console output (but are consecutive)
Issue Type:
Bug
Affects Versions:
current
Assignee:
huybrechts
Components:
parameterized-trigger
Created:
13/Aug/14 9:48 PM
Description:
To reproduce:
1. Create a job ("A") that does nothing.
2. Create another job ("B") that does nothing.
3. In B's configure page, click "Add post-build action", then click "Trigger parameterized build on other projects".
4. In "Projects to build", type "A".
5. (My build used parameters, so if the above doesn't reproduce the issue, add some parameters to A and add "Predefined parameters" and type "X=Y" for each X=a parameter you added.)
6. Repeat steps 2 through 5 two more times, so A will invoke B three times.
7. Run A.
Expected Results:
A's console output should indicate that it started B three times, and each instance should be +1 from the previous.
Actual Results:
A's console output indicates that it started B three times, but each instance number is the same.
Environment:
Jenkins on Windows Server 2008, browsing from Windows 7.
Project:
Jenkins
Priority:
Major
Reporter:
Ken Beal
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
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [clover] (JENKINS-23055) Allow Parameter interpolation for Clover path and file name
Ken Beal commented on JENKINS-23055 Allow Parameter interpolation for Clover path and file name This was fixed in the TestNG plugin fairly quickly. Could that code be reused, possibly? I'd like to put up $20 towards fixing this, but I'm not sure how to go about doing that. 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [parameterized-trigger] (JENKINS-12410) Downstream jobs not associated with upstream parent job properly
Ken Beal
commented on JENKINS-12410
Downstream jobs not associated with upstream parent job properly
The "Deploy" part creates a VM; the "Delete" part deletes it.
It looks like Jenkins is "getting confused" because we're seeing one job flow "merge" with another. Specific numbers:
Detect #33086 - Monitor #637 - Deploy #531 - Test1 #413 - Test2 #360 - Test3 #308 - Upload #301 - Report #305 - Delete #318
Detect #33142 - Monitor #641 - Deploy #532 - Test1 #414 - Test2 #360
Looking at Test2 #361, it appears to have crashed, which may be why Jenkins then "decided" that Test1 #414 - Test2 #360.
So "Test2+1" would have been #361, which was expected, not #360 which we saw in the console output of Test1 #414 (as well as #413).
At the very least it should say build #361 ran, but likely there's stuff happening after the build is started that records back to the upstream job? (An odd design, it should know it's #361 at the time it started which is, understandably, a little bit after Test1 finished, but that information should have been set a moment after #361 started, and not be "corrupted" by #361 crashing hours later note that this job takes 4-8 hours to run, and generates a large log, around 575 MB, in case that's relevant.)
The crash from Test2 #361 is below, to the end of this comment. It was run on a slave ("slave3"), which #360 was also built on (e.g., it's not always crashing when it is run on this slave).
The beginning of the below is the end of a SOAP call, which is part of the tests that are run, and then it crashed. #361's log was only 80 MB, as it crashed 1 hour 22 min in. #360's log was 575 MB, and ran for 4 hours 40 minutes.
===
...
testng /SOAP-ENV:Body
testng /SOAP-ENV:Envelope
testng
FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: Failed to abort
hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.IOException: Failed to abort
at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:41)
at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:34)
at hudson.remoting.Request.call(Request.java:174)
at hudson.remoting.Channel.call(Channel.java:739)
at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:168)
at $Proxy70.join(Unknown Source)
at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:951)
at hudson.tasks.CommandInterpreter.join(CommandInterpreter.java:137)
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:97)
at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:66)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:745)
at hudson.model.Build$BuildExecution.build(Build.java:198)
at hudson.model.Build$BuildExecution.doRun(Build.java:159)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:518)
at hudson.model.Run.execute(Run.java:1704)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:231)
Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: Failed to abort
at hudson.remoting.Request.abort(Request.java:299)
at hudson.remoting.Channel.terminate(Channel.java:802)
at hudson.remoting.Channel$2.terminate(Channel.java:483)
at hudson.remoting.AbstractByteArrayCommandTransport$1.terminate(AbstractByteArrayCommandTransport.java:72)
at org.jenkinsci.remoting.nio.NioChannelHub$NioTransport.abort(NioChannelHub.java:184)
at org.jenkinsci.remoting.nio.NioChannelHub.run(NioChannelHub.java:563)
at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: Failed to abort
... 9 more
Caused by: java.io.IOException: An existing connection was forcibly closed by the remote host
at sun.nio.ch.SocketDispatcher.read0(Native Method)
at
[JIRA] [parameterized-trigger] (JENKINS-12410) Downstream jobs not associated with upstream parent job properly
Ken Beal reopened JENKINS-12410 Downstream jobs not associated with upstream parent job properly We are experiencing this. We have a job flow like Detect - Monitor - Deploy - Test1 - Test2 - Test3 - Upload - Report - Delete. Not all the VMs we deploy are being deleted. Upon investigation, when I looked at the Delete job at the top of its console output, it shows the chain of jobs that ran. However, when I then looked at "Deploy+1", it ran "Test1+1", but looking in that job's console output, it shows it ran Test2 not "Test2+1"! We are using the Parameterized Trigger Plugin (latest version, 2.25), as well as Email-Ext (latest version, 2.38.1). Change By: Ken Beal (23/Jun/14 6:35 PM) Resolution: Fixed 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [parameterized-trigger] (JENKINS-23053) Allow Parameter interpolation for job name
Ken Beal commented on JENKINS-23053 Allow Parameter interpolation for job name Yes, this is a duplicate, 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [parameterized-trigger] (JENKINS-23053) Allow Parameter interpolation for job name
Ken Beal closed JENKINS-23053 as Duplicate Allow Parameter interpolation for job name Duplicate of previous ticket. Change By: Ken Beal (19/May/14 2:54 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [parameterized-trigger] (JENKINS-11280) Downstream project name is not accepting env variable/build parameters
Ken Beal commented on JENKINS-11280 Downstream project name is not accepting env variable/build parameters Added a vote, duplicate of the ticket I just entered, https://issues.jenkins-ci.org/browse/JENKINS-23053 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [parameterized-trigger] (JENKINS-23053) Allow Parameter interpolation for job name
Ken Beal
created JENKINS-23053
Allow Parameter interpolation for job name
Issue Type:
Bug
Affects Versions:
current
Assignee:
huybrechts
Components:
parameterized-trigger
Created:
15/May/14 3:20 PM
Description:
We have branches and projects. We have jobs for each, and would like to unify them so that a single job can be run on multiple branches. Most of the plugins already support using Parameters in their strings (e.g., the Perforce plugin allows us to specify "//depot/${project}/${branchName}" etc).
We would like the Parameterized Trigger Plugin to provide similar functionality.
Environment:
Windows 2008 R2 server, Windows 7 browser
Project:
Jenkins
Labels:
interpolation
Priority:
Major
Reporter:
Ken Beal
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
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [clover] (JENKINS-23055) Allow Parameter interpolation for Clover path and file name
Ken Beal
created JENKINS-23055
Allow Parameter interpolation for Clover path and file name
Issue Type:
Bug
Affects Versions:
current
Assignee:
stephenconnolly
Components:
clover
Created:
15/May/14 3:32 PM
Description:
We have branches and projects. We have jobs for each, and would like to unify them so that a single job can be run on multiple branches. Most of the plugins already support using Parameters in their strings (e.g., the Perforce plugin allows us to specify "//depot/${project}/${branchName}" etc).
We would like the Clover Plugin to provide similar functionality.
Environment:
Windows 2008 R2 server, Windows 7 browser
Project:
Jenkins
Priority:
Major
Reporter:
Ken Beal
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
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [ui-changes] (JENKINS-17206) Want to disable the drop-downs
Ken Beal resolved JENKINS-17206 as Fixed Want to disable the drop-downs I noticed that this was addressed in 1.513 (or possibly earlier, as I had updated to that version and saw it fixed). Now, there is a "caret" that the user has to click on in order to get the drop-down, and I'm able to copy-and-paste more easily now. Change By: Ken Beal (17/May/13 2:43 PM) 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [jobconfighistory] (JENKINS-17954) UI show next build will have a changed config
Ken Beal created JENKINS-17954 UI show next build will have a changed config Issue Type: Bug Assignee: Mirko Friedenhagen Components: jobconfighistory Created: 14/May/13 9:19 PM Description: We have several plugins added, which show useful information to the right of build instances. One plugin shows the size of that build's artifacts; another shows how it was started (from upstream, or by human, etc). Another is the job config history, which shows a wrench if this job's configuration changed prior to running that instance. It is possible that the job's configuration has changed since the most recent instance, and this is not currently shown. Would it be possible to show this in the UI? My initial thought was to have it add a "build instance" at the top: with a gray ball to indicate "not run", the next #, and text like "not run yet" in the place where the date/timestamp would be, and a wrench to the right of it to indicate that the configuration has already changed. However, I'm not sure whether that would perturb other plugins (e.g., they might see the existence of "another" build and try to take some action, which may fail because it's not really there). If that would be the case, then if a control could be added above the builds and below the left menu, a notification could be added there. Project: Jenkins Priority: Major Reporter: Ken Beal 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [fstrigger] (JENKINS-17873) FSTrigger does not accept Parameters
Ken Beal commented on JENKINS-17873 FSTrigger does not accept Parameters Hi Gregory, not exactly. Our scenario is: we want to define the location in one place, and reference it from the other. Right now we have it as a Parameter, and also as an FSTrigger setting. I understand that job Parameters cannot be used here the question now is: is there any mechanism to avoid having this information hard-coded in two locations? The FSTrigger is to a completion file that the build writes when it is done; we also want to do a directory of that for forensics, so we know time/date and size etc. The location is a complex path with the "branch" as a component of the path. We create new build jobs for new branches, and it would be far preferable to have to update one piece of data with the new branch, rather than needing to update two. Is there any possibility that some other functionality might assist us here? Thanks! Ken 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [fstrigger] (JENKINS-17873) FSTrigger does not accept Parameters
Ken Beal created JENKINS-17873 FSTrigger does not accept Parameters Issue Type: Bug Affects Versions: current Assignee: Gregory Boissinot Components: fstrigger Created: 06/May/13 3:58 PM Description: Repro steps: 1. Create a new job, "Test-FSTrigger". 2. Configure a string Parameter "monitor", with value "c:\test". 3. Check the "FSTrigger - Monitor files", then click "Add file to monitor" and in the "File Path" text field, enter "$monitor". 4. In the "Schedule" text field, enter "* * * * *" so it will monitor every minute. 5. Save the job, and wait one minute. Then click on the "FSTrigger Files Log" link in the left menu. Expected results: It should have said the folder doesn't exist (and then I would create the folder, wait a minute to see what it said then; then create the file, and wait a minute to see it function). Actual results: It shows an error: "ERROR - Polling error The given pattern for the file to monitor must have a directory." Environment: Windows 7 Project: Jenkins Priority: Major Reporter: Ken Beal 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-17206) Want to disable the drop-downs
Ken Beal created JENKINS-17206 Want to disable the drop-downs Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: ui-changes Created: 13/Mar/13 8:52 PM Description: The specific use case: I want to copy the job name from the main page, so that in an email it will show the text and also be a hyperlink to the job. However, when the drop-down pops up, it stops the highlighting and starts it from where the cursor currently is, so if I've dragged through and highlighted half the name, when the drop-down appears, that half will be un-highlighted, and as I continue dragging it'll highlight the other half of the name. This thus requires rapid dragging which is making this far less usable than it used to be, before the drop-downs were imposed. Environment: Windows, Chrome Project: Jenkins Priority: Major Reporter: Ken Beal 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
