Skip to content
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

Expand buf lint PROTOVALIDATE rule to lint example and shared rules #3317

Draft
wants to merge 28 commits into
base: main
Choose a base branch
from

Conversation

oliversun9
Copy link
Contributor

@oliversun9 oliversun9 commented Sep 13, 2024

WIP: Address TODOs and add tests

This updates the PROTOVALIDATE rule in buf lint to provide checks for two new features:

  • For the protovalidate examples feature, check:
    • example values satisfy the constraints (builtin + cel)
    • if no constraint is defined on the field, an example value should not be present
  • For the predefined rules feature, check:
    • a predefined rule compiles (the expression defined on buf.validate.*Rules compiles)
    • example values also satisfy any predefined rules

The protovalidate test dependency has also been updated and some previous integration tests have also been updated to reflect this.

Copy link
Contributor

github-actions bot commented Sep 13, 2024

The latest Buf updates on your PR. Results from workflow Buf CI / buf (pull_request).

BuildFormatLintBreakingUpdated (UTC)
✅ passed✅ passed✅ passed✅ passedSep 27, 2024, 11:07 PM

Comment on lines +104 to +106
func celTypeForStandardRuleMessageDescriptor(
ruleMessageDescriptor protoreflect.MessageDescriptor,
) *cel.Type {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rodaine Just wondering if there is a better way to do this and/or if protovalidate-go exposes some mechanism for me to resolve the "type of rule" based on the rule message descriptor (e.g. StringRules). The context of this is that, we are parsing predefined rules from our files, and then checking their CEL expressions. And so we need the type for the extension itself (which is easy, we use the celext function you and @oliversun9 exported a while ago) and we also need the type for the rule that the extension is extending.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants