-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do official images get rebuilt automatically? #1864
Comments
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 #1235. |
Thanks @yosifkit. Does this happen for all tags, or only those still in the library definition file? |
Only the tags in the library files. |
(which is the explicit set of "supported tags")
|
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. |
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. 😄 |
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? |
@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 😇 |
@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? |
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. 👍 |
Thanks @tianon, we'll do that. |
I think we need to revisit this. We're currently at 130 unique "supported" |
cc @jennyowen as well for visibility |
@tianon Would it be sufficient for us to prune out some of the old images rather than changing the strategy completely? |
It would definitely help! How many did you have in mind? |
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. |
Yeah, that would make a huge difference -- I think it'd be fine to start with that and see how it goes. 👍 |
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. |
Hello
Do the images in the official library get regularly rebuilt to pick up security updates to the base images?
Thanks
-Ben
The text was updated successfully, but these errors were encountered: