1
- # How to contribute #
1
+ # How to contribute
2
2
3
3
We'd love to accept your patches and contributions to this project. There are
4
4
a just a few small guidelines you need to follow.
5
5
6
-
7
- ## Contributor License Agreement ##
6
+ ## Contributor License Agreement
8
7
9
8
Contributions to any Google project must be accompanied by a Contributor
10
9
License Agreement. This is not a copyright ** assignment** , it simply gives
@@ -17,7 +16,7 @@ You generally only need to submit a CLA once, so if you've already submitted one
17
16
again.
18
17
19
18
20
- ## Reporting issues ##
19
+ ## Reporting issues
21
20
22
21
Bugs, feature requests, and development-related questions should be directed to
23
22
our [ GitHub issue tracker] ( https://github.com/google/go-github/issues ) . If
@@ -29,7 +28,7 @@ how the requested feature would help you do that.
29
28
Security related bugs can either be reported in the issue tracker, or if they
30
29
are more sensitive, emailed to
< [email protected] > .
31
30
32
- ## Submitting a patch ##
31
+ ## Submitting a patch
33
32
34
33
1 . It's generally best to start by opening a new issue describing the bug or
35
34
feature you're intending to fix. Even if you think it's relatively minor,
73
72
[ pull request ] : https://help.github.com/articles/creating-a-pull-request
74
73
[ monitored by codecov.io ] : https://codecov.io/gh/google/go-github
75
74
76
- ## Scripts ##
75
+ ## Code Comments
76
+
77
+ Every exported method needs to have code comments that follow
78
+ [ Go Doc Comments] [ ] . A typical method's comments will look like this:
79
+
80
+ ``` go
81
+ // Get fetches a repository.
82
+ //
83
+ // GitHub API docs: https://docs.github.com/rest/repos/repos#get-a-repository
84
+ //
85
+ // meta:operation GET /repos/{owner}/{repo}
86
+ func (s *RepositoriesService ) Get (ctx context .Context , owner , repo string ) (*Repository , *Response , error ) {
87
+ u := fmt.Sprintf (" repos/%v /%v " , owner, repo)
88
+ req , err := s.client .NewRequest (" GET" , u, nil )
89
+ ...
90
+ }
91
+ ```
92
+
93
+ The first line is the name of the method followed by a short description. This
94
+ could also be a longer description if needed, but there is no need to repeat any
95
+ details that are documented in GitHub's documentation because users are expected
96
+ to follow the documentation links to learn more.
97
+
98
+ After the description comes a link to the GitHub API documentation. This is
99
+ added or fixed automatically when you run ` script/generate.sh ` , so you won't
100
+ need to set this yourself.
101
+
102
+ Finally, the ` //meta:operation ` comment is a directive to the code generator
103
+ that maps the method to the corresponding OpenAPI operation. Once again, there
104
+ can be multiple directives for methods that call multiple
105
+ endpoints. ` script/generate.sh ` will normalize these directives for you, so if
106
+ you are adding a new method you can use the pattern from the ` u := fmt.Sprintf `
107
+ line instead of looking up what the url parameters are called in the OpenAPI
108
+ description.
109
+
110
+ [ Go Doc Comments ] : https://go.dev/doc/comment
111
+
112
+ ## Metadata
113
+
114
+ GitHub publishes [ OpenAPI descriptions of their API] [ ] . We use these
115
+ descriptions to keep documentation links up to date and to keep track of which
116
+ methods call which endpoints via the ` //meta:operation ` comments described
117
+ above. GitHub's descriptions are far too large to keep in this repository or to
118
+ pull down every time we generate code, so we keep only the metadata we need
119
+ in ` openapi_operations.yaml ` .
120
+
121
+ ### openapi_operations.yaml
122
+
123
+ Most contributors won't need to interact with ` openapi_operations.yaml ` , but it
124
+ may be useful to know what it is. Its sections are:
125
+
126
+ - ` openapi_operations ` - is the metadata that comes from GitHub's OpenAPI
127
+ descriptions. It is generated by ` script/metadata.sh update-openapi ` and
128
+ should not be edited by hand. In the rare case where it needs to be
129
+ overridden, use the ` operation_overrides ` section instead.
130
+
131
+ An operation consists of ` name ` , ` documentation_url ` ,
132
+ and ` openapi_files ` . ` openapi_files ` is the list of files where the operation
133
+ is described. In order or preference, values can be "api.github.com.json" for
134
+ operations available on the free plan, "ghec.json" for operations available on
135
+ GitHub Enterprise Cloud or "ghes-<version >.json" for operations available on
136
+ GitHub Enterprise Server. When an operation is described in multiple ghes
137
+ files, only the most recent version is included. ` documentation_url ` is the
138
+ URL that should be linked from godoc. It is the documentation link found in
139
+ the first file listed in ` openapi_files ` .
140
+
141
+ - ` openapi_commit ` - is the git commit that ` script/metadata.sh update-openapi `
142
+ saw when it last updated ` openapi_operations ` . It is not necessarily the most
143
+ recent commit seen because ` update-openapi ` doesn't update the file when
144
+ there are no changes to ` openapi_operations ` .
145
+
146
+ - ` operations ` - contains manually added metadata that is not in GitHub's
147
+ OpenAPI descriptions. There are only a few of these. Some have
148
+ documentation_urls that point to relevant GitHub documentation that is not in
149
+ the OpenAPI descriptions. Others have no documentation_url and result in a
150
+ note in the generated code that the documentation is missing.
151
+
152
+ - ` operation_overrides ` - is where we override the documentation_url for
153
+ operations where the link in the OpenAPI descriptions is wrong.
154
+
155
+ ### tools/metadata
156
+
157
+ The ` tools/metadata ` package is a command-line tool for working with metadata.
158
+ In a typical workflow, you won't use it directly, but you will use it indirectly
159
+ through ` script/generate.sh ` and ` script/lint.sh ` .
160
+
161
+ Its subcommands are:
162
+
163
+ - ` update-openapi ` - updates ` openapi_operations.yaml ` with the latest
164
+ information from GitHub's OpenAPI descriptions. With ` --validate ` it will
165
+ validate that the descriptions are correct as of the commit
166
+ in ` openapi_commit ` . ` update-openapi --validate ` is called
167
+ by ` script/lint.sh ` .
168
+
169
+ - ` update-go ` - updates Go files with documentation URLs and formats comments.
170
+ It is used by ` script/generate.sh ` .
171
+
172
+ - ` format ` - formats whitespace in ` openapi_operations.yaml ` and sorts its
173
+ arrays. It is used by ` script/fmt.sh ` .
174
+
175
+ - ` unused ` - lists operations from ` openapi_operations.yaml ` that are not mapped
176
+ from any methods.
177
+
178
+ [ OpenAPI descriptions of their API ] : https://github.com/github/rest-api-description
179
+
180
+ ## Scripts
77
181
78
182
The ` script ` directory has shell scripts that help with common development
79
183
tasks.
@@ -86,6 +190,9 @@ tasks.
86
190
** script/lint.sh** runs linters on the project and checks generated files are
87
191
current.
88
192
193
+ ** script/metadata.sh** runs ` tools/metadata ` . See the [ Metadata] ( #metadata )
194
+ section for more information.
195
+
89
196
** script/test.sh** runs tests on all modules.
90
197
91
198
## Other notes on code organization ##
@@ -104,7 +211,7 @@ defined at <https://docs.github.com/en/rest/webhooks/repos> live in
104
211
[ repos_hooks.go ] : https://github.com/google/go-github/blob/master/github/repos_hooks.go
105
212
106
213
107
- ## Maintainer's Guide ##
214
+ ## Maintainer's Guide
108
215
109
216
(These notes are mostly only for people merging in pull requests.)
110
217
0 commit comments