Due to some maintenance issues, this service has been switched in read-only mode, you can find more information about the why

and how to migrate your plugin documentation in this blogpost

Skip to end of metadata
Go to start of metadata

Build trigger that polls one or more directories and starts a build if certain files are found within those directories.

Plugin Information

View Files Found Trigger on the plugin site for more information.

Compatible with Java 7 and above.


Enable the trigger within the "Build Environment" section of the build's configuration page.



  • Detect files on the master or on a Jenkins slave.
  • Specify the files with Ant-style includes and excludes patterns.
  • Multiple directories can be specified.
  • Can specify the minimum number of found files to trigger the build.
  • Able to test the trigger before saving the settings.
  • Environment variables and global variables can be entered as $var or ${var}.
  • During the build, the settings can be accessed as environment variables.
    • filesfound_setting_node
    • filesfound_setting_directory
    • filesfound_setting_files
    • filesfound_setting_ignoredfiles
    • filesfound_setting_triggernumber

Similar Plugins

Release History

New releases may take a few hours to appear in the update center.

1.5 (Mar 14, 2017)

  • Can now specify the minimum number of found files to trigger the build. (pull request #2)
    Contributed by lyenliang
  • Improved diagnostic logging.
  • Now requires at least Jenkins 1.580.1 and Java 7.

1.4 (Aug 15, 2015)

  • Can now look for files on Jenkins slaves.

1.3.1 (Feb 25, 2015)

  • When the directory is not found, display a hint about file permissions.
  • Now requires at least Jenkins 1.520.

1.3 (Aug 17, 2011)

  • The trigger settings are available to the build scripts as environment variables.
  • When testing the configuration, the number of files found is displayed.
  • Environment variables, provided by the global properties or the operating system, can be entered into the configuration page as $var or ${var}.
  • Now requires at least Jenkins 1.399.

1.2 (Mar 06, 2011)

  • Multiple directories can be specified.
  • Now requires at least Jenkins/Hudson 1.377.

1.1.4 (Feb 07, 2011)

  • Built from github repository with new Jenkins infrastructure. No behavioural changes.

1.1.3 (Jul 18, 2010)

1.1.2 (Jun 20, 2010)

  • Now requires at least Jenkins/Hudson 1.301, rather than 1.349.

1.1.1 (Jun 4, 2010)

  • Fixed the broken Ant documentation links within the help messages.

1.1 (Apr 25, 2010)

  • Added a button to test the entered configuration before saving.
  • The Files to find field now defaults to **.
  • By default, no files are ignored. Previous releases ignored all files in the Ant default excludes.

1.0.1 (Apr 23, 2010)

  • An exception no longer appears in the console when the entered directory does not exist.

1.0 (Mar 16, 2010)

  • Initial release.


  1. Unknown User (ez2cy@hotmail.com)

    In (at least) your FilesFoundTrigger.java code, you use the isEmpty() method on the string class, which I believe wasn't introduced until Java 6.  This makes the plugin incompatible with older versions of 1.5+.  Was that your wish?  Or could you make this backward-compatible with anything that Hudson itself is compatible with?

    UPDATE:  I rebuilt after removing the .isEmpty() calls in your two source files and all works as expected on a 1.5+ system.

    1. Unknown User (steven brown)

      Thanks for letting me know, Adam. Fixed in release 1.1.3.

  2. Unknown User (vid401t)

    Can this plugin be used for remote nodes?  So if I wanted to deposit a file to a specific directory on a remote node to trigger a job, can this be done?



    1. Unknown User (stevengbrown)

      Feature added for Files Found Trigger 1.4.

  3. Unknown User (hugolmab)

    I can't seem to be able to use the env vars.

    And there is nothing there when I run "env" in my "Execute Shell" configuration

    Is it only here?

    1. Unknown User (stevengbrown)

      It works for me. Can you give me enough details to reproduce your problem?

      1. Unknown User (hugolmab)

        Hello Steven,

        when I commented that, I was starting my first tests with your plugin. By now I made it work, and, just to let you know what happened (and also leave a question here): I was using a slave machine to run my build, which I did not realize your plugin does not access (since it looks to my master host on jenkins). (If I had tested it before and seen the tip that such dir didnt exist, I could have prevented this comment here and looked up faster into the error's cause, my bad on that.). So my question is if there is any way I could use your plugin to look into a dir inside my slave hosts?! Thanks!

        1. Unknown User (stevengbrown)

          I've made an update and the plugin can now look for files on a slave.

  4. Unknown User (adityachs)


    I am facing issues with this plugin.

    1. I cant choose node in the job. It displays master node only. I have another slave node, which is not displayed in the drop down.
      (Jenkins master on Linux and Slave is Windows 2003 which is up and running)
    2. When I provide a folder to monitor, the test fails with message that Directory not found,  if directory exists, user jenkins1 may not have access.
      (I gave 777 permission for the folder, but still same error)

    1. Unknown User (stevengbrown)

      Hi, how did it go? Can you give me more details to help reproduce your issue?

      1. Unknown User (stevengbrown)

        May have an explanation for the slaves not appearing. Looks like you have to delete the text from that field before the other choices appear in the drop down list.

        - Steve

  5. Unknown User (code_shiquan)

    Is there any way to achieve the effect of "run once so long as within this time period, as and when all to-run conditions become true"?

    For example, I am trying to achieve the effect of "build once any time within the hour of 0800, 1200 and 1600hrs on weekdays when a specific file is found" with this schedule expression: H 8-16/4 * * *. It had worked fine for my workplace as a preceding prerequisite build (a CI build) had not once blocked the build of this project (the logic is: If CI is building or fails, the trigger file will be deleted/not generated. Once CI is completed, passes, and still within the hourly timeslots specified by the schedule expression, build this project by the way of detecting a trigger file generated by the CI build and detecting that the current time is still within the specified timeslot). However, since the H simply allocates a specific value, if for example the H value causes this build to run only at 0801, 1201 and 1601, a CI build that runs into these timings would cause this build to never run for the remainder of the allocated timeslot even though the to-run conditions are in favour (true) and is still within the allocated time.

    1. Unknown User (stevengbrown)

      Hi Shiquan,

      You might want to try * 8-16/4 * * * to have it run every minute within those hours, and also have the build delete the trigger file once it starts to avoid running a second time.