[JENKINS-51091] Make test results available on currentBuild

[jenkins-infra-bot]

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 ?

---

Originally reported by ironsean, imported from: Make test results available on currentBuild

• status: Open
• priority: Minor
• component(s): workflow-support-plugin
• resolution: Unresolved
• votes: 4
• watchers: 8
• imported: 20260601-173816

Raw content of original issue

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-infra-bot]

abayer:

• Original comment link
• Raw content of original 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.
  

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.

[jenkins-infra-bot]

ironsean:

• Original comment link
• Raw content of original 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.
  

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.

[jenkins-infra-bot]

svanoort:

• Original comment link
• Raw content of original comment:

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

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