generation of management-versions broken

[hadmut]

after pulling the latest version from docker hub:

docker.io/library/rabbitmq latest 9ea1d003602b 11 days ago 236 MB
docker.io/library/rabbitmq alpine bb8a8b47bc3b 11 days ago 158 MB
docker.io/library/rabbitmq 4.0-alpine bb8a8b47bc3b 11 days ago 158 MB
docker.io/library/rabbitmq 4.0-management-alpine 71c2d89dc55f 5 months ago 196 MB
docker.io/library/rabbitmq management-alpine 71c2d89dc55f 5 months ago 196 MB
docker.io/library/rabbitmq management bb7ea3a0230d 5 months ago 274 MB

the versions without the management-plugin are 11 days old, while the versions with the management-plugin are 5 months old.

There seems to be something wrong with the generation process.

[yosifkit]

We set SOURCE_DATE_EPOCH (buildkit docs) while building to the date of the last commit to the build context -- if you want to see the date the build was performed, you'll want to look at the org.opencontainers.image.created annotation we add in the image index (relevant code) instead: https://oci.dag.dev/?image=rabbitmq%3A4.0-management ("org.opencontainers.image.created": "2025-02-12T18:31:16Z").

(Edit: similar issues: docker-library/httpd#266, docker-library/buildpack-deps#166)

[hadmut]

1. This does not make sense and breaks the update mechanism of docker/podman
2. How can rabbitmq with management have an older build context than without?

[yosifkit]

How can rabbitmq with management have an older build context than without?

Because build context has nothing to do with base image (they are FROM rabbitmq:4.0-*) and is just the files committed to git and the */*/management directories have not changed since 36e4d24 but they get rebuilt every time rabbitmq:4.0-* is updated or rebuilt.

[michaelklishin]

@yosifkit thank you for the explanation. I certainly don't recall any cases where the RabbitMQ Core team would suspect that a recent image used out-of-date code.