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

Guess at buckets for initial build via filesystem scan

      When no reference build is available (there could be several reasons for this), currently the plugin puts everything into a single bucket. For very long suites, it would be useful to be able to offer a fallback estimate based on a filesystem scan.

      For example, in a Maven project with default Surefire configuration you could look in src/test/java/ for **/*Test.java, divide all matches into buckets based simply on count, and proceed.

      Subsequent builds would have access to more accurate information as well as timing and so would do a better job of equalizing branch runtimes, but this would be a lot better than nothing.

          [JENKINS-47206] Guess at buckets for initial build via filesystem scan

          Jesse Glick added a comment -

          There would need to be some sort of extension point allowing the details of that heuristics to be pluggable and customizable per project, similar to JENKINS-28924.

          Jesse Glick added a comment - There would need to be some sort of extension point allowing the details of that heuristics to be pluggable and customizable per project, similar to  JENKINS-28924 .

          Jesse Glick added a comment -

          Would serve as an alternative to both JENKINS-33169 (different build options within the current job) and JENKINS-46028 (different job to search for builds).

          Jesse Glick added a comment - Would serve as an alternative to both  JENKINS-33169 (different build options within the current job) and  JENKINS-46028 (different job to search for builds).

          I agree that there are many possibilities how to do it more intelligent in case that there is no previous result. It does not matter if it is correct fully or not, it is still better then do it in one bucket.

          Lucie Votypkova added a comment - I agree that there are many possibilities how to do it more intelligent in case that there is no previous result. It does not matter if it is correct fully or not, it is still better then do it in one bucket.

          I can implement it for Maven project as you suggested - to take it from src/test/java/ for **/*Test.java was my first thought when I started use this plugin. My question is, should it be default or better optional in settings? Or do it only when it is Maven project (but it can work for another type of project as well)? 

          Lucie Votypkova added a comment - I can implement it for Maven project as you suggested - to take it from src/test/java/  for  **/*Test.java  was my first thought when I started use this plugin. My question is, should it be default or better optional in settings? Or do it only when it is Maven project (but it can work for another type of project as well)? 

          Jesse Glick added a comment -

          See my comments w.r.t. JENKINS-28924.

          Jesse Glick added a comment - See my comments w.r.t.  JENKINS-28924 .

          As a quick solution I did it for java only.  It is not a very big change, but it is fast solution and should break nothing - firstly it uses previous build, if it does not exists, it tries to find Test classes in file source by pattern expected in java project, if this fails it returns empty result - so it will be executed in one (the same behavior as before). It works only if it is performed in directory which contains any files - so you have to prepare file data for it (checkout given java project). 

          Lucie Votypkova added a comment - As a quick solution I did it for java only.  It is not a very big change, but it is fast solution and should break nothing - firstly it uses previous build, if it does not exists, it tries to find Test classes in file source by pattern expected in java project, if this fails it returns empty result - so it will be executed in one (the same behavior as before). It works only if it is performed in directory which contains any files - so you have to prepare file data for it (checkout given java project). 

          Jesse Glick added a comment -

          Interesting, will take a look. I suspect we will need something more careful going forward, but so long as no new user option or API is introduced, it could be a stopgap.

          Jesse Glick added a comment - Interesting, will take a look. I suspect we will need something more careful going forward, but so long as no new user option or API is introduced, it could be a stopgap.

          Andrew Bayer added a comment -

          Merged, releasing now as 1.11.

          Andrew Bayer added a comment - Merged, releasing now as 1.11.

            lvotypkova Lucie Votypkova
            jglick Jesse Glick
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: