Skip to content

Generating Go Bindings with Docker #180

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

Closed

Conversation

akutz
Copy link
Contributor

@akutz akutz commented Jan 31, 2018

This patch introduces the ability to generate Go language bindings using
Docker with Dockerfile-go:

# builds the container image
$ docker build -t csi/spec -f Dockerfile-go .

# emits the go bindings to stdout
$ docker run --rm csi/spec

# emits the protobuf to stdout
$ docker run --rm csi/spec csi.proto

This patch introduces the ability to generate Go language bindings using
Docker with `Dockerfile-go`:

        # builds the container image
        $ docker build -t csi/spec -f Dockerfile-go .

        # emits the go bindings to stdout
        $ docker run --rm csi/spec

        # emits the protobuf to stdout
        $ docker run --rm csi/spec csi.proto
@saad-ali
Copy link
Member

I like the idea of containerizing the build process. How do you envision this being used? Would Makefile be modified to build and run the container?

@akutz
Copy link
Contributor Author

akutz commented Jan 31, 2018

Hi @saad-ali,

This is just a short-cut for now. Ultimately, even if the Travis-CI build went to sudo mode to utilize this process, we'd still want to employ dep to manage the protobuf dependency to make sure it and its dependency graph are pinned at known versions.

So, in other words, the first step is merging #113, then building on that with this to have the option to do a Docker build with known dependencies and required tools, such as protoc.

@akutz
Copy link
Contributor Author

akutz commented Jan 31, 2018

Hi @saad-ali,

Additionally, I'd likely publish csi/spec as an executable image rather than what it is now, a way to build the current spec.md into the generated output. As an executable image it would simply consume spec.md and emit the desired output, ex. csi.proto, csi.pb.go, etc. I started down this path in fact except that the default golang Docker image doesn't have the unzip command in it, and I could not use it to get and inflate the protoc zip file needed to do the one-liner.

@akutz
Copy link
Contributor Author

akutz commented Jan 31, 2018

However, even as an executable image, we'd still need dep to manage the Go dependency graph as no one wants to use go get to get random dependencies based on HEAD revisions. So if we need dep and its Gopkg files regardless, why not use the ones in #113 as a starting point?

FROM alpine:3.7
RUN mkdir /csi
WORKDIR /csi
COPY --from=0 /csi/csi.pb.go .
Copy link
Contributor

Choose a reason for hiding this comment

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

Just a nit, you can name each stage with FROM golang:1.9.3 AS build and then use COPY --from=build

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi @cpuguy83,

Thanks! I've actually done that, but since this was a single stage being referenced I didn't care.

@cpuguy83
Copy link
Contributor

Would Makefile be modified to build and run the container?

Ideally the Makefile would not require a container.

@akutz
Copy link
Contributor Author

akutz commented Jan 31, 2018

Hi @cpuguy83 and @saad-ali,

Ideally the Makefile would not require a container.

Exactly. I'm working on an update to this that will be what we want (I think).

@akutz
Copy link
Contributor Author

akutz commented Feb 1, 2018

Replaced by #181

@akutz akutz closed this Feb 1, 2018
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.

3 participants