official-images

I have zero internal info, just guessing, but there's a PR from 5min ago asking to add someone as a reviewer for PHP images: https://github.com/docker-library/official-images/pull/22544 Maybe the guy that has to click OK is asleep?

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 was merged a minute ago https://github.com/docker-library/official-images/pull/22541

They even committed the fixed version to the repo, but it seems no images where pushed: https://github.com/docker-library/php/commit/e3eaff845f7a9f7... Edit: Seems like GitHub has issues with merging PRs: https://github.com/docker-library/official-images/pull/22541

That's bad practice because it hides build steps from `docker inspect`. Per https://github.com/docker-library/official-images#clarity: > Try to make the Dockerfile easy to understand/read. It may be tempting, for the sake of brevity, to put complicated initialization details into a standalone script and merely add a RUN command in the Dockerfile. However, this causes the resulting Dockerfile to be overly opaque, and such Dockerfiles are unlikely to pass review. Instead, it is recommended to put all the commands for initialization into the Dockerfile as appropriate RUN or ENV command combinations. To find good examples, look at the current official images.

Debian & Ubuntu provide daily snapshots of their repositories, see snapshot.debian.org and https://ubuntu.com/blog/ubuntu-snapshots-on-azure-ensuring-p... See e.g. https://github.com/reproducible-containers/repro-sources-lis... for how to use them. Also, at least for Debian there are official images available that use snapshot.debian.org as package repository from the get-go – unfortunately those images are not published on a daily basis yet. It seems the overall topic if reproducibility is on the Docker team's to do list, though, see https://github.com/docker-library/official-images/issues/160...

Ubuntu now has snapshot.ubuntu.com, see https://ubuntu.com/blog/ubuntu-snapshots-on-azure-ensuring-p... Here's a related discussion about reproducible builds by the Docker people, where they provide some more details: https://github.com/docker-library/official-images/issues/160...

> In the Alpine ecosystem, it is generally not advised to pin minimum versions of packages. I think it would be more accurate to say, in the Alpine ecosystem, it is generally not advised to pin versions of packages at all. Actually, this is not so much a recommendation as it is a statement of impossibility: You can't pin package versions (without your Docker builds starting to fail in a week or two), period. In other words: Don't use Alpine if you want reproducible (easily cacheable) Docker builds. I had to learn this the hard way: - There is no way to pin the apk package sources ("cache"), like you can on Debian (snapshot.debian.org) and Ubuntu (snapshot.ubuntu.com). The package cache tarball that apk downloads will disappear from pkgs.alpinelinux.org again in a few weeks. - Even if you managed to pin the sources (e.g. by committing the

Indeed. While I do maintain two of them, that maintenance is effectively equivalent to being an open source maintainer or open source contributor. I do not have any non-public knowledge about the Docker Official Images program. My interaction with the Docker Official Images program can be summed up as “my PRs to docker-library/official-images” (https://github.com/docker-library/official-images/pulls/TimW...) and the #docker-library IRC channel on Libera.Chat.

The images you mention (alpine, node, golang) are all so-called “Docker Official Images”. Those are all the ones without a slash as the namespace separator in them: https://hub.docker.com/search?q=&type=image&image_filter=off... They are versioned and reviewed here: https://github.com/docker-library/official-images I don't expect them to go away. Disclosure: I maintain two of them (spiped, adminer).

"AdoptOpenJDK up until now was producing OpenJDK binaries with both Hotspot and OpenJ9 VM's. With Adopt's move to Eclipse, legal restrictions prevent the new Eclipse Adoptium group from producing/releasing OpenJ9 based binaries. As a result, IBM will be producing OpenJ9 based binaries in 2 flavours, Open and Certified, both under the family name IBM Semeru Runtimes. Essentially the same binaries, released under different licenses." Source: https://github.com/docker-library/official-images/pull/10666...

Why the heck isn't there just an official Android container and/or a LineageOS container? It's not a certified device, so. There are a number of ways to build "multi-arch docker images" e.g. for both x86 and ARM: OCI, docker build, podman build, buildx, buildah. Containers are testable. Here's this re: whether the official OpenWRT container should run /sbin/init in order to run procd, ubusd,: https://github.com/docker-library/official-images/pull/7975#... AFAIU, from a termux issue thread re: repackaging everything individually, latest Android requires binaries to be installed from APKs to get the SELinux context label necessary to run?

It doesn't block it, it requires recompiling musl. https://github.com/docker-library/official-images/pull/10779... This is also a response to inclusion of this broken mess into official docker images, I think alpine putting their foot down is entirely justified here.

Monthly typically (and when important security updates are released): https://github.com/docker-library/official-images/pulls?q=is...