Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-17873

FSTrigger does not accept Parameters

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: In Progress (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: fstrigger-plugin
    • Labels:
      None
    • Environment:
      Windows 7
    • Similar Issues:

      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."

        Attachments

          Activity

          Hide
          gbois Gregory Boissinot added a comment -

          Job Parameters are only processed at build tine. They cannot be used by XTrigger plugin as the FSTrigger plugin.
          Therefore, you have to put the plain value.

          Show
          gbois Gregory Boissinot added a comment - Job Parameters are only processed at build tine. They cannot be used by XTrigger plugin as the FSTrigger plugin. Therefore, you have to put the plain value.
          Hide
          gbois Gregory Boissinot added a comment -

          Does it suit you?

          Show
          gbois Gregory Boissinot added a comment - Does it suit you?
          Hide
          kbeal Ken Beal added a comment -

          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

          Show
          kbeal Ken Beal added a comment - 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
          Hide
          abigos Andy Bigos added a comment -

          Same situation here. Would be good to avoid repeating the value if such as mechanism was possible.

          Show
          abigos Andy Bigos added a comment - Same situation here. Would be good to avoid repeating the value if such as mechanism was possible.

            People

            • Assignee:
              gbois Gregory Boissinot
              Reporter:
              kbeal Ken Beal
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: