-
Improvement
-
Resolution: Unresolved
-
Minor
-
None
The main role of the plugin is to update the issues but this is not a build plugin, but a build-reference plugin. So as far as my understanding of workflow is concerned, this should not fail builds by default.
That being said, because it already does... I think we could introduce a switch "fail build when updating JIRA fails", that is on by default.
This needs to take two scenarios in consideration:
- JIRA is not/improperly configured so no update was successful
- at least one update was successful.
This is because there is a JiraCarryOverAction now implemented.
- links to
We also need this behaviour for our use case.
Many of our projects use a shared library which runs the Jira issue updater: many projects might have not configured their Jira Site, so the build is marked as failed and the project members don't know why. We need to have the Jira issue updater as an optional feature.
We tried to find a workaround, like checking if the Jira Site has been configured before running the issue updater, but it seems too complex and unwieldly. (getting the parent organization's config.xml from within the pipeline build, setting the build result back to SUCCESSFUL doesn't work because result can only worsen...)
On top of it, there's a statement in our shared library which checks if the build has been marked as failed by the Warnings plugin; and if so aborts the build. This leads to our pipelines aborting the builds when the Jira site is not configured. The Warnings plugin execution is also skipped when the build is marked as failed.