The TestDataPublisher extension in junit-plugin allows other plugins to contribute TestAction s that enrich test result UI. This is called "Additional test report features" in the job configuration UI. There are currently jelly hooks that allow other plugins to provide custom content in various places across the test result pages.

I suggest that two new optional jelly hooks are added that allow TestAction s to add custom columns to the ClassResult table: one hook for the table headers and one hook for the table rows. That way, it would be possible to include additional column headers and row cells from TestAction s.

Custom columns in the ClassResult table can be useful for several things. For example, JENKINS-12575 discusses chronological ordering of test cases. The de-facto JUnit XML report schema as implemented by various software including the junit-plugin doesn't support datetime information in test cases, so a generic catch-all support for chronological ordering may not be a good fit for the standard junit-plugin itself. Instead, the junit-plugin by default sorts test cases alphabetically by name, and the UI allows the user to re-sort the table by the other standard columns: duration and status.

However, there may be specific cases where a more specialized third party plugin can deduce datetime information. If such a plugin can add a custom column (for example "Timestamp") to the ClassResult table, the user can choose to sort the table chronologically. I've attached a screenshot of a mockup showing the ClassResult table sorted by the values in the Timestamp column.

Note that the Timestamp column is just an example of a custom column. There is nothing in this suggested improvement that prevents other custom columns to be added by other plugins.

In more concrete terms, I am suggesting that two new optional classresult-tableheader.jelly and classresult-tablerow.jelly pages are added to TestAction s and included in the hudson/tasks/junit/ClassResult/body.jelly resource similar to how the badge.jelly page is included today.

diff --git a/src/main/resources/hudson/tasks/junit/ClassResult/body.jelly b/src/main/resources/hudson/tasks/junit/ClassResult/body.jelly
index 6ce0000..2bb9e88 100644
--- a/src/main/resources/hudson/tasks/junit/ClassResult/body.jelly
+++ b/src/main/resources/hudson/tasks/junit/ClassResult/body.jelly
@@ -32,6 +32,9 @@ THE SOFTWARE.
           <th class="pane-header">${%Test name}</th>
           <th class="pane-header" style="width:6em">${%Duration}</th>
           <th class="pane-header" style="width:6em">${%Status}</th>
+          <j:forEach var="tableheader" items="${it.testActions}">
+            <st:include it="${tableheader}" page="classresult-tableheader.jelly" optional="true"/>
+          </j:forEach>
         </tr>
       </thead>
       <tbody>
@@ -50,6 +53,9 @@ THE SOFTWARE.
                 ${pst.message}
               </span>
             </td>
+            <j:forEach var="tablerow" items="${p.testActions}">
+              <st:include it="${tablerow}" page="classresult-tablerow.jelly" optional="true"/>
+            </j:forEach>
           </tr>
         </j:forEach>
       </tbody>

Such an approach would make it easy for a third party plugin to add any number of columns to the ClassResult table. It is also easy for a third party plugin to localize column names and cell data formats using the standard Jelly internationalization support. The change would be backwards compatible since the two new pages are optional; any existing plugins that contribute TestDataPublisher s do not need to be updated.

A drawback is that if the third party plugin wants to achieve UI consistency it must match html elements and css classes of the standard columns in body.jelly. If the markup of th and td elements is changed in junit-plugin, the corresponding change would have to be done in each plugin that contributes classresult-tableheader.jelly and classresult-tablerow.jelly pages too. Is this code duplication acceptable?

I am willing to submit a pull request that implements this improvement. Before doing so I would like feedback from the maintainers to ensure that custom columns in the ClassResult table is considered a good idea or if there is a better way to accomplish the same thing.