Skip to content

refactor: unify go Dockerfiles and begin setting up Go OSV API#5425

Merged
michaelkedar merged 4 commits into
google:masterfrom
michaelkedar:💬⛔🐍
May 21, 2026

Hidden character warning

The head ref may contain hidden characters: "\ud83d\udcac\u26d4\ud83d\udc0d"
Merged

refactor: unify go Dockerfiles and begin setting up Go OSV API#5425
michaelkedar merged 4 commits into
google:masterfrom
michaelkedar:💬⛔🐍

Conversation

@michaelkedar
Copy link
Copy Markdown
Member

@michaelkedar michaelkedar commented May 20, 2026

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 an replace directive in go.mod to keep them synced.
The replace directive 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.

@michaelkedar michaelkedar requested review from a team and tobyhawker May 21, 2026 00:18
Comment thread go/cmd/api-devserver/main.go
Comment thread go/cmd/api-devserver/main.go Outdated
Comment thread AGENTS.md
- 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 .
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Copy Markdown
Member Author

@michaelkedar michaelkedar May 21, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 🙂

@michaelkedar michaelkedar requested a review from another-rex May 21, 2026 00:47
@michaelkedar michaelkedar merged commit 1f1fa87 into google:master May 21, 2026
26 checks passed
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

Successfully merging this pull request may close these issues.

2 participants