Skip to content
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

Closed
benbc opened this issue Jun 21, 2016 · 20 comments
Closed

Do official images get rebuilt automatically? #1864

benbc opened this issue Jun 21, 2016 · 20 comments

Comments

@benbc
Copy link
Contributor

benbc commented Jun 21, 2016

Hello

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

Thanks
-Ben

@yosifkit
Copy link
Member

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.

@benbc
Copy link
Contributor Author

benbc commented Jun 24, 2016

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

@yosifkit
Copy link
Member

Only the tags in the library files.

@tianon
Copy link
Member

tianon commented Jun 24, 2016 via email

@benbc
Copy link
Contributor Author

benbc commented Jun 27, 2016

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 benbc closed this as completed Jun 27, 2016
@benbc
Copy link
Contributor Author

benbc commented Jun 27, 2016

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

@benbc benbc reopened this Jun 27, 2016
@tianon
Copy link
Member

tianon commented Jun 27, 2016

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. 😄

@dalanmiller
Copy link
Contributor

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
Copy link
Member

tianon commented Jun 27, 2016

@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 😇

@benbc
Copy link
Contributor Author

benbc commented Jul 26, 2016

@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
Copy link
Contributor Author

benbc commented Aug 1, 2016

@yosifkit, @tianon: Any thoughts on this?

@tianon
Copy link
Member

tianon commented Aug 1, 2016

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. 👍

@benbc
Copy link
Contributor Author

benbc commented Aug 2, 2016

Thanks @tianon, we'll do that.

@benbc benbc closed this as completed Aug 2, 2016
@tianon
Copy link
Member

tianon commented Oct 31, 2018

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
Copy link
Member

tianon commented Oct 31, 2018

cc @jennyowen as well for visibility

@benbc
Copy link
Contributor Author

benbc commented Nov 1, 2018

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

@tianon
Copy link
Member

tianon commented Nov 1, 2018

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

@benbc
Copy link
Contributor Author

benbc commented Nov 1, 2018

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
Copy link
Member

tianon commented Nov 1, 2018

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

@jennyowen
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants