Skip to content
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

Use Bazel to build the entire backend and perform API code generation #609

Merged
merged 6 commits into from
Jan 5, 2019

Conversation

neuromage
Copy link
Contributor

@neuromage neuromage commented Jan 3, 2019

Using Bazel means we'll get reproducible builds that are not dependent on the tools installed by each dev. This change adds BUILD files for the backend that builds both binaries, as well as the API protocol buffers and swagger definitions.

In order to let go build and go test work as before, the Makefile is replaced with a script that uses Bazel to first generate the API code, and then copy them back into the source tree.

Most of the BUILD files were generated automatically using Gazelle.

Apologies for the large PR but this is hopefully a one time change. From here on, running bazel //:gazelle should update the BUILD files automatically.

We may also want to consider not checking in generated code altogether. This may be a better option going forward.


This change is Reviewable

This also uses Bazel to generate code from the API definition in the
proto files.

The Makefile is replaced with a script that uses Bazel to first generate
the code, and then copy them back into the source tree.

Most of the BUILD files were generated automatically using Gazelle.
@neuromage
Copy link
Contributor Author

Note: the changes in the generated files are due to using more up to date versions of the code generation tools.

@neuromage
Copy link
Contributor Author

/cc @vicaire
/cc @yebrahim
/cc @IronPan

Copy link
Contributor

@yebrahim yebrahim left a comment

Choose a reason for hiding this comment

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

It would be great to close on checking-in auto-generated code. If bazel simplifies the build and we have all of our dependencies pinned down, I'm in favor of maintaining the fewest sources of truth. (To quickly follow this up, if a tool can generate the BUILD files, why are we checking them in?)

My opinion: if we have good reasons for checking in auto-generated files, let's discuss them here. Let's remove them otherwise.

@@ -0,0 +1,3 @@
// +build ignore
Copy link
Contributor

Choose a reason for hiding this comment

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

Why are these files needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There are auto-generated. I have no idea how this works. It also varies depending on the version of protoc-gen-grpc that we use.

name=$(basename ${f})
cp $f go_client/${name}
chmod 766 $f
${AUTOGEN_CMD} -i --no-tlc -c "Google LLC" -l apache go_client/${name}
Copy link
Contributor

Choose a reason for hiding this comment

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

It seems like this line didn't work in the checked in sources, they're missing the license headers.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry, something must have gone wrong when I was merging with master. I re-ran the script and generated the licenses.

WORKSPACE Outdated
tag = "v1.1.1",
)

# go_repository(
Copy link
Contributor

Choose a reason for hiding this comment

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

Was this generated this way? Why would the tool comment this out?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry I commented that out. Removed it, as we don't need it. The proto types are built into the rules now.

@yebrahim
Copy link
Contributor

yebrahim commented Jan 3, 2019

Can you also add a backend/README file that explains how to build the backend, and what the build toolset is? Is it just bazel? What version.. etc?

Copy link
Member

@IronPan IronPan left a comment

Choose a reason for hiding this comment

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

could you use wildcard for all src[] section of the bazel file? so that it doesn't need to be manually maintained?

@@ -20,6 +20,7 @@ import "google/api/annotations.proto";
import "google/protobuf/empty.proto";
import "google/protobuf/timestamp.proto";
import "protoc-gen-swagger/options/annotations.proto";
import "backend/api/error.proto";
Copy link
Member

Choose a reason for hiding this comment

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

is this change required or by accident?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is required. Note the ".api.Status" which is the default response below. When generating swagger.json files, the error.proto file is what contains the Status message, and it must be visible to this file so that protoc_gen_swagger BUILD rule can generate the right swagger definitions. Otherwise, it's an error. This took me forever to figure out! :-)

Copy link
Member

Choose a reason for hiding this comment

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

thanks for confirm.

go_library(
name = "go_default_library",
srcs = [
"error.pb.go",
Copy link
Member

Choose a reason for hiding this comment

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

can this be wildcard *.pb.go *.pb.gw.go? otherwise this need to manually added in the future i guess?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There's actually no need to manually manage these. Just run bazel run //:gazelle to auto update the BUILD files. I added a README with these instructions.

@@ -1,28 +1,12 @@
// Copyright 2018 Google LLC
Copy link
Member

Choose a reason for hiding this comment

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

headers seems gone here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry, re-ran the script and added them back. Think something went wrong when I was merging.

Also fix the missing licenses in the generated proto files.
@neuromage
Copy link
Contributor Author

I added a README with instructions on how to build/test with bazel. The BUILD files don't need to be manually maintained, for the most part, running bazel run //:gazelle will auto-update them.

As for whether we should keep checking generated code in, here are the pros and cons as I see them:

Pros:

  • go build and go test continue to work as before. No need to change build/release process as yet.
  • IDE/Editors see the generated code, and don't need special Bazel plugins to auto-complete on them.

Cons;

  • Generated code changes are noisy during code reviews
  • Spurious merge conflicts to resolve when changes touch proto files.

If we do decide to remove them, my preference is to do that in a separate PR.

@yebrahim
Copy link
Contributor

yebrahim commented Jan 3, 2019

Thanks Ajay. Looks like there's still some generated files missing the license headers.
Is there value in checking in the BUILD files if they're all auto-generated? Can the gazelle build rule be run before running the rest of the bazel rules? This way we can just add them to .gitignore.

@yebrahim
Copy link
Contributor

yebrahim commented Jan 3, 2019

I guess it's a good idea to discuss maintaining auto-generated files in a separate issue so as not to block this PR on it, but it's good to make sure we really need any new generated files.

@neuromage
Copy link
Contributor Author

Thanks for catching that! Added the missing license for files under go_http_client, and fixed the script so this won't happen again.

We will need to check in BUILD files. The files are only mostly autogenerated. I made some changes (see lines that have #keep in them) to make sure everything compiles and tests correctly. Also, auto generation only works for Go. Other languages will require more manual BUILD file work. It's standard to check these in in projects that use Bazel. I think we should do the same.

@yebrahim
Copy link
Contributor

yebrahim commented Jan 3, 2019

SG then.
/lgtm

@k8s-ci-robot k8s-ci-robot removed the lgtm label Jan 4, 2019
@IronPan
Copy link
Member

IronPan commented Jan 5, 2019

/lgtm
/approve

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: IronPan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

1 similar comment
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: IronPan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@IronPan
Copy link
Member

IronPan commented Jan 5, 2019

Thanks for the change

@k8s-ci-robot k8s-ci-robot merged commit 163545b into kubeflow:master Jan 5, 2019
HumairAK pushed a commit to red-hat-data-services/data-science-pipelines that referenced this pull request Mar 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants