Excited about Gloo Edge and want to help make it better?
At Solo we strive to make the world of microservices, serverless and service mesh available to everyone. If you want to help but don't know where to start, let us know, and we'll find something for you.
If you haven't already, make sure you sign up for the Solo Slack.
Here are some of the ways you can contribute:
If you encounter a bug, please file an issue on GitHub. If an issue you have is already reported, please add additional information or add a 👍 reaction to indicate your agreement.
The docs for Gloo Edge are built from the contents found in the docs/content directory of this repository.
Improving the documentation, adding examples or use cases can be the easiest way to contribute to Gloo Edge. If you see a piece of content that can be better, open a PR with an improvement, it doesn't matter how small!
For more detailed guidance on contributing to the documentation, check out the guide on the docs website.
Instructions for setting the development environment can be found in the developer guide.
Useful make commands:
| Command | Description |
|---|---|
| make install-go-tools generated-code -B | Makes all generated code which is required to get past CI. |
| make glooctl | Makes glooctl binary and places it in _output/glooctl |
| make build-test-chart | Makes the .tgz helm file that locally-built instances of glooctl require to install gloo |
| make docker TAGGED_VERSION=(version) | Builds the docker images needed for the helm charts and tests |
| 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. |
| make install-go-tools | Updates the go dependencies |
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, just make sure that you include a test that verifies the bug you are fixing.
This includes:
- Big bug fixes
- New features
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.
- Open an issue. Open an issue about your bug in this repo.
- Message us on Slack. Reach out to us to discuss your proposed changes.
- 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?
- 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 progressto start getting feedback. - 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.
- A Solo team member will merge and release!
It’s important that every piece of code in Gloo Edge is reviewed by at least one Solo team member familiar with that codebase.
- Changelog Every PR in Gloo Edge needs a changelog entry. For more information about changelogs, see the readme.
- CI check A Solo team member needs to kick off the CI process by commenting
/teston your PR. - Testing Please write tests for your changes. Bias towards fast / unit testing.
- Comments The code reviewer may leave comments to discuss changes. Minor preferences are often called out with
nit.
To see coverage, run your tests in the package like so
ginkgo -cover && go tool cover -html *.coverprofile