Add CI Workflow for Protocol Buffers #173
Conversation
Reference: #172
| - 'tfprotov6/internal/tfplugin6/*' | ||
|
|
||
| permissions: | ||
| contents: read |
There was a problem hiding this comment.
And this doesn't apply to the filesystem where the generation below will be executed, correct?
I looked on the doc but it wasn't specified, so I assume the filesystem is always accessible for write, but then any attempt to persist the code would fail.
Also, setting only contents leaves all other permissions on the default level, right? I couldn't determine this either.
There was a problem hiding this comment.
contents refers to the REST API endpoints for the repository. It's not intuitive, and I'm not sure where that's documented, but its why permissions such as issues: write is necessary for modifying milestones, since those APIs are related to issues subsystem.
Assigning one of the permissions removes other permissions per this documentation:
If you specify the access for any of these scopes, all of those that are not specified are set to
none.
| contents: read | ||
|
|
||
| jobs: | ||
| protoc: |
There was a problem hiding this comment.
So, this is all good, but I think we should add a couple of things so that the knowledge isn't so "buried".
I was looking for a Makefile in the project to help doing something like make generate (to take care of the code generation). And there is no explanation about this bit of the development workflow in the README.
So I dug up the generate.sh and found:
# We do not run protoc under go:generate because we want to ensure that all
# dependencies of go:generate are "go get"-able for general dev environment
# usability. To compile all protobuf files in this repository, run
# "make protobuf" at the top-level.
So, I suspect this is a rethinking of the original approach (that I frankly don't fully understand because it wasn't explained in the generate.sh either).
Also, that bit above mentions a Makefile that doesn't seem to exist anymore.
I don't come from an "Makefile-heavy" background, but I think it would be preferable if all "developer's default actions" (not sure how to best describe it) were ready made in there. Compared to the README, that is textual description, the Makefile helps on a more "don't tell me, show me" level.
What do you think?
There was a problem hiding this comment.
As a matter of fact, I'd argue that the generate.sh scripts should just be replaced with Makefile commands, given that all the script does is:
- figure out its own directory
- call
protoc
There was a problem hiding this comment.
I'm fine with this change, to be honest. Will push it up.
There was a problem hiding this comment.
Updated! Please take a look and let me know what you think.
| lint: | ||
| golangci-lint run ./... | ||
|
|
||
| # Protocol Buffers compilation is done outside of 'go generate' handling since |
| ### Unit Testing | ||
|
|
||
| Run `go test ./...` or `make test` after any changes. | ||
|
|
||
| ### Linting | ||
|
|
||
| Ensure the following tooling is installed: | ||
|
|
||
| - [`golangci-lint](https://golangci-lint.run/): Aggregate Go linting tool. | ||
|
|
||
| Run `golangci-lint run ./...` or `make lint` after any changes. | ||
|
|
||
| ### Protocol Updates | ||
|
|
||
| Ensure the following tooling is installed: | ||
|
|
||
| - [`protoc`](https://github.com/protocolbuffers/protobuf): Protocol Buffers compiler. | ||
| - [`protoc-gen-go`](https://pkg.go.dev/google.golang.org/protobuf/cmd/protoc-gen-go): Go plugin for Protocol Buffers compiler. e.g. `go install google.golang.org/protobuf/cmd/protoc-gen-go` | ||
| - [`protoc-gen-go-grpc`](https://pkg.go.dev/google.golang.org/grpc/cmd/protoc-gen-go-grpc): Go gRPC plugin for Protocol Buffers compiler. e.g. `go install google.golang.org/grpc/cmd/protoc-gen-go-grpc` | ||
|
|
||
| The Protocol Buffers definitions can be found in `tfprotov5/internal/tfplugin5` and `tfprotov6/internal/tfplugin6`. | ||
|
|
||
| Run `make protoc` to recompile the Protocol Buffers files after any changes. | ||
|
|
Closes #172