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

x/build/cmd/gopherbot: doesn't close re-opened backport issues #31094

Open
dmitshur opened this issue Mar 27, 2019 · 2 comments
Open

x/build/cmd/gopherbot: doesn't close re-opened backport issues #31094

dmitshur opened this issue Mar 27, 2019 · 2 comments
Labels
Builders x/build issues (builders, bots, dashboards) help wanted NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@dmitshur
Copy link
Contributor

Issue #29270 was filed about gopherbot being too aggressive about closing backport issues. It fought humans (more than one time) who tried to re-open a backport issue. /cc @bradfitz

The fix to that issue was to have gopherbot check for a gi.HasEvent("reopened") event and not consider any re-opened backport issues. It worked to resolve that issue, but it doesn't take into account a situation where a backport issue is re-opened (e.g., because the fix is reverted) and then resolved via another future CL.

This happened in #30266.

Until this is resolved, the workaround is to manually close a backport issue. This situation happens very infrequently, so this is not a high priority bug.

@dmitshur dmitshur added help wanted Builders x/build issues (builders, bots, dashboards) NeedsFix The path to resolution is known, but the work has not been done. labels Mar 27, 2019
@gopherbot gopherbot added this to the Unreleased milestone Mar 27, 2019
@dmitshur dmitshur changed the title x/build/cmd/gopherbot: doesn't close re-opened backport issues after it's resolved by a different CL x/build/cmd/gopherbot: doesn't close re-opened backport issues Aug 6, 2019
@dmitshur
Copy link
Contributor Author

dmitshur commented Aug 6, 2019

This happened again in #32940 (comment) because the issue was closed and re-opened by a human for unrelated reasons.

A fix in gopherbot would be to replace the simple check for "reopened" event with a more targeted check: it should check if the issue was closed by gopherbot itself—rather than anyone—and then reopened. E.g., something like this:

// gopherbotClosedIssue reports whether gopherbot has
// previously closed the GitHub issue gi.
//
// Note that until golang.org/issue/28226 is resolved,
// there's a brief delay before maintner catches up on
// GitHub issue events and learns that it has happened.
func gopherbotClosedIssue(gi *maintner.GitHubIssue) bool {
	var hasClosed bool
	gi.ForeachEvent(func(e *maintner.GitHubIssueEvent) error {
		if e.Actor != nil && e.Actor.ID == gopherbotGitHubID && e.Type == "closed" {
			hasClosed = true
			return errStopIteration
		}
		return nil
	})
	return hasClosed
}

@ianlancetaylor
Copy link
Contributor

If the goal is just to avoid fighting with people, then perhaps we could only consider "reopened" events that occurred in the last week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Builders x/build issues (builders, bots, dashboards) help wanted NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

3 participants