Skip to content

Commit cca8239

Browse files
Merge pull request #387 from wking/contributing-docs
CONTRIBUTING: Add a contributing file
2 parents 7d703e3 + dd14258 commit cca8239

File tree

5 files changed

+81
-6
lines changed

5 files changed

+81
-6
lines changed

CONTRIBUTING.md

Lines changed: 70 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
1+
# How to Contribute
2+
3+
The cluster-version operator is [Apache 2.0 licensed](LICENSE) and accepts contributions via GitHub pull requests.
4+
This document outlines some of the conventions on development workflow, commit message formatting, contact points and other resources to make it easier to get your contribution accepted.
5+
6+
## Security Response
7+
8+
If you've found a security issue that you'd like to disclose confidentially, please contact Red Hat's Product Security team.
9+
Details [here][security].
10+
11+
## Getting Started
12+
13+
- Fork the repository on GitHub.
14+
- Read the [README](README.md) and [developer documentation](docs/dev) for build and test instructions.
15+
- Play with the project, submit bugs, submit patches!
16+
17+
### Contribution Flow
18+
19+
Anyone may [file issues][new-issue].
20+
For contributors who want to work up pull requests, the workflow is roughly:
21+
22+
1. Create a topic branch from where you want to base your work (usually master).
23+
2. Make commits of logical units.
24+
3. Make sure your commit messages are in the proper format (see [below](#commit-message-format)).
25+
4. If necessary, you may use `make update-codegen` to update generated code.
26+
5. Make sure the tests pass (`go test ./...`), and add any new tests as appropriate.
27+
6. Push your changes to a topic branch in your fork of the repository.
28+
7. Submit a pull request to the original repository.
29+
8. The [repo owners](OWNERS) will respond to your issue promptly, following [the ususal Prow workflow][prow-review].
30+
31+
Thanks for your contributions!
32+
33+
## Coding Style
34+
35+
The coding style suggested by the Golang community is used in installer.
36+
See the [style doc][golang-style] for details.
37+
Please follow them when working on your contributions.
38+
You may also `go fmt ./...` to have Go automatically format your .
39+
40+
## Commit Message Format
41+
42+
We follow a rough convention for commit messages that is designed to answer two questions: what changed and why.
43+
The subject line should feature the what and the body of the commit should describe the why.
44+
45+
```
46+
scripts: add the test-cluster command
47+
48+
this uses tmux to set up a test cluster that you can easily kill and
49+
start for debugging.
50+
51+
Fixes #38
52+
```
53+
54+
The format can be described more formally as follows:
55+
56+
```
57+
<subsystem>: <what changed>
58+
<BLANK LINE>
59+
<why this change was made>
60+
<BLANK LINE>
61+
<footer>
62+
```
63+
64+
The first line is the subject and should be no longer than 70 characters, the second line is always blank, and other lines should be wrapped at 80 characters.
65+
This allows the message to be easier to read on GitHub as well as in various Git tools.
66+
67+
[golang-style]: https://github.com/golang/go/wiki/CodeReviewComments
68+
[new-issue]: https://github.com/openshift/cluster-version-operator/issues/new
69+
[prow-review]: https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process
70+
[security]: https://access.redhat.com/security/team/contact

README.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -55,3 +55,8 @@ go test ./...
5555
export KUBECONFIG=<admin kubeconfig>
5656
TEST_INTEGRATION=1 go test ./... -test.run=^TestIntegration
5757
```
58+
59+
## Contributing
60+
61+
[Contributions welcome](CONTRIBUTING.md)!
62+

lib/resourceread/apiext_test.go

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -13,7 +13,7 @@ func TestReadCustomResourceDefinitionOrDie(t *testing.T) {
1313
args args
1414
}{
1515
{
16-
name:"v1",
16+
name: "v1",
1717
args: args{
1818
objBytes: []byte(`
1919
apiVersion: apiextensions.k8s.io/v1
@@ -42,7 +42,7 @@ spec:
4242
},
4343
},
4444
{
45-
name:"v1beta1",
45+
name: "v1beta1",
4646
args: args{
4747
objBytes: []byte(`
4848
apiVersion: apiextensions.k8s.io/v1beta1
@@ -82,4 +82,4 @@ spec:
8282
_ = ReadCustomResourceDefinitionOrDie(tt.args.objBytes)
8383
})
8484
}
85-
}
85+
}

pkg/autoupdate/autoupdate.go

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,6 @@ import (
77

88
"github.com/blang/semver"
99

10-
"k8s.io/klog"
1110
v1 "github.com/openshift/api/config/v1"
1211
clientset "github.com/openshift/client-go/config/clientset/versioned"
1312
"github.com/openshift/client-go/config/clientset/versioned/scheme"
@@ -23,6 +22,7 @@ import (
2322
"k8s.io/client-go/tools/cache"
2423
"k8s.io/client-go/tools/record"
2524
"k8s.io/client-go/util/workqueue"
25+
"k8s.io/klog"
2626
)
2727

2828
const (

pkg/cvo/cvo_test.go

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -27,8 +27,8 @@ import (
2727
"k8s.io/apimachinery/pkg/util/diff"
2828
"k8s.io/apimachinery/pkg/watch"
2929
"k8s.io/client-go/discovery"
30-
"k8s.io/client-go/rest"
3130
kfake "k8s.io/client-go/kubernetes/fake"
31+
"k8s.io/client-go/rest"
3232
ktesting "k8s.io/client-go/testing"
3333
"k8s.io/client-go/util/workqueue"
3434
"k8s.io/klog"
@@ -2581,7 +2581,7 @@ func TestOperator_availableUpdatesSync(t *testing.T) {
25812581
optr: Operator{
25822582
defaultUpstreamServer: "http://localhost:8080/graph",
25832583
minimumUpdateCheckInterval: 1 * time.Minute,
2584-
availableUpdates: &availableUpdates{
2584+
availableUpdates: &availableUpdates{
25852585
Upstream: "http://localhost:8080/graph",
25862586
Channel: "fast",
25872587
LastAttempt: time.Now(),

0 commit comments

Comments
 (0)