Automated PRs for release builds

[dinogun]

Currently it is hard to keep track of release builds as not all versions get GAed at the same time, builds for some arches can be delayed and in some cases we have re-releases with minor version updates as well. Also the dockerfile updates usually have >450 files which makes it difficult to review. The proposal here is to have the following

1. Have a nightly jenkins job to call update_all.sh only for release builds and generate a PR to the openjdk-docker repo if the shasums have changed.
2. Add a check to the PR testing scripts that validates the Dockerfiles for
   a. version mismatches among the various dockerfiles
   b. missing arches in the dockerfiles
3. Provide a daily summary "table" in the nightly builds that provide a quick visual summary of the builds (>200 builds)
   a. Arch-wise table that highlights any builds failures
   b. Append data for each version in the ./build_all.sh loop against hotspot/openj9, jdk/jre
   c. Table gets printed at the end of the run, so easy to get a summary at the end of the logfile

[aahlenst]

This is a common problem we have across multiple repositories (Homebrew, Docker, Linux packages). I'd prefer an event-based approach that triggers jobs on releases being pushed (that happens manually by triggering a script in Jenkins). So there would be no need to wait for ~23 hours in the worst case. Would be great if we could solve that for every repository or even have a bot that automatically creates PRs.

[dinogun]

This is a common problem we have across multiple repositories (Homebrew, Docker, Linux packages). I'd prefer an event-based approach that triggers jobs on releases being pushed (that happens manually by triggering a script in Jenkins). So there would be no need to wait for ~23 hours in the worst case. Would be great if we could solve that for every repository or even have a bot that automatically creates PRs.

Fully agree on a common trigger that can create PRs. A couple of things to consider would be, releases that are deferred over time, this would be mean several incremental PRs, instead of just one (which should be ok), secondly ensuring the trigger takes into account re-releases and any other issues with releases.

However we can still ensure that the script is ready and tested with a jenkins job until the above infra is made available.

[smlambert]

Related: DockerScannerTool creates a list of recently changed images (as we wanted to add some way to let us know what changed to inform testing).

https://github.com/AdoptOpenJDK/openjdk-docker/tree/master/tests/scanner for documentation.