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

HtmlPublisher should be able to handle wildcard paths to find multiple html files

    • Icon: New Feature New Feature
    • Resolution: Fixed
    • Icon: Major Major
    • htmlpublisher-plugin
    • None

      I'm generating some HTML reports per module within my project, so they are in multiple directories, but I'd like to publish them all as one page with tabs to each file. So the ability to specify one path and a comma separated list of files doesn't quite work. I'd rather be able to do

      **\target\reports\fooTool*.html

      and have all found HTML files on the publish page, one tab each named for the file name being presented.

          [JENKINS-7139] HtmlPublisher should be able to handle wildcard paths to find multiple html files

          NetAppBlueDevil created issue -

          mcrooney added a comment -

          I think this sound reasonable. You want the wildcard to work in the "Index page[s]" field, and any matches are a tab?

          If anyone wants to look at how a similar plugin expands wildcards, I'd happily accept a patch!

          mcrooney added a comment - I think this sound reasonable. You want the wildcard to work in the "Index page [s] " field, and any matches are a tab? If anyone wants to look at how a similar plugin expands wildcards, I'd happily accept a patch!

          Yea, pretty much rather than 2 fields of the directory and index pages, just one that is a fileset type specification, then each found file gets a tab.

          I'm guessing there is some standard method to find filesets from this type of pattern as I specify this way for the Junit, cobertura, pmd, checkstyle, etc plugins

          NetAppBlueDevil added a comment - Yea, pretty much rather than 2 fields of the directory and index pages, just one that is a fileset type specification, then each found file gets a tab. I'm guessing there is some standard method to find filesets from this type of pattern as I specify this way for the Junit, cobertura, pmd, checkstyle, etc plugins

          mcrooney added a comment -

          The problem with having only one field is that it is ambiguous which directories should be archived for publishing, since they aren't served out of the workspace as that is subject to change at any time and could be on a slave. Using your example of "*\target\reports\fooTool.html", in the simple case of that matching directly in the workspace, it doesn't know if it should archive the "reports" directory or the "target" directory. With the "**", it could also be at foo/bar/baz/target/reports/fooTool1.html, and then it is even more confusing. Is there a way to decide this that I am missing?

          As a way to achieve what you want, you could create a meta-report directory in your workspace, and put all reports there (either by having the reporting tools write there or via a "mv */reports reportdir" executed as the last build step), and then list those each as an Index Page. In this case a wildcard could make a lot of sense in the index page area.

          mcrooney added a comment - The problem with having only one field is that it is ambiguous which directories should be archived for publishing, since they aren't served out of the workspace as that is subject to change at any time and could be on a slave. Using your example of "* \target\reports\fooTool .html", in the simple case of that matching directly in the workspace, it doesn't know if it should archive the "reports" directory or the "target" directory. With the "**", it could also be at foo/bar/baz/target/reports/fooTool1.html, and then it is even more confusing. Is there a way to decide this that I am missing? As a way to achieve what you want, you could create a meta-report directory in your workspace, and put all reports there (either by having the reporting tools write there or via a "mv */reports reportdir" executed as the last build step), and then list those each as an Index Page. In this case a wildcard could make a lot of sense in the index page area.

          I was thinking to add the mv to the end of the build step, that wouldn't be too evil. So then at lest the wild card in the index page would suffice.

          NetAppBlueDevil added a comment - I was thinking to add the mv to the end of the build step, that wouldn't be too evil. So then at lest the wild card in the index page would suffice.

          mcrooney added a comment -

          I just wanted to comment that you could achieve this now with HTML Publisher 1.0 + the EnvInject plugin. If you add a build step to generate the comma-separated string of files you want, and put it into an environment variable, you could use that in the HTML Publisher plugin. Not ideal but I wanted to document it as a workaround.

          mcrooney added a comment - I just wanted to comment that you could achieve this now with HTML Publisher 1.0 + the EnvInject plugin. If you add a build step to generate the comma-separated string of files you want, and put it into an environment variable, you could use that in the HTML Publisher plugin. Not ideal but I wanted to document it as a workaround.

          mcrooney added a comment -

          1.1 was just released (it may take up to 24 hours to appear), which supports ant syntax, could anyone let me know if that resolves this issue?

          mcrooney added a comment - 1.1 was just released (it may take up to 24 hours to appear), which supports ant syntax, could anyone let me know if that resolves this issue?

          Having the option to list matching files would also be valuable in some cases; if I have 80 reports, I don't really want 80 tabs.

          Grégory Joseph added a comment - Having the option to list matching files would also be valuable in some cases; if I have 80 reports, I don't really want 80 tabs.

          mcrooney added a comment -

          If anyone wants to give this a stab, there was a pull request at https://github.com/jenkinsci/htmlpublisher-plugin/pull/5 that had to be reverted as it caused https://issues.jenkins-ci.org/browse/JENKINS-16083. So it probably isn't a huge amount of work to fix the pull request and solve its regression.

          mcrooney added a comment - If anyone wants to give this a stab, there was a pull request at https://github.com/jenkinsci/htmlpublisher-plugin/pull/5 that had to be reverted as it caused https://issues.jenkins-ci.org/browse/JENKINS-16083 . So it probably isn't a huge amount of work to fix the pull request and solve its regression.

          Has there been any progress on adding back pattern support?
          I have to deal with a directory that contains an version number and would like to simply use eg: "testresults-*/" as the directory (this would match a single directory in my case so I'm not sure if this is the correct request)

          Br,
          Christoph

          Ing. Christoph Obexer added a comment - Has there been any progress on adding back pattern support? I have to deal with a directory that contains an version number and would like to simply use eg: "testresults-*/" as the directory (this would match a single directory in my case so I'm not sure if this is the correct request) Br, Christoph

            r2b2_nz Richard Bywater
            netappbluedevil NetAppBlueDevil
            Votes:
            17 Vote for this issue
            Watchers:
            29 Start watching this issue

              Created:
              Updated:
              Resolved: