Add reproducibility percentage to daily build summary

[adamfarley]

Where we have implemented testing for a reproducible build, this code ensures that the results of that testing are included in the daily build summary.

If we did try to run the tests, but failed for whatever reason, we provide a short summary of the relevant platforms and provide a lot more information in the "details" link to the jenkins job that generates the summary, as well as useful links.

Resolves #1091

[github-actions]

Thank you for creating a pull request!

Please check out the information below if you have not made a pull request here before (or if you need a reminder how things work).

Code Quality and Contributing Guidelines

If you have not done so already, please familiarise yourself with our Contributing Guidelines and Code Of Conduct, even if you have contributed before.

Tests

Github actions will run a set of jobs against your PR that will lint and unit test your changes. Keep an eye out for the results from these on the latest commit you submitted. For more information, please see our testing documentation.

In order to run the advanced pipeline tests (executing a set of mock pipelines), it requires an admin to post run tests on this PR.
If you are not an admin, please ask for one's attention in #infrastructure on Slack or ping one here.
To run full set of tests, use "run tests"; a subset of tests on specific jdk version, use "run tests quick 11,21"

[andrew-m-leonard]

Just one comment on the significance of "10" ?

[andrew-m-leonard]

I've updated the live Slack job to use this PR, to see how it looks for a few days...

[adamfarley]

@andrew-m-leonard - Thanks for the reviews. I've tweaked the relevant code. Let me know if this works for you. :)

[andrew-m-leonard]

@andrew-m-leonard - Thanks for the reviews. I've tweaked the relevant code. Let me know if this works for you. :)

@adamfarley I've just done a run using your latest code: https://adoptium.slack.com/archives/C09NW3L2J/p1728486568438139

The jdk-21.0.5+9-ea has run with tests enabled... here: https://trss.adoptium.net/allTestsInfo?buildId=66ff33dad24e1b006e7b75f0&limit=1&hasChildren=false
so we need to check why it thinks tests were disabled....?

[adamfarley]

@andrew-m-leonard - Thanks for the reviews. I've tweaked the relevant code. Let me know if this works for you. :)

@adamfarley I've just done a run using your latest code: https://adoptium.slack.com/archives/C09NW3L2J/p1728486568438139

The jdk-21.0.5+9-ea has run with tests enabled... here: https://trss.adoptium.net/allTestsInfo?buildId=66ff33dad24e1b006e7b75f0&limit=1&hasChildren=false so we need to check why it thinks tests were disabled....?

Ok, I think I've fixed it. I'm rerunning the test job now.

[andrew-m-leonard]

This "getInProgressBuildUrl" was originally added to purely see if A build was in-progress for the given tag, regardless of what platform, is was just a "rough" status as to "is there anything still going...?"
Thus it's intention was not for finding a "specific" build, which is what I think we need now, the situation can be that in TRSS there could be several entries for a given tag say "jdk-21.0.5+9-ea", which has 334 and 335, as Windows_aarch64 was re-run... As it stands the above will find 335(WindowsAarch64) and incorrectly think no ReproducibleTest ran for x64Linux, which is in 334.

We could update verifyReleaseContent() to add the list of platforms that were found/built to the status[] json (eg.status['foundAssets']), and update getBuildUrl to take a build platform, and find the TRSS build entry for the given tag that has that build platform...?