It would not be easy (or reasonable) to take a public build like that private to build a 'secret' image version, and I'm not sure GitHub even has the capability to do that. I would not trust a build pushed to Docker Hub separate from the established / public / auditable process they have in place.
All dependent (official) images need to go through the same process, so that makes it fairly problematic, and I think Docker needs to take a look at it for the future.
A PR was posted within a minute or two of PHP's source code update. Then within a minute of the PR's CI job completing, it was merged, and the build took a while but is now complete: https://github.com/docker-library/php/actions/runs/396158697...
It would not be easy (or reasonable) to take a public build like that private to build a 'secret' image version, and I'm not sure GitHub even has the capability to do that. I would not trust a build pushed to Docker Hub separate from the established / public / auditable process they have in place.
This is just the first step. See here for the full process: https://github.com/docker-library/faq#an-images-source-chang...
All dependent (official) images need to go through the same process, so that makes it fairly problematic, and I think Docker needs to take a look at it for the future.
Ah, indeed... I thought the GA push was the final step but there's another manual process between that and updating the Docker Hub image tags: https://github.com/docker-library/official-images/pull/22541
It should definitely have a 'high impact' workflow that bypasses some of those manual steps.
It would however be reasonable to expect a maintainer to be available to start the CI faster than 30 minutes after the PR was created.
The maintainer isn't getting paid enough to react with that much speed.