-
Notifications
You must be signed in to change notification settings - Fork 36
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Co-authored-by: Elliot Jackson <13633636+elliotmjackson@users.noreply.github.com> Co-authored-by: Alfred Fuller <afuller@buf.build> Co-authored-by: Tony Li <122298175+tonyli233@users.noreply.github.com>
- Loading branch information
Showing
180 changed files
with
56,080 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
*.go text eol=lf |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,132 @@ | ||
# Contributor Covenant Code of Conduct | ||
|
||
## Our Pledge | ||
|
||
We as members, contributors, and leaders pledge to make participation in our | ||
community a harassment-free experience for everyone, regardless of age, body | ||
size, visible or invisible disability, ethnicity, sex characteristics, gender | ||
identity and expression, level of experience, education, socio-economic status, | ||
nationality, personal appearance, race, religion, or sexual identity | ||
and orientation. | ||
|
||
We pledge to act and interact in ways that contribute to an open, welcoming, | ||
diverse, inclusive, and healthy community. | ||
|
||
## Our Standards | ||
|
||
Examples of behavior that contributes to a positive environment for our | ||
community include: | ||
|
||
* Demonstrating empathy and kindness toward other people | ||
* Being respectful of differing opinions, viewpoints, and experiences | ||
* Giving and gracefully accepting constructive feedback | ||
* Accepting responsibility and apologizing to those affected by our mistakes, | ||
and learning from the experience | ||
* Focusing on what is best not just for us as individuals, but for the | ||
overall community | ||
|
||
Examples of unacceptable behavior include: | ||
|
||
* The use of sexualized language or imagery, and sexual attention or | ||
advances of any kind | ||
* Trolling, insulting or derogatory comments, and personal or political attacks | ||
* Public or private harassment | ||
* Publishing others' private information, such as a physical or email | ||
address, without their explicit permission | ||
* Other conduct which could reasonably be considered inappropriate in a | ||
professional setting | ||
|
||
## Enforcement Responsibilities | ||
|
||
Community leaders are responsible for clarifying and enforcing our standards of | ||
acceptable behavior and will take appropriate and fair corrective action in | ||
response to any behavior that they deem inappropriate, threatening, offensive, | ||
or harmful. | ||
|
||
Community leaders have the right and responsibility to remove, edit, or reject | ||
comments, commits, code, wiki edits, issues, and other contributions that are | ||
not aligned to this Code of Conduct, and will communicate reasons for moderation | ||
decisions when appropriate. | ||
|
||
## Scope | ||
|
||
This Code of Conduct applies within all community spaces, and also applies when | ||
an individual is officially representing the community in public spaces. | ||
Examples of representing our community include using an official e-mail address, | ||
posting via an official social media account, or acting as an appointed | ||
representative at an online or offline event. | ||
|
||
## Enforcement | ||
|
||
Instances of abusive, harassing, or otherwise unacceptable behavior may be | ||
reported to the community leaders responsible for enforcement at | ||
conduct@buf.build. All complaints will be reviewed and investigated promptly | ||
and fairly. | ||
|
||
All community leaders are obligated to respect the privacy and security of the | ||
reporter of any incident. | ||
|
||
## Enforcement Guidelines | ||
|
||
Community leaders will follow these Community Impact Guidelines in determining | ||
the consequences for any action they deem in violation of this Code of Conduct: | ||
|
||
### 1. Correction | ||
|
||
**Community Impact**: Use of inappropriate language or other behavior deemed | ||
unprofessional or unwelcome in the community. | ||
|
||
**Consequence**: A private, written warning from community leaders, providing | ||
clarity around the nature of the violation and an explanation of why the | ||
behavior was inappropriate. A public apology may be requested. | ||
|
||
### 2. Warning | ||
|
||
**Community Impact**: A violation through a single incident or series | ||
of actions. | ||
|
||
**Consequence**: A warning with consequences for continued behavior. No | ||
interaction with the people involved, including unsolicited interaction with | ||
those enforcing the Code of Conduct, for a specified period of time. This | ||
includes avoiding interactions in community spaces as well as external channels | ||
like social media. Violating these terms may lead to a temporary or | ||
permanent ban. | ||
|
||
### 3. Temporary Ban | ||
|
||
**Community Impact**: A serious violation of community standards, including | ||
sustained inappropriate behavior. | ||
|
||
**Consequence**: A temporary ban from any sort of interaction or public | ||
communication with the community for a specified period of time. No public or | ||
private interaction with the people involved, including unsolicited interaction | ||
with those enforcing the Code of Conduct, is allowed during this period. | ||
Violating these terms may lead to a permanent ban. | ||
|
||
### 4. Permanent Ban | ||
|
||
**Community Impact**: Demonstrating a pattern of violation of community | ||
standards, including sustained inappropriate behavior, harassment of an | ||
individual, or aggression toward or disparagement of classes of individuals. | ||
|
||
**Consequence**: A permanent ban from any sort of public interaction within | ||
the community. | ||
|
||
## Attribution | ||
|
||
This Code of Conduct is adapted from the [Contributor Covenant][homepage], | ||
version 2.0, available at | ||
[https://www.contributor-covenant.org/version/2/0/code_of_conduct.html][v2.0]. | ||
|
||
Community Impact Guidelines were inspired by | ||
[Mozilla's code of conduct enforcement ladder][Mozilla CoC]. | ||
|
||
For answers to common questions about this code of conduct, see the FAQ at | ||
[https://www.contributor-covenant.org/faq][FAQ]. Translations are available | ||
at [https://www.contributor-covenant.org/translations][translations]. | ||
|
||
[homepage]: https://www.contributor-covenant.org | ||
[v2.0]: https://www.contributor-covenant.org/version/2/0/code_of_conduct.html | ||
[Mozilla CoC]: https://github.com/mozilla/diversity | ||
[FAQ]: https://www.contributor-covenant.org/faq | ||
[translations]: https://www.contributor-covenant.org/translations |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,153 @@ | ||
# Contributing Guidelines | ||
|
||
Firstly, we want to say thank you for considering contributing | ||
to `protovalidate`. We genuinely appreciate your help. This document aims to | ||
provide some guidelines to make your contribution process straightforward and | ||
meaningful. | ||
|
||
## Code of Conduct | ||
|
||
We pledge to maintain a welcoming and inclusive community. Please read | ||
our [Code of Conduct](../CODE_OF_CONDUCT.md) before participating. | ||
|
||
## How Can I Contribute? | ||
|
||
### Reporting Bugs | ||
|
||
Bugs are tracked as GitHub issues. If you discover a problem | ||
with `protovalidate`, we want to hear about it. Here's how you can report a bug: | ||
|
||
1. __Ensure the bug was not already reported__: Before creating a new issue, | ||
please do a search | ||
in [issues](https://github.com/bufbuild/protovalidate/issues) to see if | ||
the problem has already been reported. If it has and the issue is still open, | ||
add a comment to the existing issue instead of opening a new one. | ||
|
||
2. __Check if the issue is fixed__: Try to reproduce the issue using the | ||
latest `main` branch to see if the problem has already been fixed. If fixed, | ||
that's great! | ||
|
||
3. __Open new issue__: If the issue has not been reported and has not been | ||
fixed, then we encourage you to [open a new issue][file-bug]. | ||
|
||
Remember to detail the steps to reproduce the issue. This information is | ||
invaluable in helping us fix the issue. | ||
|
||
Once you've filled in the template, hit "Submit new issue", and we will take | ||
care of the rest. We appreciate your contribution to making `protovalidate` | ||
better! | ||
|
||
### Suggesting Enhancements | ||
|
||
We welcome ideas for enhancements and new features to improve `protovalidate`. | ||
If you have an idea you'd like to share, if you want to expand language | ||
support, | ||
please read [the section below](#language-support-requirements) first. | ||
|
||
1. __Check if the enhancement is already suggested__: Before creating a new | ||
issue, please do a search | ||
in [issues](https://github.com/bufbuild/protovalidate/issues) to see if | ||
the idea or enhancement has already been suggested. If it has and the issue | ||
is still open, add a comment to the existing issue instead of opening a new | ||
one. | ||
|
||
2. __Open a new issue__: If your enhancement hasn't been suggested before, | ||
please [create a new issue][file-feature-request]. | ||
|
||
3. __Discussion__: Once you've submitted the issue, maintainers or other | ||
community members might jump in to discuss the enhancement. Be prepared to | ||
provide more context or insights about your suggestion. | ||
|
||
Remember, the goal of suggesting an enhancement is to improve `protovalidate` | ||
for everyone. Every suggestion is valued, and we thank you in advance for your | ||
contribution. | ||
|
||
### Pull Requests | ||
|
||
For changes, improvements, or fixes, please create a pull request. Make sure | ||
your PR is up-to-date with the main branch. Please write clear and concise | ||
commit messages to help us understand and review your PR. | ||
|
||
## Language Support Requirements | ||
|
||
We aim for `protovalidate` to support multiple languages, including but not | ||
limited to Go, Java, Python, C++, and Typescript. Here are the requirements for | ||
adding a new language: | ||
|
||
1. __Conformance__: Make sure that your language addition passes the conformance | ||
test suite. This ensures that your addition meets the project's standards and | ||
behaves as expected. | ||
|
||
2. __CEL Interpreter__: Implement a Common Expression Language (CEL) interpreter | ||
in your chosen language. CEL is a non-Turing complete language that makes it | ||
easy to write simple expressions, and it's crucial to `protovalidate`. | ||
|
||
3. __Custom Function Equivalence__: Ensure that custom functions have equivalent | ||
behavior across all languages. This uniformity is essential to maintain the | ||
integrity and consistency of the project. Check out | ||
the [Custom Functions](../docs/cel.md#custom-library-in-protovalidate) for more | ||
|
||
If you are interested in adding a new language to `protovalidate`, please open | ||
an issue to discuss the details and requirements. We will be more than happy to | ||
guide you through the process. | ||
|
||
### Minimizing Performance Regression | ||
|
||
Performance and efficient resource management are critical aspects | ||
of `protovalidate`. CEL, being non-Turing complete, provides production safety | ||
controls to limit execution time, helping to prevent excessive resource | ||
consumption during evaluation. Here are some guidelines for effectively managing | ||
resource constraints and minimizing performance regressions: | ||
|
||
1. __Understanding Resource Constraints__: CEL has resource constraint features | ||
which provide feedback about expression complexity. These are designed to | ||
prevent CEL evaluation from consuming excessive resources. One key element is | ||
the concept of a _cost unit_, an independent measure used for tracking CPU | ||
utilization regardless of system load or hardware. The cost is deterministic, | ||
meaning for any CEL expression and input data, the evaluation cost will | ||
remain the same. | ||
2. __Cost Units and Operations__: Many of CEL's operations have fixed costs. | ||
Simple operations, such as comparisons (e.g. `<`), have a cost of 1, while | ||
some, like list literal declarations, have a higher fixed cost of 40 cost | ||
units. Functions implemented in native code approximate cost based on time | ||
complexity. For instance, regular expression operations like `match` | ||
and `find` use an approximated cost | ||
of `length(regexString)*length(inputString)`, reflecting the worst-case time | ||
complexity of the operation. | ||
3. __Testing the Overall Cost__: You can use the CEL library to test the overall | ||
cost of an expression. This can help predict the resources required to | ||
evaluate an expression and prevent operations that would consume excessive | ||
resources. | ||
4. __Benchmark and Profile__: Benchmark your changes against the current `main` | ||
branch to evaluate the performance impact. If a performance regression is | ||
suspected, profile the code to pinpoint the bottleneck. | ||
5. __Optimize__: Always look for ways to optimize your changes without | ||
compromising readability, maintainability, or correctness of your code. | ||
6. __Discuss__: If your changes might cause a performance regression or resource | ||
constraint, but you believe they're still beneficial, discuss this in the | ||
pull request. Explain why you think the performance regression or resource | ||
constraint might be acceptable. | ||
|
||
By keeping performance and resource management in mind throughout the | ||
development process, we can ensure `protovalidate` remains efficient and | ||
responsive, even as we add new features and fix bugs. | ||
|
||
## Questions? | ||
|
||
If you have any questions, please don't hesitate to create an issue, and we'll | ||
answer as soon as possible. If your question is regarding a specific issue or | ||
pull request, please link it in your comment. | ||
|
||
## Thank You | ||
|
||
Again, we appreciate your help and time, and we are excited to see your | ||
contributions! | ||
|
||
Remember, you can reach out to us at any time, and we're looking forward to | ||
working together to make `protovalidate` the best it can be. | ||
|
||
[file-bug]: https://github.com/bufbuild/protovalidate/issues/new?assignees=&labels=Bug&template=bug_report.md&title=%5BBUG%5D | ||
|
||
[file-feature-request]: https://github.com/bufbuild/protovalidate/issues/new?assignees=&labels=Feature&template=feature_request.md&title=%5BFeature+Request%5D | ||
|
||
[cel-spec]: https://github.com/google/cel-spec |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,48 @@ | ||
--- | ||
name: Bug report | ||
about: Create a report to help us improve | ||
title: "[BUG]" | ||
labels: Bug | ||
assignees: '' | ||
|
||
--- | ||
|
||
## Description | ||
<!--Provide a clear and concise description of the bug. Be specific and include any relevant information about the issue, such as what you were trying to accomplish, what the expected behavior was, and how the actual behavior differed.--> | ||
|
||
## Steps to Reproduce | ||
<!-- | ||
1. First step to reproduce the bug | ||
2. Second step to reproduce the bug | ||
3. Third step to reproduce the bug | ||
... additional steps as needed | ||
--> | ||
|
||
## Expected Behavior | ||
|
||
<!--Describe what you expected to happen when following the steps to reproduce the bug.--> | ||
|
||
## Actual Behavior | ||
|
||
<!--Describe what actually happened instead of the expected behavior.--> | ||
|
||
## Screenshots/Logs | ||
|
||
<!--If applicable, add screenshots and/or log files to help explain the bug.--> | ||
|
||
## Environment | ||
|
||
- **Operating System**: <!--[e.g., macOS, Windows, Linux]--> | ||
- **Version**: <!--[e.g., macOS 10.15.7, Windows 10, Ubuntu 20.04]--> | ||
- **Compiler/Toolchain**: <!--[e.g., GCC 9.3.0, Clang 10.0.0]--> | ||
- **Protobuf Compiler & Version**: <!--[e.g. buf v1.17.0, protoc 3.17.3]--> | ||
- **Protoc-gen-validate Version**: <!--[if applicable, e.g., v0.6.1]--> | ||
- **Protovalidate Version**: <!--[if applicable, e.g., v1.0.2]--> | ||
|
||
## Possible Solution | ||
<!--If you have any suggestions on how the bug could be fixed or have identified the source of the problem, please provide your insights here.--> | ||
|
||
## Additional Context | ||
<!--Any other information, context, or relevant details that could be helpful for understanding and resolving the bug.--> | ||
|
||
<!--Please make sure to provide as much information as possible to help the maintainers diagnose and fix the issue.--> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,26 @@ | ||
--- | ||
name: Feature request | ||
about: Suggest an idea for this project | ||
title: "[Feature Request]" | ||
labels: Feature | ||
assignees: '' | ||
|
||
--- | ||
|
||
**Feature description:** | ||
<!-- A clear and concise description of the feature you would like to see implemented in protoc-gen-validate.--> | ||
|
||
**Problem it solves or use case:** | ||
<!-- Explain the problem this feature would solve or the use case it addresses, and how it would benefit users of protoc-gen-validate.--> | ||
|
||
**Proposed implementation or solution:** | ||
<!-- If you have a suggestion on how this feature can be implemented or any ideas on the solution, please describe them here.--> | ||
|
||
**Contribution:** | ||
<!--Describe how you would like to contribute this feature to the project. If you are willing to implement the feature yourself, please indicate that here. If you are not willing to implement it yourself, please indicate if you would be willing to help others implement it.--> | ||
|
||
**Examples or references:** | ||
<!-- If applicable, provide examples or references to similar features in other libraries or tools.--> | ||
|
||
**Additional context:** | ||
<!-- Add any other context or information about the feature request here.--> |
Oops, something went wrong.