Official-images: Do official images get rebuilt automatically?

[benbc]

Hello

Do the images in the official library get regularly rebuilt to pick up security updates to the base images?

Thanks
-Ben

[yosifkit]

Yes, we do periodic updates on the base images like Debian and Ubuntu which we then rebuild all descendant images. The base or affected images are also recreated when there is a major vulnerability, like https://github.com/docker-library/official-images/issues/1235.

[benbc]

Thanks @yosifkit. Does this happen for all tags, or only those still in the library definition file?

[yosifkit]

Only the tags in the library files.

[tianon]

(which is the explicit set of "supported tags")

[benbc]

Thank you. We have not fully thought through the need to keep rebuilding old images, so we've been removing tags for superseded point releases from the library file despite their still being supported.

[benbc]

@yosifkit @tianon Do you, as the library maintainers, have a preference for whether images retain tags for superseded point releases?

[tianon]

Our stance is usually one that's best described by example IMO. If there were a version 1.1.2 and a problem were discovered with it, would there be a 1.1.3 or a 1.1.2.1 or something? Would there be a new release which fixes the issue? If the answer is yes, that's what I consider to be "supported" (in the sense that issues with the software itself, not just the Dockerization, will be fixed).

That being said, we're willing to discuss further on a case-by-case basis if there are special considerations that ought to be made. :smile:

[dalanmiller]

Another question somewhat related to this. I see that in my public docker hub projects there's a webhook option. Would it be possible to be notified if builds succeed or fail via the webhook?

[tianon]

@dalanmiller I think that question is likely more appropriately directed at Docker's support team (via [email protected]) -- we aren't part of the automated builds team, and can't really speak to the feature set there :innocent:

[benbc]

@tianon We (the Neo4j maintainers) have given some more thought to this and to security concerns generally. We're uncomfortable with expecting our users to upgrade to the latest point release of Neo4j in order to get security fixes to the underlying platform.

Would you object to us leaving tags for all point releases of supported versions in our library files so that our users can fix the Neo4j version but still benefit from security patches to the OS etc?

[benbc]

@yosifkit, @tianon: Any thoughts on this?

[tianon]

Sorry, @benbc! It's not great, and I wish we had a better way to handle it, but I suppose it sounds reasonable. It's probably worth including a comment in the library file linking to this discussion noting why they're present. :+1:

[benbc]

Thanks @tianon, we'll do that.

[tianon]

I think we need to revisit this. We're currently at 130 unique "supported" neo4j tags (with #5018 adding two more), and running the entire test suite across all of them takes a very long time (going on nearly two hours now for the build test on that latest PR), which seems to be roughly how long it takes our official server to build them all too.

[tianon]

cc @jennyowen as well for visibility

[benbc]

@tianon Would it be sufficient for us to prune out some of the old images rather than changing the strategy completely?

[tianon]

It would definitely help! How many did you have in mind?

[benbc]

I'm sure that we could remove at least half of them. Would that be enough to solve your problem? We would change our process to routinely prune out old releases when cutting new ones.

[tianon]

Yeah, that would make a huge difference -- I think it'd be fine to start with that and see how it goes. :+1:

[jennyowen]

OK then! We'll be doing another release in a day or so. I'll prune away some of the cruft and push it then.