Currently, as described here, the only way to get the archived test results in a Pipeline job is through the currentBuild.rawBuild object and pulling an AbstractTestResultAction out of it to read test results. This involved whitelisting several external methods.

      This is a lot of work to try and say, generate a slack message saying "Build BUILD failed, X/Y tests failed". How hard would it be to define a property on the currentBuild Global Variable live this: currentBuild.testResult.failCount ?

          [JENKINS-51091] Make test results available on currentBuild

          Andrew Bayer added a comment -

          It'd be at least a little complicated - the workflow-support plugin would need to depend on the junit plugin, etc. For what it's worth, the junit step does return a TestResultSummary.

          Andrew Bayer added a comment - It'd be at least a little complicated - the workflow-support plugin would need to depend on the junit plugin, etc. For what it's worth, the junit step does return a TestResultSummary .

          Sean MacKay added a comment -

          Interesting, so do none of the test results pages in normal or Blue Ocean UI function without the junit plugin? Or is the way the data is eventually saved into the finished build just even harder to access? I assumed the workaround with AbstractTestResultAction pulled the results from the same final location which both nunit and junit post to, but I haven't tested to confirm so I'm not sure.

          And that's interesting. I assume you could use it in a scripting pipeline like this. Does the same work in Declarative pipeline?

          def results = junit '*.xml';
          sh "echo ${results.getFailCount()}"
          

          Unfortunately the `nunit` plugin doesn't seem to behave the same way (I use both). Yet it still posts the results to the same final place, so those results should still be available from one location regardless of which plugin posts there. That's why I assumed there would be a way to read them, but I don't know enough about the architecture in place to really be sure of anything. I'll do some testing and see if I can at least confirm what the behaviour of each approach is.

          Sean MacKay added a comment - Interesting, so do none of the test results pages in normal or Blue Ocean UI function without the junit plugin? Or is the way the data is eventually saved into the finished build just even harder to access? I assumed the workaround with AbstractTestResultAction pulled the results from the same final location which both nunit and junit post to, but I haven't tested to confirm so I'm not sure. And that's interesting. I assume you could use it in a scripting pipeline like this. Does the same work in Declarative pipeline? def results = junit '*.xml' ; sh "echo ${results.getFailCount()}" Unfortunately the `nunit` plugin doesn't seem to behave the same way (I use both). Yet it still posts the results to the same final place, so those results should still be available from one location regardless of which plugin posts there. That's why I assumed there would be a way to read them, but I don't know enough about the architecture in place to really be sure of anything. I'll do some testing and see if I can at least confirm what the behaviour of each approach is.

          Sam Van Oort added a comment -

          Red flag for me: if we do off-master, this one would add some nontrivial extra complexity to that implementation.

          Sam Van Oort added a comment - Red flag for me: if we do off-master, this one would add some nontrivial extra complexity to that implementation.

            Unassigned Unassigned
            ironsean Sean MacKay
            Votes:
            4 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: