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
Push Protobufs to Buf Schema Registry #4923
Conversation
uses: bufbuild/buf-push-action@v1 | ||
with: | ||
input: apis | ||
buf_token: ${{ secrets.BUF_TOKEN }} |
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.
Unfortunately the Buf Schema Registry doesn't seem to support robots, so I'll need to create a token associated with my account and use that. We'll also need at least one other maintainer to create an account for redundancy.
This registry generates us documentation. I believe it also allows us to avoid copying around protobuf files, which we currently need to do for each SDK (e.g. https://github.com/crossplane/function-sdk-go/tree/main/proto). Signed-off-by: Nic Cope <nicc@rk0n.org>
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.
Directionally, this seems reasonable, and we could always change direction in the future if we wanted more direct integration of some fashion with docs.crossplane.io.
A few question about the expected workflow here, but overall this is reasonable.
@@ -0,0 +1,7 @@ | |||
# Generated by buf. DO NOT EDIT. |
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.
what's the expected workflow for this type of file being updated? is it something a developer will ever need to do with the buf
tooling and include in a PR?
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.
Exceedingly rarely. The command is buf mod update
, which I've mentioned in #4924 for now.
with: | ||
input: apis | ||
|
||
- name: Detect Breaking Changes in Protocol Buffers |
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.
should there be a local part of the workflow here? e.g. make reviewable
does this same check so devs can have confidence in their commit before opening a PR?
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.
It would be nice to have, but I feel a sense of urgency to have something in place and I don't want to take on teaching the Makefile and/or build submodule about buf
right now. I've raised #4924 to track this.
/backport |
Git push to origin failed for release-1.14 with exitcode 1 |
Description of your changes
This registry generates us documentation. I believe it also allows us to avoid copying around protobuf files, which we currently need to do for each SDK (e.g. https://github.com/crossplane/function-sdk-go/tree/main/proto). The
buf
tool is OSS but the Schema Registry is a commercial product of https://buf.build. It does appear to be free for OSS use.Example docs: https://buf.build/crossplane/crossplane/docs/main:apiextensions.fn.proto.v1beta1
I'd like to link to these docs from https://docs.crossplane.io.
I have:
make reviewable
to ensure this PR is ready for review.Added or updated unit tests.Added or updated e2e tests.Linked a PR or a docs tracking issue to document this change.Addedbackport release-x.y
labels to auto-backport this PR.Need help with this checklist? See the cheat sheet.