|
1 | | -# Contributing Guidelines |
| 1 | +# Contributing |
2 | 2 |
|
3 | | -Welcome to Kubernetes. We are excited about the prospect of you joining our [community](https://git.k8s.io/community)! The Kubernetes community abides by the CNCF [code of conduct](code-of-conduct.md). Here is an excerpt: |
| 3 | +This project is [Apache 2.0 licensed](LICENSE) and accepts contributions |
| 4 | +via GitHub pull requests. This document outlines some of the conventions on |
| 5 | +to make it easier to get your contribution accepted. |
4 | 6 |
|
5 | | -_As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities._ |
| 7 | +We gratefully welcome improvements to issues and documentation as well as to |
| 8 | +code. |
6 | 9 |
|
7 | | -## Getting Started |
| 10 | +## Certificate of Origin |
8 | 11 |
|
9 | | -We have full documentation on how to get started contributing here: |
| 12 | +By contributing to this project you agree to the Developer Certificate of |
| 13 | +Origin (DCO). This document was created by the Linux Kernel community and is a |
| 14 | +simple statement that you, as a contributor, have the legal right to make the |
| 15 | +contribution. No action from you is required, but it's a good idea to see the |
| 16 | +[DCO](DCO) file for details before you start contributing code to FluxCD |
| 17 | +pkg. |
10 | 18 |
|
11 | | -<!--- |
12 | | -If your repo has certain guidelines for contribution, put them here ahead of the general k8s resources |
13 | | ---> |
| 19 | +## Communications |
14 | 20 |
|
15 | | -- [Contributor License Agreement](https://git.k8s.io/community/CLA.md) Kubernetes projects require that you sign a Contributor License Agreement (CLA) before we can accept your pull requests |
16 | | -- [Kubernetes Contributor Guide](https://git.k8s.io/community/contributors/guide) - Main contributor documentation, or you can just jump directly to the [contributing section](https://git.k8s.io/community/contributors/guide#contributing) |
17 | | -- [Contributor Cheat Sheet](https://git.k8s.io/community/contributors/guide/contributor-cheatsheet/README.md) - Common resources for existing developers |
| 21 | +The project uses Slack: To join the conversation, simply join the |
| 22 | +[CNCF](https://slack.cncf.io/) Slack workspace and use the |
| 23 | +[#flux](https://cloud-native.slack.com/messages/flux/) channel. |
18 | 24 |
|
19 | | -## Mentorship |
| 25 | +The developers use a mailing list to discuss development as well. |
| 26 | +Simply subscribe to [flux-dev on cncf.io](https://lists.cncf.io/g/cncf-flux-dev) |
| 27 | +to join the conversation (this will also add an invitation to your |
| 28 | +Google calendar for our [Flux |
| 29 | +meeting](https://docs.google.com/document/d/1l_M0om0qUEN_NNiGgpqJ2tvsF2iioHkaARDeh6b70B0/edit#)). |
20 | 30 |
|
21 | | -- [Mentoring Initiatives](https://git.k8s.io/community/mentoring) - We have a diverse set of mentorship programs available that are always looking for volunteers! |
| 31 | +### How to run the test suite |
22 | 32 |
|
23 | | -## Contact Information |
| 33 | +You can run the unit tests by simply doing |
24 | 34 |
|
25 | | -- [Slack channel](https://kubernetes.slack.com/messages/sig-cli) |
26 | | -- [Mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-cli) |
| 35 | +```bash |
| 36 | +make test |
| 37 | +``` |
27 | 38 |
|
28 | | -## Setup a Dev Environment |
| 39 | +## Acceptance policy |
29 | 40 |
|
30 | | -- install [go](https://golang.org/doc/install) |
31 | | -- `export GO111MODULE=on` |
32 | | -- install [wire](https://github.com/google/wire/) |
| 41 | +These things will make a PR more likely to be accepted: |
33 | 42 |
|
34 | | -## Build and Test |
| 43 | +- a well-described requirement |
| 44 | +- tests for new code |
| 45 | +- tests for old code! |
| 46 | +- new code and tests follow the conventions in old code and tests |
| 47 | +- a good commit message (see below) |
| 48 | +- all code must abide [Go Code Review Comments](https://github.com/golang/go/wiki/CodeReviewComments) |
| 49 | +- names should abide [What's in a name](https://talks.golang.org/2014/names.slide#1) |
| 50 | +- code must build on both Linux and Darwin, via plain `go build` |
| 51 | +- code should have appropriate test coverage and tests should be written |
| 52 | + to work with `go test` |
35 | 53 |
|
36 | | -1. `go generate` |
37 | | - - Generates the `wire_gen.go` files |
38 | | -1. `go test ./...` |
39 | | - - Test the |
40 | | -1. `golint -min_confidence 0.9 ./...` |
41 | | - - Look for errors |
42 | | -1. `go build` |
43 | | - - Build the binary |
| 54 | +In general, we will merge a PR once one maintainer has endorsed it. |
| 55 | +For substantial changes, more people may become involved, and you might |
| 56 | +get asked to resubmit the PR or divide the changes into more than one PR. |
44 | 57 |
|
45 | | -## Dependency Injection |
| 58 | +### Format of the Commit Message |
46 | 59 |
|
47 | | -This repo uses Dependency Injection for wiring together the Commands. See the |
48 | | -[wire tutorial](https://github.com/google/wire/tree/master/_tutorial) for more on DI. |
| 60 | +For Source Controller we prefer the following rules for good commit messages: |
49 | 61 |
|
50 | | -## Adding a Command |
| 62 | +- Limit the subject to 50 characters and write as the continuation |
| 63 | + of the sentence "If applied, this commit will ..." |
| 64 | +- Explain what and why in the body, if more than a trivial change; |
| 65 | + wrap it at 72 characters. |
51 | 66 |
|
52 | | -1. Add a new package for your cobra command under `cmd/` |
53 | | - - e.g. `kubectl apply status` would be added under `cmd/apply/status` |
54 | | - - Add it to the parent command |
55 | | - - Copy an existing command as an example |
56 | | -1. Add a new package that contains the library for your command under `internal/pkg` |
57 | | - - e.g. `kubectl apply status` library would be added under `internal/pkg/status` |
58 | | - - Invoke it from the command you added |
59 | | - - Copy an existing package as an example |
60 | | -1. Add the DI wiring for your library |
61 | | - - Edit `internal/pkg/wiring/wiring.go` - Add your struct to the `ProviderSet` list |
62 | | - - Edit `internal/pkg/wiring/wire.go` - Add an `Initialize` function for you struct |
63 | | - |
64 | | -## Adding a Library (non-internal) |
65 | | - |
66 | | -1. Add a new package for your library under `pkg` |
67 | | -1. Add a new package that contains the implementation under `internal/pkg` |
68 | | - - Invoke it from your public package |
| 67 | +The [following article](https://chris.beams.io/posts/git-commit/#seven-rules) |
| 68 | +has some more helpful advice on documenting your work. |
0 commit comments