github/troubleshoot
1
0
Fork 0
mirror of https://github.com/replicatedhq/troubleshoot.git synced 2026-04-15 07:16:34 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #591 from replicatedhq/diamonwiggins/sc-48784/update-contributed-md

Browse Source 
Update Contributing.md
This commit is contained in:
Diamon Wiggins
2022-06-10 10:28:17 -04:00
committed by GitHub
parent 009829c3ff c044cc6021
commit a881877fd8
1 changed files with 25 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
CONTRIBUTING.md
View File

@@ -6,11 +6,17 @@ Thank you for your interest in Troubleshoot, we welcome your participation. Plea
- [Request a New Feature](https://github.com/replicatedhq/troubleshoot/issues/new?assignees=&labels=feature&template=feature_enhancement.md) Create an issue to add functionality that addresses a problem or adds an enhancement.
- [Report a Bug](https://github.com/replicatedhq/troubleshoot/issues/new?assignees=&labels=bug&template=bug_report.md) Report a problem or unexpected behaviour with Troubleshoot.
## Pull Requests
## Development Environment
If you are interested in contributing a change to the code or documentation please open a pull request with your set of changes. The pull request will be reviewed in a timely manner.
To get started we recommend:
## Tests
1. Go (v1.17 or later)
2. Kubernetes (we recommend https://k3d.io/. requires Docker v20.10.5 or later)
3. Fork and clone the repo to $GOPATH/src/github.com/replicatedhq/
4. Run `make support-bundle preflight` to generate binaries
5. Run `make run-troubleshoot` to generate a support bundle with the `sample-troubleshoot.yaml` in the root of the repo
### Testing
To run the tests locally run the following:
@@ -24,4 +30,19 @@ Additionally, e2e tests can be run with:
make support-bundle preflight e2e-test
```
A kubernetes cluster as well as `jq` are required to run e2e tests.
A Kubernetes cluster as well as `jq` are required to run e2e tests.
## Contribution workflow
This is a rough outline of how to prepare a contribution:
- Create a topic branch from where you want to base your work (branched from main).
- Make commits of logical units.
- Push your changes to a topic branch in your fork of the repository.
- Submit a pull request to the original repository. It will be reviewed in a timely manner.
### Pull Requests
A pull request should address a single issue, feature or bug. For example, lets say you've written code that fixes two issues. That's great! However, you should submit two small pull requests, one for each issue as opposed to combining them into a single larger pull request. In general the size of the pull request should be kept small in order to make it easy for a reviewer to understand, and to minimize risks from integrating many changes at the same time. For example, if you are working on a large feature you should break it into several smaller PRs by implementing the feature as changes to several packages and submitting a separate pull request for each one.
Code submitted in pull requests must be properly documented, formatted and tested in order to be approved and merged. The following guidelines describe the things a reviewer will look for when they evaluate your pull request. Here's a tip. If your reviewer doesn't understand what the code is doing, they won't approve the pull request. Strive to make code clear and well documented. If possible, request a reviewer that has some context on the PR.