[JENKINS-75082] Include test results in build status notification

[ugrave]

Include test result in build status notification.

The results are summaries from all available AbstractTestResultAction`s. To post test result to junit plugin must be installed. If the junit plugin is not installed not test results are included into the build status notification.

The junit plugin is added as optional dependency.

Publishing of test results is not only limited to junit plugin. Ex the TestNG plugin is also extending the AbstractTestResultAction.

Publishing of test result is not supported by bitbucket cloud.

Fixes https://issues.jenkins.io/browse/JENKINS-75082

Your checklist for this pull request

• [x] Make sure you are requesting to pull a topic/feature/bugfix branch (right side) and not your master branch!
• [x] Ensure that the pull request title represents the desired changelog entry
• [x] Please describe what you did
• [x] Link to relevant issues in GitHub or in Jenkins JIRA
• [x] Link to relevant pull requests, esp. upstream and downstream changes
• [x] Did you provide a test-case? That demonstrates feature works or fixes the issue.

[nfalco79]

The issue JENKINS-75082 must not be implemented adding JUnit as dependency. As the TODO you removed in this PR the way will be through an extension point so that any kind of unit test plugin can partecipate to enrich (not only test information) to the build status. Maybe enrich depends (not yet decided) on the build status, does not make sense for example inject test cases information when build start.

[KalleOlaviNiemitalo]

@nfalco, would it be ok to add BitbucketBuildStatus.TestResults and related accessors and cloning changes here, without the junit-plugin dependency? Or would you prefer that the json serialisation of test results in Bitbucket API requests be also implemented in an extension plugin?

[nfalco79]

Or would you prefer that the json serialisation of test results in Bitbucket API requests be also implemented in an extension plugin?

I would like but I think that is not possible because client have different class. I have an idea how I would realise but I not know yet. I though something like:

...
buildStatus.setParent(notificationParentKey);
original = clone buildStatus
for each listener {
    tmp = clone buildStatus
    // listener could contribute, enrich or override anything except unmodifiable fields
    buildStatus = listener.enrich(buildStatus, build);
    // useful in case of bug
    if tmp not equals buildStatus {
        logger.info(listener class change notification);
    }
}
restore unmodificable fields like key, url, status, ... from original to tmp
notifier.notifyBuildStatus(buildStatus);
...

I could think if create a new trait so the user can select which listeners are enabled for this project instead to apply all indiscriminately.

[nfalco79]

Superseded by #1101