Strategy for keeping gRPC definitions and generated files in VCS

Question

I wanted to use gRPC in a system composed of multiple services (each in its own repository) and I was wondering about approach towards versioning in Git:

• *.proto files
• generated code (mostly Go/Java/Python)

So far I was thinking about approach like:

• *.proto files - either:
  1. each definition goes to separate repository
  2. each definition lands in repository of service that implements defined service
• generated code - one of:
  1. goes into the same repository as in 1. above
  2. goes into the same repository as in 2. above
  3. there is no generated code at all - it is generated by built system/script before actual built

I'm not too experienced in gRPC and I have hard time to tell whether one of those is much better/worse than others. I can see some pros and cons of those (like good IDE integration, no need for app that generates code, etc.) but I wonder about some "big" potential problems? Which approach is "best practice"?

Answer 1

General best practice is to keep the generated files out of the repository and to always auto-generate them on build. For example, when you compile Java programs, you don't add any generated .jar files to source control; that's redundant and asking for headaches down the road. The same deal goes for protobuf files.

One can imagine scenarios where it's useful to keep generated files in source control (e.g. as golden files for unit tests), but those are special on a case-by-case basis rather than by general rule of thumb, and may require more complicated machinery to ensure whatever is generated is up-to-date.

Note that this subtly different than distributing generated sources from .proto files. Not every user of your code wants to or has the system able to rebuild from source. By similar analogy, you don't necessarily distribute your Java projects as raw code, but rather as .jar files.