|
1 | | -# Contributing to Gloo Gateway |
| 1 | +# Contributing |
2 | 2 |
|
3 | | -Excited about Gloo Gateway and want to help make it better? |
4 | | - |
5 | | -At Solo we strive to make the world of microservices, serverless and service mesh available to everyone. |
6 | | -If you want to help but don't know where to start, let us know, and we'll find something for you. |
7 | | - |
8 | | -If you haven't already, make sure you sign up for the [Solo Slack](https://slack.solo.io). |
9 | | - |
10 | | -Here are some of the ways you can contribute: |
11 | | - |
12 | | -* [Filing issues](#filing-issues) |
13 | | -* [Improving the documentation](#improving-the-documentation) |
14 | | -* [Small bug fixes](#small-bug-fixes) |
15 | | -* [Big pull requests](#big-prs) |
16 | | -* [Code review guidelines](#code-review-guidelines) |
17 | | - |
18 | | -## Filing issues |
19 | | - |
20 | | -If you encounter a bug, please file an issue on GitHub. |
21 | | -If an issue you have is already reported, please add additional information or add a 👍 reaction to indicate your agreement. |
22 | | - |
23 | | -## Improving the documentation |
24 | | - |
25 | | -The docs for Gloo Gateway are built from the contents found in the [`docs/content`](/docs/content) directory of this repository. |
26 | | - |
27 | | -Improving the documentation, adding examples or use cases can be the easiest way to contribute to Gloo Gateway. If you see a piece of content that can be better, open a PR with an improvement, it doesn't matter how small! |
28 | | - |
29 | | -For more detailed guidance on contributing to the documentation, check out the guide on the [docs website](https://docs.solo.io/gloo-edge/latest/contributing). |
30 | | - |
31 | | -## Setting up the development environment |
32 | | - |
33 | | -Instructions for setting the development environment can be found in the [developer guide](https://docs.solo.io/gloo-edge/latest/guides/dev/setting-up-dev-environment/). |
34 | | - |
35 | | -Useful make commands: |
36 | | - |
37 | | -| Command | Description | |
38 | | -| --- | --- | |
39 | | -| make install-go-tools generated-code -B | Makes all generated code which is required to get past CI. | |
40 | | -| make glooctl | Makes glooctl binary and places it in _output/glooctl | |
41 | | -| make build-test-chart | Makes the .tgz helm file that locally-built instances of glooctl require to install gloo | |
42 | | -| make docker TAGGED_VERSION=(version) | Builds the docker images needed for the helm charts and tests | |
43 | | -| make clean build-test-assets -B TAGGED_VERSION=v(version) | Builds a zipped helm chart for gloo that is configured to use the specified gloo version. This version must be a valid image in quay. This can include non-standard versions used for testing. | |
44 | | -| make install-go-tools | Updates the go dependencies | |
45 | | - |
46 | | -## Small bug fixes |
47 | | - |
48 | | -If your bug fix is small (around 20 lines of code) just open a pull request. We will try to merge it as soon as possible, |
49 | | -just make sure that you include a test that verifies the bug you are fixing. |
50 | | - |
51 | | -## Big PRs |
52 | | - |
53 | | -This includes: |
54 | | - |
55 | | -- Big bug fixes |
56 | | -- New features |
57 | | - |
58 | | -For significant changes to the repository, it’s important to settle on a design before starting on the implementation. Reaching out to us early will help minimize the amount of possible wasted effort and will ensure that major improvements are given enough attention. |
59 | | - |
60 | | -1. **Open an issue.** Open an issue about your bug in this repo. |
61 | | -2. **Message us on Slack.** Reach out to us to discuss your proposed changes. |
62 | | -3. **Agree on implementation plan.** Write a plan for how this feature or bug fix should be implemented. Should this be one pull request or multiple incremental improvements? Who is going to do each part? |
63 | | -4. **Submit a work-in-progress PR** It's important to get feedback as early as possible to ensure that any big improvements end up being merged. Submit a pull request and label it `work in progress` to start getting feedback. |
64 | | -5. **Review.** At least one Solo team member should sign off on the change before it’s merged. Look at the “code review” section below to learn about what we're looking for. |
65 | | -6. **A Solo team member will merge and release!** |
66 | | - |
67 | | -## Code review guidelines |
68 | | - |
69 | | -It’s important that every piece of code in Gloo Gateway is reviewed by at least one Solo team member familiar with that codebase. |
70 | | - |
71 | | -1. **Changelog** Every PR in Gloo Gateway needs a changelog entry. For more information about changelogs, see the [readme](https://github.com/solo-io/go-utils/tree/main/changelogutils). |
72 | | -2. **CI check** A Solo team member needs to kick off the CI process by commenting `/test` on your PR. |
73 | | -3. **Testing** Please write tests for your changes. Bias towards fast / unit testing. |
74 | | -4. **Comments** The code reviewer may leave comments to discuss changes. Minor preferences are often called out with `nit`. |
75 | | - |
76 | | -## Testing with coverage: |
77 | | - |
78 | | -To see coverage, run your tests in the package like so |
79 | | - |
80 | | -``` |
81 | | -ginkgo -cover && go tool cover -html *.coverprofile |
82 | | -``` |
| 3 | +Please refer to the [contributing guide](https://github.com/kgateway-dev/community/blob/main/CONTRIBUTING.md) in the community repo. |
0 commit comments