feat(grpc): add golang gRPC client code package#874
feat(grpc): add golang gRPC client code package#874slin1237 merged 9 commits intolightseekorg:mainfrom
Conversation
|
Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits. |
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a comprehensive Go module for gRPC client support within the project. Previously, only Rust and Python clients were available, leaving Go consumers without an easy way to integrate with ModelServers. The new module provides a structured framework, including automated code generation from protobuf files and a robust CI/CD pipeline for releasing versioned clients, significantly improving developer experience for Go users. Highlights
Ignored Files
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces a Go gRPC client package, including the necessary module files, documentation, and a generation script. The overall structure is sound and provides a good foundation for Go consumers. My review includes a few suggestions to improve the robustness of the generation script and ensure broader compatibility of the Go module, including ensuring accurate external resource versions.
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 8 minutes and 30 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (6)
📝 WalkthroughWalkthroughAdds a Go gRPC client module with generation tooling, documentation, and a GitHub Actions workflow that tests generated code and can create a release tag containing generated outputs when invoked manually. Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer / Trigger
participant GH as GitHub Actions
participant Runner as Actions Runner
participant Protoc as protoc + plugins
participant Git as Git remote
Dev->>GH: push or workflow_dispatch (version)
GH->>Runner: start test job
Runner->>Runner: checkout repo, setup Go & protoc
Runner->>Protoc: run ./generate.sh -> protoc + plugins -> write generated/*
Runner->>Runner: go test ./...
alt workflow_dispatch (release)
GH->>Runner: start release job (depends on test)
Runner->>Runner: checkout full history
Runner->>Protoc: regenerate generated/*
Runner->>Runner: stage generated files, commit if changed
Runner->>Git: create tag (crates/grpc_client/go/v<version>) if absent and push
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related issues
Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Hi @zetxqx, the DCO sign-off check has failed. All commits must include a To fix existing commits: # Sign off the last N commits (replace N with the number of unsigned commits)
git rebase HEAD~N --signoff
git push --force-with-leaseTo sign off future commits automatically:
|
|
@zetxqx thanks for the contribution |
Thank you for your quick response @slin1237 . I see we have go bindings. I'll try it out. But meanwhile we also want a lightweight gRPC package for model servers like vllm. I see SMG publish the python client code: https://pypi.org/project/smg-grpc-proto/ . This PR adds the go client code for the proto. Since it's just client code, do you think it make sense to have a separate version? |
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release-go.yml:
- Around line 16-17: The global permissions block currently grants contents:
write for the whole workflow; change it to a least-privilege default (e.g.,
contents: read or remove the global write) and add an explicit permissions:
contents: write stanza under the release job definition (not under test), so
only the release job gets a write-capable token; reference the top-level
permissions key and the job names "release" and "test" when making the edits.
- Line 97: The workflow uses unquoted redirections like echo "version=$VERSION"
>> $GITHUB_OUTPUT which can trigger actionlint/shellcheck and cause
word-splitting; update the echo redirection to quote the output file variable
(e.g. use >> "$GITHUB_OUTPUT") wherever echo writes to GITHUB_OUTPUT (the lines
with echo "version=$VERSION" >> $GITHUB_OUTPUT and the other occurrences that
write to $GITHUB_OUTPUT around lines 104-106), keeping the variable expansion
for VERSION as-is but ensuring the redirection target is quoted.
- Around line 31-39: The workflow currently installs moving targets; pin the
tooling by updating the "Install protoc" step to use a specific
arduino/setup-protoc tag (replace uses: arduino/setup-protoc@v3 with a concrete
version tag) and change the "Install protoc-gen-go" step to install fixed module
versions (replace `@latest` for google.golang.org/protobuf/cmd/protoc-gen-go and
google.golang.org/grpc/cmd/protoc-gen-go-grpc with explicit version tags),
repeat the same pinned changes in the release job (the duplicate Install protoc
/ Install protoc-gen-go blocks), and update the README entries that mention
protoc versions to document the chosen pinned versions so builds are
reproducible.
In `@crates/grpc_client/go/generate.sh`:
- Around line 10-12: The script currently only clears "$OUTPUT_DIR" but not the
copied proto tree, so stale .proto files in GO_PROTO_DIR can persist; update
generate.sh to remove the existing "$GO_PROTO_DIR" contents before recreating it
(e.g., rm -rf "$GO_PROTO_DIR" prior to mkdir -p "$GO_PROTO_DIR") and apply the
same cleanup for the related block at the other occurrence (the lines around the
second cleanup at 19-21) so the proto directory is fully wiped before
repopulation.
In `@crates/grpc_client/go/README.md`:
- Around line 7-10: Update the first install example so it uses a tagged release
instead of the default branch: replace the literal "go get
github.com/lightseek/smg/crates/grpc_client/go" with a versioned form such as
"go get github.com/lightseek/smg/crates/grpc_client/go@v<VERSION>" (use the
current release tag), and apply the same change to the second occurrence
referenced around the example on lines 39-40 to ensure users install a tag that
includes generated files.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: acbc1913-6b48-46f7-9a95-a1be8ca6ecc0
⛔ Files ignored due to path filters (1)
crates/grpc_client/go/go.sumis excluded by!**/*.sum
📒 Files selected for processing (7)
.github/workflows/release-go.ymlcrates/grpc_client/go/.gitignorecrates/grpc_client/go/README.mdcrates/grpc_client/go/VERSIONcrates/grpc_client/go/generate.gocrates/grpc_client/go/generate.shcrates/grpc_client/go/go.mod
It makes perfect sense, Python package actually has its own version, |
|
Hi @zetxqx, the DCO sign-off check has failed. All commits must include a To fix existing commits: # Sign off the last N commits (replace N with the number of unsigned commits)
git rebase HEAD~N --signoff
git push --force-with-leaseTo sign off future commits automatically:
|
|
@coderabbitai resolve |
There was a problem hiding this comment.
Actionable comments posted: 4
♻️ Duplicate comments (2)
.github/workflows/release-go.yml (2)
71-74:⚠️ Potential issue | 🟠 MajorPin generator versions in release job to match test job.
The test job pins
protoc-gen-go@v1.36.1andprotoc-gen-go-grpc@v1.5.1(lines 38-39), but the release job uses@latest. This inconsistency could cause the release to generate different code than what was tested.🔧 Suggested fix
- name: Install protoc-gen-go run: | - go install google.golang.org/protobuf/cmd/protoc-gen-go@latest - go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest + go install google.golang.org/protobuf/cmd/protoc-gen-go@v1.36.1 + go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@v1.5.1🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release-go.yml around lines 71 - 74, The release workflow installs protoc generators using `@latest` which can diverge from test runs; update the two go install lines that install protoc-gen-go and protoc-gen-go-grpc to pin the same versions used in the test job (protoc-gen-go@v1.36.1 and protoc-gen-go-grpc@v1.5.1) so code generation in the release job matches the tested generator versions.
31-34:⚠️ Potential issue | 🟡 MinorPin
protocversion for reproducible builds in both jobs.The
arduino/setup-protoc@v3action is used without specifying aversionparameter, which installs the latest protoc. For reproducible release artifacts, pin to a specific version.🔧 Suggested fix for both jobs
First job (lines 36-39):
- name: Install protoc uses: arduino/setup-protoc@v3 with: + version: '34.x' repo-token: ${{ github.token }}Second job (lines 71-74):
- name: Install protoc uses: arduino/setup-protoc@v3 with: + version: '34.x' repo-token: ${{ github.token }}Also note: The release job pins
protoc-gen-go-grpcandprotoc-gen-goto@latest(lines 78-79), which contradicts the goal of reproducibility. Consider pinning these to specific versions as well (e.g., matching the versions used in the test job at lines 43-44).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release-go.yml around lines 31 - 34, Pin the protoc installer by adding the version input to the arduino/setup-protoc step (the existing uses: arduino/setup-protoc@v3) in both jobs so the action installs a fixed protoc release instead of the latest; also change the release job's pinned generators (protoc-gen-go-grpc and protoc-gen-go) from `@latest` to specific versions matching the test job (or other chosen semver) to ensure reproducible builds. Locate the setup step that uses arduino/setup-protoc@v3 and add the version: parameter, and update the uses entries for protoc-gen-go-grpc and protoc-gen-go to concrete tags instead of `@latest`. Ensure both the test job and release job receive the same pinned versions.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release-go.yml:
- Around line 111-118: The "Create and Push Tag" step currently creates a local
tag (git tag "$TAG") without ensuring the generated commit has been pushed;
update this step to push the commit to the remote before creating the tag (e.g.,
run a git push of the current HEAD or the branch) so that the tag will point to
a commit already on origin, then create and push the tag (references: step name
"Create and Push Tag", condition steps.check_tag.outputs.exists, the TAG
variable, git tag, git push origin "$TAG").
In `@crates/grpc_client/go/generate.sh`:
- Around line 52-64: The protoc command uses unquoted variable expansions for
proto_file in the --go_opt and --go-grpc_opt mappings (seen where
M${proto_file}=github.com/lightseekorg/...) which triggers shellcheck SC2086;
update those occurrences to quote the expansions (use "M${proto_file}=...") so
the mappings and the final "$proto_file" are safely handled by the shell;
specifically modify the two options that reference M${proto_file} in the
generate.sh protoc invocation to use quoted variable expansions.
- Around line 33-35: The indentation for the `exit 1` in the block that checks
for `protoc-gen-go-grpc` is inconsistent; remove the extra leading spaces before
`exit 1` so it matches the indentation of the earlier check block (same style as
the previous `exit 1`), ensuring the `echo` and `exit 1` lines align
consistently in the script.
In `@crates/grpc_client/go/README.md`:
- Around line 27-35: The markdown lists in crates/grpc_client/go/README.md
contain fenced code blocks that lack surrounding blank lines (MD031); update the
list items so there is a blank line immediately before and after each fenced
code block — specifically the code block with the two "go install ..." lines and
the code block with "bash generate.sh" — to ensure a blank line between the list
item text and the ``` fences and a blank line after each ``` before the next
list item or paragraph.
---
Duplicate comments:
In @.github/workflows/release-go.yml:
- Around line 71-74: The release workflow installs protoc generators using
`@latest` which can diverge from test runs; update the two go install lines that
install protoc-gen-go and protoc-gen-go-grpc to pin the same versions used in
the test job (protoc-gen-go@v1.36.1 and protoc-gen-go-grpc@v1.5.1) so code
generation in the release job matches the tested generator versions.
- Around line 31-34: Pin the protoc installer by adding the version input to the
arduino/setup-protoc step (the existing uses: arduino/setup-protoc@v3) in both
jobs so the action installs a fixed protoc release instead of the latest; also
change the release job's pinned generators (protoc-gen-go-grpc and
protoc-gen-go) from `@latest` to specific versions matching the test job (or other
chosen semver) to ensure reproducible builds. Locate the setup step that uses
arduino/setup-protoc@v3 and add the version: parameter, and update the uses
entries for protoc-gen-go-grpc and protoc-gen-go to concrete tags instead of
`@latest`. Ensure both the test job and release job receive the same pinned
versions.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 98bb0408-8a35-406d-9265-968c4e3dc8e8
⛔ Files ignored due to path filters (1)
crates/grpc_client/go/go.sumis excluded by!**/*.sum
📒 Files selected for processing (7)
.github/workflows/release-go.ymlcrates/grpc_client/go/.gitignorecrates/grpc_client/go/README.mdcrates/grpc_client/go/VERSIONcrates/grpc_client/go/generate.gocrates/grpc_client/go/generate.shcrates/grpc_client/go/go.mod
✅ Actions performedComments resolved and changes approved. |
|
Hi @zetxqx, the DCO sign-off check has failed. All commits must include a To fix existing commits: # Sign off the last N commits (replace N with the number of unsigned commits)
git rebase HEAD~N --signoff
git push --force-with-leaseTo sign off future commits automatically:
|
|
@slin1237 good call, I updated the golang generated client code to use the same version as the github tag. if we are going to release the golang client code for the model server proto, we'll start with version > 1.4.0 . |
|
This pull request has been automatically marked as stale because it has not had any activity within 14 days. It will be automatically closed if no further activity occurs within 16 days. Leave a comment if you feel this pull request should remain open. Thank you! |
There was a problem hiding this comment.
♻️ Duplicate comments (2)
.github/workflows/release-go.yml (1)
76-80:⚠️ Potential issue | 🟠 MajorPin release job generator versions to match the test job.
Using@latesthere makes tag artifacts non-deterministic and can diverge from what was validated in Line 43-44.Suggested fix
- name: Install protoc-gen-go run: | - go install google.golang.org/protobuf/cmd/protoc-gen-go@latest - go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest + go install google.golang.org/protobuf/cmd/protoc-gen-go@v1.36.1 + go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@v1.5.1🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release-go.yml around lines 76 - 80, Replace the non-deterministic go install lines that use `@latest` for protoc-gen-go and protoc-gen-go-grpc with pinned module versions matching the ones used in the test job (i.e., use the same version strings or variables as the test job instead of `@latest`) so the release job generates deterministic artifacts; update the two install commands in the step that runs protoc-gen-go and protoc-gen-go-grpc accordingly.crates/grpc_client/go/README.md (1)
27-35:⚠️ Potential issue | 🟡 MinorFix MD031 by adding blank lines around fenced blocks in the numbered list.
Markdownlint warning still reproduces in this segment.Suggested markdown fix
1. Install prerequisites: + ```bash go install google.golang.org/protobuf/cmd/protoc-gen-go@latest go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest ``` + 2. Run the generation script: + ```bash bash generate.sh ```🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@crates/grpc_client/go/README.md` around lines 27 - 35, The numbered list in README.md triggers MD031 because fenced code blocks lack surrounding blank lines; update the two list items that contain the install commands and the "bash generate.sh" block to insert a blank line before the opening ``` and a blank line after the closing ```, so each fenced block is separated from the list text (fix the install commands block and the "Run the generation script" block to satisfy MD031).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In @.github/workflows/release-go.yml:
- Around line 76-80: Replace the non-deterministic go install lines that use
`@latest` for protoc-gen-go and protoc-gen-go-grpc with pinned module versions
matching the ones used in the test job (i.e., use the same version strings or
variables as the test job instead of `@latest`) so the release job generates
deterministic artifacts; update the two install commands in the step that runs
protoc-gen-go and protoc-gen-go-grpc accordingly.
In `@crates/grpc_client/go/README.md`:
- Around line 27-35: The numbered list in README.md triggers MD031 because
fenced code blocks lack surrounding blank lines; update the two list items that
contain the install commands and the "bash generate.sh" block to insert a blank
line before the opening ``` and a blank line after the closing ```, so each
fenced block is separated from the list text (fix the install commands block and
the "Run the generation script" block to satisfy MD031).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 778d721d-a923-4bfb-9b34-5968f10aaa37
⛔ Files ignored due to path filters (1)
crates/grpc_client/go/go.sumis excluded by!**/*.sum
📒 Files selected for processing (6)
.github/workflows/release-go.ymlcrates/grpc_client/go/.gitignorecrates/grpc_client/go/README.mdcrates/grpc_client/go/generate.gocrates/grpc_client/go/generate.shcrates/grpc_client/go/go.mod
|
Hi @zetxqx, the DCO sign-off check has failed. All commits must include a To fix existing commits: # Sign off the last N commits (replace N with the number of unsigned commits)
git rebase HEAD~N --signoff
git push --force-with-leaseTo sign off future commits automatically:
|
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
.github/workflows/release-go.yml (1)
76-79:⚠️ Potential issue | 🟠 MajorRelease codegen still uses floating versions (
@latest).
testvalidates pinned generator versions, butreleaseregenerates with moving versions. That can ship artifacts different from what was tested.🔧 Proposed fix
- name: Install protoc-gen-go run: | - go install google.golang.org/protobuf/cmd/protoc-gen-go@latest - go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest + go install google.golang.org/protobuf/cmd/protoc-gen-go@v1.36.1 + go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@v1.5.1#!/bin/bash # Verify there are no floating generator versions in this workflow. rg -nP 'protoc-gen-go@latest|protoc-gen-go-grpc@latest' .github/workflows/release-go.yml🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release-go.yml around lines 76 - 79, The release workflow step currently installs generators using floating tags ("protoc-gen-go@latest" and "protoc-gen-go-grpc@latest"), which can produce code that differs from tested artifacts; update the run lines to pin those installs to the exact versions used in the test workflow by replacing "google.golang.org/protobuf/cmd/protoc-gen-go@latest" and "google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest" with the same explicit module versions/tags referenced in the test job (e.g., the exact `@vX.Y.Z` strings found in the test workflow), so release generation matches tested generator versions.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release-go.yml:
- Around line 96-104: The "Read Version" step currently uses the GitHub input
directly; instead read the canonical version from the file
crates/grpc_client/go/VERSION and use that as the source of truth (fall back to
the github.event.inputs.version only if that file is missing or empty). Update
the step (id: version) to first attempt to read the version string from
crates/grpc_client/go/VERSION into VERSION, validate it, and only if that read
fails or yields empty assign VERSION from ${{ github.event.inputs.version }};
always echo "version=$VERSION" to $GITHUB_OUTPUT after validation.
- Line 57: Update the workflow run condition so manual dispatches only create
release tags on the main branch: change the existing if that checks
github.event_name == 'workflow_dispatch' to also require github.ref ==
'refs/heads/main' (e.g., if: github.event_name == 'workflow_dispatch' &&
github.ref == 'refs/heads/main'), ensuring the workflow will only run for manual
dispatches targeting main; use the github.event_name and github.ref condition in
the same expression where the existing check currently appears.
---
Duplicate comments:
In @.github/workflows/release-go.yml:
- Around line 76-79: The release workflow step currently installs generators
using floating tags ("protoc-gen-go@latest" and "protoc-gen-go-grpc@latest"),
which can produce code that differs from tested artifacts; update the run lines
to pin those installs to the exact versions used in the test workflow by
replacing "google.golang.org/protobuf/cmd/protoc-gen-go@latest" and
"google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest" with the same explicit
module versions/tags referenced in the test job (e.g., the exact `@vX.Y.Z` strings
found in the test workflow), so release generation matches tested generator
versions.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: e17f9ff7-f649-4839-b61b-abbb4e5e97a8
📒 Files selected for processing (1)
.github/workflows/release-go.yml
Signed-off-by: bobzetian <bobzetian@google.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> Signed-off-by: bobzetian <bobzetian@google.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> Signed-off-by: bobzetian <bobzetian@google.com>
Signed-off-by: bobzetian <bobzetian@google.com>
Signed-off-by: bobzetian <bobzetian@google.com>
Signed-off-by: bobzetian <bobzetian@google.com>
Signed-off-by: bobzetian <bobzetian@google.com>
Signed-off-by: bobzetian <bobzetian@google.com>
Signed-off-by: bobzetian <bobzetian@google.com>
|
@slin1237 mind taking a look again? I refined this a bit. Thanks in advance! |
Signed-off-by: bobzetian <bobzetian@google.com> Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Description
Problem
The project currently provides Rust and Python clients for ModelServers defined in crates/grpc_client/proto, but lacks a Go client support. Go consumers cannot easily import and use the services without manual boilerplate setups.
Solution
Introduced a dedicated Go module framework at crates/grpc_client/go with automated code generation and CI release workflows. Specifically:
generate.shautomating protoc generation..github/workflows/release-go.ymlthat runs verification tests on branches and automates releasing versioned Git tags (e.g., crates/grpc_client/go/vX.Y.Z) carrying the forced-add generated outputs for external consumers to safely fetch.Changes
.github/workflows/release-go.yml: Workflow to test package building & trigger automatic Git tags/release branches pushcrates/grpc_client/go/generate.sh: Shell-script triggers for individual service protobuf to gRPC structure compilation.crates/grpc_client/go/VERSION: Basic semantic track definition point for GO.crates/grpc_client/go/generate.go: Short wrapper support for continuous go:generate bindings support.crates/grpc_client/go/{go.mod, go.sum}: Go modules initial descriptors setup for dependencies referencing.Test Plan
Run the following command locally
Checklist
cargo +nightly fmtpassescargo clippy --all-targets --all-features -- -D warningspassesSummary by CodeRabbit
New Features
Documentation