Repository: google/go-github
Pull request #2587 (2022-11-30 05:08:09)

Add go generate mention to CONTRIBUTING.md
a WIP for the improvement of CONTRIBUTING.md as detailed by #2579 , mentioning the existence of generated files and the fact that they should be added alongside the manual part of the commit.  We could probably add a few more things, but those will come along if suggestions do.

codecov[bot]: # [Codecov](https://codecov.io/gh/google/go-github/pull/2587?src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=google) Report
> Merging [#2587](https://codecov.io/gh/google/go-github/pull/2587?src=pr&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=google) (e1f29fe) into [master](https://codecov.io/gh/google/go-github/commit/6c430acced309db64330fb879a5bbbe242bcda8c?el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=google) (6c430ac) will **not change** coverage.
> The diff coverage is `n/a`.

```diff
@@           Coverage Diff           @@
##           master    #2587   +/-   ##
=======================================
  Coverage   97.98%   97.98%           
=======================================
  Files         125      125           
  Lines       10875    10875           
=======================================
  Hits        10656    10656           
  Misses        150      150           
  Partials       69       69           
```



Help us with your feedback. Take ten seconds to tell us [how you rate us](https://about.codecov.io/nps?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=google). Have a feature suggestion? [Share it here.](https://app.codecov.io/gh/feedback/?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=google)

XaurDesu: So, maybe should we put the information on generated files after line 58? moreso explaining the function of `go generate` when the concept is introduced. Or what ideas do you have regarding this?
gmlewis: @Parker77 - do you have any ideas about how these instructions in CONTRIBUTING.md can be improved?

For context, there was some confusion in #2577 and we are trying to minimize the friction that new contributors encounter when creating PRs for this repo.  Do you have any thoughts about this?
Parker77: I guess in step 5 (maybe right after line 60), like @XaurDesu suggested, we could give a brief explanation of what’s happening when that command is run, along with the instruction that the resulting changes should be included in a PR, which could go something like:

The `go generate ./...` command will update or generate certain files, and the resulting changes should be included in your pull request.
XaurDesu: Sorry for the absence guys, i've been a bit occupied in my personal life as of late, coming back to the topic at hand, i think that yes, i think @Parker77 's format seems like a good idea for them. I'll be adding that exact comment to `README.md` once i get home from work today, if you guys don't mind. Maybe i could convert this pull request into a draft until we have a specific plan for the whole thing.
XaurDesu: Hey guys, do you think it could be a good idea to add a few links to the official Go documentation of the commands of interest in `README.md`? Also, i just realized that `README.md` mentions `golint` as a command that should be ran after fmt. but [According to the golint repository,  golint is deprecated](https://github.com/golang/lint), and given that it reccomends running 'vet' instead of golint, and that is a command we use already, should we change that reference?
gmlewis: Adding links to official Go documentation in the README is fine by me.
And yes, updating the README from "golint" to "go vet" sounds like a good idea too.
XaurDesu: Tried putting some comments in the style of @Parker77 's idea for them (including his description of `go generate`, actually) please check for any styling/conceptual problems in it, please.  Also updated the `go lint` mentions.
XaurDesu: Just committed the changes requested.
XaurDesu: Just commited both changes, it should be good now
XaurDesu: Just corrected the dead link, i should probably have seen it before you honestly. Sorry for that.

Patch:
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 25d455b8..fb366046 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -44,9 +44,8 @@ are more sensitive, emailed to <opensource@google.com>.
 
   1. Go makes it very simple to ensure properly formatted code, so always run
      `go fmt` on your code before committing it. You should also run
-     [golint][] over your code. As noted in the [golint readme][], it's not
-     strictly necessary that your code be completely "lint-free", but this will
-     help you find common style issues.
+     [go vet][] over your code. this will help you find common style issues
+     within your code and will keep styling consistent within the project.
 
   1. Any significant changes should almost always be accompanied by tests. The
      project already has good test coverage, so look at some of the existing
@@ -59,18 +58,35 @@ are more sensitive, emailed to <opensource@google.com>.
      * `go test github.com/google/go-github/...`
      * `go vet github.com/google/go-github/...`
 
+   The `go generate ./...` command will update or generate certain files, and the 
+   resulting changes should be included in your pull request.
+
+   The `go test ./...` command will run tests inside your code. This will help you
+   spot places where code might be faulty before committing.
+
+   And finally, the `go vet ./...` command will check linting and styling over your 
+   code, keeping the project consistent formatting-wise.
+
+   In any case, it is always a good idea to read [official Go documentation][] when working 
+   on this project, as the definition of tools and commands of the Go programming 
+   language is described in further detail there.
+
   1. Do your best to have [well-formed commit messages][] for each change.
      This provides consistency throughout the project, and ensures that commit
      messages are able to be formatted properly by various git tools.
 
   1. Finally, push the commits to your fork and submit a [pull request][].
+     Before pushing commits, it is highly advised to check for generated files
+     that were either created or modified for the sake of your commit. Running
+     `go generate -x ./...` should return a log of modified generated files that should
+     be included alongside the manually written code in the commit.
      **NOTE:** Please do not use force-push on PRs in this repo, as it makes
      it more difficult for reviewers to see what has changed since the last
      code review.
 
+[official Go documentation]: https://pkg.go.dev/std
 [forking]: https://help.github.com/articles/fork-a-repo
-[golint]: https://github.com/golang/lint
-[golint readme]: https://github.com/golang/lint/blob/master/README.md
+[go vet]: https://pkg.go.dev/cmd/vet
 [gocov]: https://github.com/axw/gocov
 [gocov-html]: https://github.com/matm/gocov-html
 [well-formed commit messages]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
@@ -128,4 +144,5 @@ this][modified-comment].
 [rebase-comment]: https://github.com/google/go-github/pull/277#issuecomment-183035491
 [modified-comment]: https://github.com/google/go-github/pull/280#issuecomment-184859046
 
-**When creating a release, don't forget to update the `Version` constant in `github.go`.** This is used to send the version in the `User-Agent` header to identify clients to the GitHub API.
+**When creating a release, don't forget to update the `Version` constant in `github.go`.** This is used to 
+send the version in the `User-Agent` header to identify clients to the GitHub API.
diff --git a/github/event_types.go b/github/event_types.go
index 8330353a..50c7b567 100644
--- a/github/event_types.go
+++ b/github/event_types.go
@@ -485,6 +485,7 @@ type IssuesEvent struct {
 	Repo         *Repository   `json:"repository,omitempty"`
 	Sender       *User         `json:"sender,omitempty"`
 	Installation *Installation `json:"installation,omitempty"`
+	Milestone    *Milestone    `json:"milestone,omitempty"`
 }
 
 // LabelEvent is triggered when a repository's label is created, edited, or deleted.
diff --git a/github/github-accessors.go b/github/github-accessors.go
index 63b1079c..f502995e 100644
--- a/github/github-accessors.go
+++ b/github/github-accessors.go
@@ -8390,6 +8390,14 @@ func (i *IssuesEvent) GetLabel() *Label {
 	return i.Label
 }
 
+// GetMilestone returns the Milestone field.
+func (i *IssuesEvent) GetMilestone() *Milestone {
+	if i == nil {
+		return nil
+	}
+	return i.Milestone
+}
+
 // GetRepo returns the Repo field.
 func (i *IssuesEvent) GetRepo() *Repository {
 	if i == nil {


Test patch:
diff --git a/github/github-accessors_test.go b/github/github-accessors_test.go
index 961eba82..8fea0bb5 100644
--- a/github/github-accessors_test.go
+++ b/github/github-accessors_test.go
@@ -9843,6 +9843,13 @@ func TestIssuesEvent_GetLabel(tt *testing.T) {
 	i.GetLabel()
 }
 
+func TestIssuesEvent_GetMilestone(tt *testing.T) {
+	i := &IssuesEvent{}
+	i.GetMilestone()
+	i = nil
+	i.GetMilestone()
+}
+
 func TestIssuesEvent_GetRepo(tt *testing.T) {
 	i := &IssuesEvent{}
 	i.GetRepo()