deepmap
Add docker build on release
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.
What's the reasoning behind this? To docker run oapi-codegen instead of using go install to get it?
What's the reasoning behind this? To
docker run oapi-codegeninstead of usinggo installto get it?
For example to use it in CI, as docker image for stage. Also i don't need to control and check what the version is currently installed, just use docker image with tag I need.
So? Any updates? If you are struggle to prevent providing Dockerfile and image, I can just make my project with dependabot and reference to yours repo) Imho, project could be fully self-maintained and let users more convenient service of usage)
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.
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.
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... Any updates? Or I must to create just side project with dependabot automation and custom image?
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"?
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 https://github.com/oapi-codegen/oapi-codegen/pull/937#issuecomment-2208548688 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 FROM scratch 👍🏼