jenkinsci / jenkinsci/junit-plugin

[JENKINS-43692] Allow an option for the pipeline step to throw an exception instead of setting the build status.

Open
#1,075 2 comments 0 reactions 0 assignees View on GitHub
component:junit-plugin enhancement imported-jira-issue priority:minor resolution:unresolved
Dominant language
Java
Stars
87
Forks
351
Avg merge
1d 19h
Merged PRs (30d)
2

Description

Sometimes I don't want the junit plugin to mark a build as failed when it publishes a failed test. Other pipeline tasks throw exceptions instead of just marking the build as a failure, and once the JUnit plugin sets the status, I can't unset that status due to how setResult works in hudson/model/Run. I would really like a parameter to override this default behavior and just throw an exception instead of marking the whole build as a failure.

 

The use cases I've found for something like this are as follows:



  • We use a lot of different parallel tasks in our Jenkinsfiles. Instead of failing the Jenkins build, we prefer to use individually updated status checks on our github PRs that we manage. For example, we might have a check for "Unit Tests" that would get failed, but the job would still be marked as passing. There isn't much value in seeing that the build failed for us, because all that says is one of X types of CI that we run has failed. I would rather leave that passing and only mark the unit test check as failed.

  • When we first introduce a new type of CI task to our Jenkinsfiles, we like to have them not publicly report statuses for the first week or two so that we can verify that there will be no flakiness. In this stage, we cannot use the JUnit plugin or it will force itself to be publicly displayed.

---
Originally reported by spencermalone, imported from: Allow an option for the pipeline step to throw an exception instead of setting the build status.


  • assignee: vlatombe
  • status: In Review
  • priority: Minor
  • component(s): junit-plugin
  • resolution: Unresolved
  • votes: 3
  • watchers: 3
  • imported: 2025-11-26

Raw content of original issue

Sometimes I don't want the junit plugin to mark a build as failed when it publishes a failed test. Other pipeline tasks throw exceptions instead of just marking the build as a failure, and once the JUnit plugin sets the status, I can't unset that status due to how setResult works in hudson/model/Run. I would really like a parameter to override this default behavior and just throw an exception instead of marking the whole build as a failure.

 

The use cases I've found for something like this are as follows:



  • We use a lot of different parallel tasks in our Jenkinsfiles. Instead of failing the Jenkins build, we prefer to use individually updated status checks on our github PRs that we manage. For example, we might have a check for "Unit Tests" that would get failed, but the job would still be marked as passing. There isn't much value in seeing that the build failed for us, because all that says is one of X types of CI that we run has failed. I would rather leave that passing and only mark the unit test check as failed.

  • When we first introduce a new type of CI task to our Jenkinsfiles, we like to have them not publicly report statuses for the first week or two so that we can verify that there will be no flakiness. In this stage, we cannot use the JUnit plugin or it will force itself to be publicly displayed.


Contributor guide

Open the contributing guide

Research direction

Start in the junit-plugin implementation and review the interaction with hudson/model/Run, which the issue identifies as controlling build results. Trace the pipeline step that publishes failed tests and determine how an option should select exception behavior; done means the option is supported without setting the overall build status.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
testing-qa
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
28/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.