-
-
Notifications
You must be signed in to change notification settings - Fork 1k
Add docker build on release #888
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
Conversation
|
What are your thoughts, @deepmap-marcinr? Not sure if this fits within your thoughts about what we'd want to maintain in this project, but looks like a few folks are interested in it. |
84e8db7 to
4769a2d
Compare
|
What's the reasoning behind this? To |
For example to use it in CI, as docker image for stage. |
|
So? Any updates? |
|
How is this going to look like in terms of releases to ghcr or docker hub or whatever? It looks like it's automatic whenever I push a release - but now, I have to worry about exceeding storage or access quotas, because people will complain when this fails. I'm open to doing something like this, the process with github actions looks simple, but I think maybe I'd need to push it to dockerhub after setting up my own account there. Is there any particular reason to use one over the other? I've only ever consumed from public docker repositories, never produced. |
Depends on you want to use =) I can provide Action for push to Dockerhub, if you want =) And there is cool feature Automated builds in Dockerhub, but it works only for paid accounts. |
- Add Dockerfile - Add GitHub workflow
4769a2d to
5c59043
Compare
|
Any updates here? Would like to see it happening. |
|
I'd like to see an update here as well. Having a docker image drastically improves adoption. For some companies/developers it's a no-go if they have to check out a repo or install something in a not so streamline way. Docker helps with that. All the cli tools you want/need can be just inside containers and don't bloat the host system. They can be easily removed as well and using other versions of the software doesn't require and weird procedures. Just changing the version tag. |
|
So? Seems like not only me ask for this feature =) But 6 months passed from first push... |
|
I am happy to merge the Dockerfile and Makefile changes to produce a container image, however, I'm in a tight spot with where to host this docker image. Deepmap got acquired by a large company which has all kinds of licensing requirements and internal requirements around shipping binaries, because it opens us up to liability in case we accidentally ship a virus or malware or something. I'm no longer in a position where I have the authority to make these decisions. So, could I propose that we commit the build into this repository, but not the action hook which publishes it? Then, maybe someone who doesn't have these constraints can publish an image. I can link to it in the readme, but mention that it's not supported. |
|
Hey @deepmap-marcinr is it right that we're maybe in a state we may need to close this as a "can't do, legally"? |
jamietanna
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just awaiting Marcin's thoughts, after which we can look at some follow up changes
[feat] Update alpine version [feat] Add possibility to change base image
|
What's the status here? I would really like this to be merged |
|
Hey folks, I've opened this page a couple of times recently to draft a reply. The short answer is, nothing yet - there's some behind the scenes stuff which hopefully should make this progress, but until then, Marcin's comment above still holds about us not being able to serve the image. Am eagerly hoping to have an answer for this before long! |
|
Just a quick x-post of #937 (comment) here as it's a fairly similar change and is worthwhile us considering a bit more |
|
One thing I also want us to make sure we think about with this is how we'll respond to CVEs in the underlying container (i.e. I don't want to have to have folks chasing us for "hey there's a completely unrelated CVE in the container, please fix") |
|
A FROM SCRATCH image could be used with just the built go binary. Then there are no such CVEs, correct? |
|
Correct yes, so chances are this proposal would avoid the CVE concerns, as we'd distribute |
Already done in my PR ) |
|
Any progress on this? Ideally a stage in my CI (publishing generated Go files as a package) will run |
|
Hey folks, apologies for the delay on the final decision here - we've decided not to proceed with a Docker image for
We welcome a community-maintained container image - but at this point, this isn't something we're going to be maintained upstream At some point, we may reconsider this, at which point we'll distribute both a container image and a pre-built binary. Thanks for your patience + understanding! |
release publishedevent