| Currently, when the dependencyTrackUpload step encounters an error, it sets the build status to FAILURE. This is a one-way trip. It is not possible for users of the step to catch and recover from these errors, as there is no way to downgrade the build status from FAILURE. It would be much better, and more in the style of most other build steps, for dependencyTrackUpload to throw an exception when it encounters an error. Preferably different exceptions for configuration problems (e.g. unable to contact the deptrack server) vs threat threshold violations. That way: a) by default, builds will abort immediately when the dependencyTrackUpload step encounters an error, rather than silently continuing on with further steps and then marking the build as failed after all the other steps complete, which might have included continuous deployment steps. b) users who want to suppress dependencyTrackUpload errors can do so via a try/catch block around the step, and then provide whatever custom build status handling they'd like. |
