Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

x/build/maintner: GitHubIssue.ID field is never populated #39371

Open
dmitshur opened this issue Jun 3, 2020 · 1 comment
Open

x/build/maintner: GitHubIssue.ID field is never populated #39371

dmitshur opened this issue Jun 3, 2020 · 1 comment
Labels
Builders x/build issues (builders, bots, dashboards) NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@dmitshur
Copy link
Contributor

dmitshur commented Jun 3, 2020

Similarly to #28745, the ID field of a GitHubIssue is always zero:

corpus, err := godata.Get(context.Background())
if err != nil {
	log.Fatal(err)
}
num := 0
corpus.GitHub().ForeachRepo(func(gr *maintner.GitHubRepo) error {
	return gr.ForeachIssue(func(gi *maintner.GitHubIssue) error {
		if gi.ID != 0 {
			num++
		}
		return nil
	})
})
fmt.Printf("%d GitHub issues with non-zero IDs.\n", num)

// Output:
// 0 GitHub issues with non-zero IDs.

The field was added in CL 37888, but GithubIssueMutation.ID is not set anywhere. It should probably be set in the githubIssueDiffer.Diff method, with care taken that it's populated for both new and existing issues (it would be unhelpful to populate it only for new issues, as no one could rely on the field then).

An alternative fix is to document that it's always zero and/or to remove it.

This isn't high priority because the Number field is usable as a workaround; filing so I can look it up. (Fixing this is made harder by #37603.)
@dmitshur dmitshur added Builders x/build issues (builders, bots, dashboards) NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jun 3, 2020
@dmitshur dmitshur added this to the Backlog milestone Jun 3, 2020
@gopherbot
Copy link

Change https://golang.org/cl/236260 mentions this issue: cmd/releasebot: remove okay-after-beta1 label after beta1 is released

gopherbot pushed a commit to golang/build that referenced this issue Jun 3, 2020
@dmitshur
cmd/releasebot: remove okay-after-beta1 label after beta1 is released
6b5029f 
The okay-after-beta1 label is used to mark that a given issue with
the release-blocker label for a given major release milestone is
okay to resolve after beta1. When the beta1 is released for that
milestone, by definition, all remaining issues with release-blocker
label must be okay to resolve after beta1 and will have the label
indicating that.

That means the okay-after-beta1 label loses its meaning after beta1
is released. Since it takes up visual space, automatically remove it
from all release-blocker issues in the same milestone, and open up
more room for a potential future "okay-after-rc1" label or so.

Modify pushIssues to match the release status issue by issue
number rather than by title (keeping golang/go#39371 in mind).
Also modify pushIssues and check{,Beta1}ReleaseBlockers to match
milestones by ID rather than by name. This is to be more robust.

Change-Id: If74654375253185cc5e6488d344ec7b2b5195011
Reviewed-on: https://go-review.googlesource.com/c/build/+/236260
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Builders x/build issues (builders, bots, dashboards) NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
2 participants
@dmitshur @gopherbot