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
fix(merge-on-green): add cleanup cron job, fix blocking issue for removing #1112
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Design question: could we do this cleanup "check" before doing anything with a PR in the normal loop/cron? That way, there won't be a delay between the problematic state and when it gets fixed by the next cleanup cron iteration.
Also, I saw the multiple-comment behavior on #1111, which doesn't seem like the same issue?
@@ -148,6 +148,59 @@ handler.cleanUpPullRequest = async function cleanUpPullRequest( | |||
.catch(logger.error); | |||
}; | |||
|
|||
/** | |||
* Check if PR has been merged, closed, or unlabeled, then remove |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing end of sentence?
Thanks for the review @tbpg!
I think what you're asking is if we can check to see if the PR is closed/merged/unlabeled before doing something in the regular workflow. This was the previous implementation of the bot, but I changed it in #1023 because checking this info was causing us to run into rate limits very quickly. Now, we wait for the unlabeled/closed/merged event to update the Datastore table. But, now we're running into a separate issue on whether or not the PR is in the table before it gets deleted if it gets added and deleted in the table too quickly. But, maybe we run the cleanup cron job every 15 minutes, instead of every 30? It is an expensive task to do, but it might be worth to address these issues. I'll leave that suggestion up to you and/or anyone else who has thoughts on it :)
Funny you mention that PR, it is actually the same issue! I was testing it last night. I quickly added and removed the automerge label. If you see there, MOG actually ended up merging that PR, even though it didn't have an automerge label on it. I am not exactly clear on what causes the multiple commenting issue, but I do know that this fix should solve it, since that PR shouldn't have even been in the Datastore table to begin with. |
…n-bots into fixCommentingIssue
@@ -26,7 +26,7 @@ import Ajv from 'ajv'; | |||
import yaml from 'js-yaml'; | |||
import {PullsListFilesResponseData} from '@octokit/types'; | |||
|
|||
export const configFileName = 'sync-repo-settings.yaml'; | |||
export const configFileName = 'sync-repo-settings.yml'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There seem to be some changes unrelated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oof, thanks for the heads up. Need to resync to main branch.
@@ -340,12 +340,6 @@ async function updateRepoTeams( | |||
logger.info(`Update team access for ${repo}`); | |||
const [owner, name] = repo.split('/'); | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this also an irrelevant change?
assert(removePRStub.called); | ||
}); | ||
|
||
it('deletes a PR if label is not found when cleaning up repository', async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
awesome to see the increased coverage 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic in schedule.repository
is getting pretty expansive, perhaps we could split it into two helpers that get called depending on the type of payload:
runCleanUp
/runMergeOnGreen
or something like that?
@@ -210,15 +297,19 @@ function handler(app: Application) { | |||
github as any | |||
); | |||
if (remove || wp.state === 'stop') { | |||
await handler.removePR(wp.url); | |||
try { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
spacing looks a little weird here, might need to run npm run fix
.
@@ -188,6 +252,29 @@ function handler(app: Application) { | |||
//open issue for a fix: https://github.com/octokit/webhooks.js/issues/277 | |||
app.on('schedule.repository' as any, async context => { | |||
const watchedPRs = await handler.listPRs(); | |||
if (context.payload.cleanUp === true) { | |||
while (watchedPRs.length) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might be tempted to pull this into a helper function.
This is kind of meta comment. Take this a grain of solt. The PR title should be something like:
|
…n-bots into fixCommentingIssue
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few small comments. Otherwise, LGTM.
}) | ||
).data; | ||
} catch (err) { | ||
pr = undefined; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this return early rather than continue unnecessarily?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might leave this just in case the github API is unavailable for some reason, but we can confirm by checking to see if a label is on the PR in the next function.
label.name === MERGE_ON_GREEN_LABEL_SECURE | ||
); | ||
|
||
if (pr?.merged === true || pr?.state === 'closed' || !foundLabel) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if (pr?.merged === true || pr?.state === 'closed' || !foundLabel) { | |
if (pr?.merged || pr?.state === 'closed' || !foundLabel) { |
VERSION is used in @google-cloud/cloud-rad to publish ref docs for a particular version. Pass VERSION in via Stubby or Fusion. Source-Link: googleapis/synthtool@740366b Post-Processor: gcr.io/repo-automation-bots/owlbot-nodejs:latest@sha256:bbdd52de226c00df3356cdf25460397b429ab49552becca645adbc412f6a4ed5
VERSION is used in @google-cloud/cloud-rad to publish ref docs for a particular version. Pass VERSION in via Stubby or Fusion. Source-Link: googleapis/synthtool@740366b Post-Processor: gcr.io/repo-automation-bots/owlbot-nodejs:latest@sha256:bbdd52de226c00df3356cdf25460397b429ab49552becca645adbc412f6a4ed5
See java-bigtable/498, and this issue.
I did some further digging into this multiple commenting issue, that did not seem to be solved by #1091. I think the real issue here is when people add an 'automerge' label and then either remove that label, close, or merge that PR soon after. I think a race condition is happening where the PR is not yet recorded in the Datastore table when the PR is closed or removed, making so that it doesn't actually get removed.
I don't know how to solve this problem categorically. What I ended up doing is creating a clean-up cron job that runs every 30 minutes. Every 30 minutes, if the cron job is the 'cleanup' job, the app will go through the PRs in the Datastore table and clean up ones that are either closed, merged, or do not have an automerge label on them anymore.