-
Notifications
You must be signed in to change notification settings - Fork 137
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
Fix all the dynamically generated code #547
Conversation
e2f1eef
to
da146ba
Compare
Codecov Report
@@ Coverage Diff @@
## main #547 +/- ##
=======================================
Coverage 34.76% 34.76%
=======================================
Files 44 44
Lines 3348 3348
=======================================
Hits 1164 1164
Misses 2085 2085
Partials 99 99 Continue to review full report at Codecov.
|
da146ba
to
ef240d4
Compare
- name: make verify | ||
run: make verify |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @tstromberg I modified this so it checks more than just lint steps. I think its in line with the idea behind lint-install's lint
.
all: cli server worker ## Build all binaries for host OS and CPU | ||
|
||
-include rules.mk | ||
-include lint.mk |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved the lint-install
managed stuff here as I'd like to keep the Makefile as simplish as possible... lesson learned from osie's ;)
grpc/gen_doc: | ||
protoc \ | ||
-I./protos \ | ||
-I./protos/third_party \ | ||
--doc_out=./doc \ | ||
--doc_opt=html,index.html \ | ||
protos/hardware/*.proto protos/template/*.proto protos/workflow/*.proto |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@displague I got rid of this because I couldn't find where it used. I don't think it is right? I'd love to use it but am not sure how we'd integrate the generated files (html or even markdown...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn't find anywhere it was used. We could potentially have a reference section in the docs with API schemas. When we are using K8s CRDs for storage, a section in the docs site might be especially helpful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For that I'd expect the docs repo to clone and be the one calling protoc-gen-doc right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. K8s does something similar with submodules (not that we should do the same, just a reference point). At the point we want autogenerated API docs, we can add back some doc gen make targets
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:nod:
ef240d4
to
b6250b3
Compare
.github/workflows/ci.yaml
Outdated
uses: actions/setup-go@v2 | ||
with: | ||
go-version: "1.14.6" | ||
- name: gofumpt |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The golangci-lint config already includes gofumpt.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah I thought lint-install did that and I didn't find it. will drop.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
its been dropped
b6250b3
to
ca2166e
Compare
ca2166e
to
b4465b6
Compare
grpc/gen_doc: | ||
protoc \ | ||
-I./protos \ | ||
-I./protos/third_party \ | ||
--doc_out=./doc \ | ||
--doc_opt=html,index.html \ | ||
protos/hardware/*.proto protos/template/*.proto protos/workflow/*.proto |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn't find anywhere it was used. We could potentially have a reference section in the docs with API schemas. When we are using K8s CRDs for storage, a section in the docs site might be especially helpful.
export PATH | ||
endif | ||
|
||
toolsBins := $(addprefix bin/,$(notdir $(shell awk -F'"' '/^\s*_/ {print $$2}' tools.go))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this directory be used for other things too? I'm thinking about #542
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, if you update tools.go with the ref to the cmd you can update your makefile bits to depend on bin/$name and it'll all work out. So far I'm digging this pattern quite a bit over explicitly installing tools via make.
|
||
.PHONY: pbfiles | ||
pbfiles: buf.gen.yaml buf.lock $(shell git ls-files 'protos/*/*.proto') $(toolsBins) | ||
buf generate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this download the imported google protobuf definitions? do those need to be added to .gitignore
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep it does download them, but into a buf managed cache dir. The files never land into somewhere git sees.
Lets keep the Makefile easy to read. Signed-off-by: Manuel Mendez <[email protected]>
We already did .yml, but missed .yaml extension. Signed-off-by: Manuel Mendez <[email protected]>
gofumpt is goimports++. Signed-off-by: Manuel Mendez <[email protected]>
Also sets up the PATH so the binaries will be used by other steps. Signed-off-by: Manuel Mendez <[email protected]>
Signed-off-by: Manuel Mendez <[email protected]>
Signed-off-by: Manuel Mendez <[email protected]>
Its not used at the moment, so lets get rid of it until we have a use. Signed-off-by: Manuel Mendez <[email protected]>
Signed-off-by: Manuel Mendez <[email protected]>
The old code was just plain broken and did not generate anything. Signed-off-by: Manuel Mendez <[email protected]>
Signed-off-by: Manuel Mendez <[email protected]>
Makes more sense for a phony target, no need for the subdir in it. Also add a dep on bin/moq for correctness. Signed-off-by: Manuel Mendez <[email protected]>
Signed-off-by: Manuel Mendez <[email protected]>
Signed-off-by: Manuel Mendez <[email protected]>
Signed-off-by: Manuel Mendez <[email protected]>
Signed-off-by: Manuel Mendez <[email protected]>
Going off of the go grpc example from buf [tour]. tour: https://docs.buf.build/tour/generate-go-code/ Signed-off-by: Manuel Mendez <[email protected]>
Signed-off-by: Manuel Mendez <[email protected]>
Signed-off-by: Manuel Mendez <[email protected]>
I don't want to wire up the buf based generation as a dependendency of the binary targets as its almost always a waste of time. I'd rather be able to build quickly and leave CI and/or explicit check to catch the stale files. Signed-off-by: Manuel Mendez <[email protected]>
buf does it all, manages dependencies and invokes protoc. No need for 2 separate tools. Signed-off-by: Manuel Mendez <[email protected]>
Verify will no verify that generated files are up to date, along with its previous checks of lint free and formatted correctly. Signed-off-by: Manuel Mendez <[email protected]>
This way we check more than just linting and don't need to have one job for each and every check. Signed-off-by: Manuel Mendez <[email protected]>
Signed-off-by: Manuel Mendez <[email protected]>
b4465b6
to
c06dde1
Compare
Lots of fixes to stuff that is dynamically generated along with a few extra bits here and there in related code to make things better.
go generate
callsMostly fixes for dynamically generated files.
I noticed that #541 had some protobuf format commits which I was not expecting being done separately. I went looking into it and noticed the mess we're in.
How Has This Been Tested?
CI
How are existing users impacted? What migration steps/scripts do we need?
Will have better automation for messing with generated files.
Checklist:
I have: