refactor: unify go Dockerfiles and begin setting up Go OSV API#5425
Hidden character warning
Conversation
| - Due to the `replace` directive in `go/go.mod` pointing to the sibling `bindings/` library, Go Docker builds **must** mount the `bindings/` folder into the build context. | ||
| - Since the production Cloud Build steps run inside `dir: 'go'`, they leverage BuildKit's `--build-context` flag to cleanly map the sibling folder without importing other monorepo files: | ||
| ```bash | ||
| docker build -t osv/importer --target importer --build-context bindings=../bindings -f Dockerfile . |
There was a problem hiding this comment.
Can you add to the general contribution docs with these instructions so we know how to build the docker image.
(Also should we have a build docker image command in our makefile?)
There was a problem hiding this comment.
Added to CONTRIBUTING.md and also to the top of the Dockerfile itself.
We shouldn't really need to be building the images themselves regularly since they're all pretty lightweight - basically equivalent to just go run-ing the equivalent command. I don't really think we'd need a Makefile target dedicated to these cases.
There was a problem hiding this comment.
Hmm how fast does esp start up / stop?
One thing that might be useful (which we have for the python api) is to be able to startup the esp part separately from the server. (So I can do fast iterations on the server while keeping the ESP up)
There was a problem hiding this comment.
It seems to be fairly fast - about 2 seconds.
One thing that might be useful (which we have for the python api) is to be able to startup the esp part separately from the server. (So I can do fast iterations on the server while keeping the ESP up)
You mean maybe having a --no-backend flag 🙂
Wanted to set up the things needed for migrating the API to go (including porting code for running REST API locally).
Need to import the API grpc definitions from
bindings/go, which required anreplacedirective ingo.modto keep them synced.The
replacedirective means that every go image built from there needs the bindings folder in its Docker context.To make this easier to maintain, unified nearly all
go/Dockerfiles into a multi-target Dockerfile that they can all build from.