-
Notifications
You must be signed in to change notification settings - Fork 48
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
Don't close forks, don't close PRs for child/parent commands #142
Conversation
Codecov Report
@@ Coverage Diff @@
## master #142 +/- ##
============================================
+ Coverage 68.82% 69.28% +0.46%
- Complexity 140 176 +36
============================================
Files 7 13 +6
Lines 603 687 +84
Branches 93 99 +6
============================================
+ Hits 415 476 +61
- Misses 168 191 +23
Partials 20 20
|
90c77dd
to
778cfd1
Compare
Note: There's likely a need for fork cleanup that should either be a part of this process or separate (to reduce specific time of this process). For example, the original parent repo could be deleted or moved which would put the fork in the bot org in a weird state (the deletion can make the fork in the bot org a non-fork). |
It has proven wasteful and confusing to remove forks. Start marching towards using branches within a fork. Refactor out duplication to repository/GitHub class
This yields more results for other Dockerfile names
* Added slight logging improvement after PR created * Shift away from deprecated JsonParser methods
This is a steel thread approach. Needs a bit more refactoring and tests.
778cfd1
to
214af2a
Compare
* Also improve unreachable code block in GitForkBranch.isSameBranchOrHasImageNamePrefis(branchName)
* JSON processing can move to specific GitHubJsonStore (theoretically we could support more stores and more than just GitHub) * DockerfileGitHubUtil could potentially start migrating to an interface to provide a dry run mode (but it has far too many responsibilities at the moment) * Pull generic algorithm out of Parent into GitHubPullRequestSender
return false; | ||
} | ||
|
||
private String getBranchWithoutTag(String branchName) { |
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.
Are we documenting branch name conventions anywhere?
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.
Yeah, I kinda put it up top but this should be nearer to the function. Adding.
} | ||
} | ||
String jsonOutput = getAndModifyJsonString(json, img, tag); | ||
content.update(jsonOutput, |
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.
Doe this include retries?
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.
Nah, it doesn't currently. I haven't observed many issues where retries set this in a bad spot. That is something that could be considered for sure. I would have a similar concern about determining when to retry to help reduce rate limit pressure.
} | ||
// TODO: This may loop forever in the event of constant -1 pullRequestExitCodes... |
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.
Give it a configurable timeout?
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.
Yeah, right now focusing on solidifying the move to stop forking and branch instead. This needs to be done at some point or another though.
if (contentsWithImage.getTotalCount() > 0) { | ||
break; | ||
} else { | ||
Thread.sleep(1000); |
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.
TimeUnit.SECONDS.sleep(1);
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.
Change still not made?
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.
Bah... There were a bunch... Corrected that crust
"provided has access to deleting repositories."); | ||
if (!repo.queryPullRequests().state(GHIssueState.OPEN).list().iterator().hasNext()) { | ||
try { | ||
repo.delete(); |
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.
Need to retry on failure a few times?
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.
In which scenario would you expect that? Are you thinking of a network blip or momentary server unavailability? A potential issue with that would be to potentially put pressure on GitHub rate limits.
One thing that I'm considering to open up as an issue is to avoid forking at all if a repo doesn't need a change. We should be able to detect that off of the primary repo and then just skip forking it at the beginning.
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.
Yeh, network blips or errors
* A failed user check shouldn't blow up the whole process
Also remove invalid test for Child subcommand
This PR already involves a fairly significant amount of change. Talked a bit with @afalko. Will let |
} | ||
} | ||
private Optional<GHPullRequest> commentAndCloseExistingPullRequestsForBranch(GHRepository parentRepo, GitForkBranch gitForkBranch) { | ||
Optional<GHPullRequest> specifiedBranchPullRequest = dockerfileGitHubUtil.getPullRequestForImageBranch(parentRepo, gitForkBranch); | ||
// GHPullRequest pullRequest = specifiedBranchPullRequest.get(); |
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.
Need to keep this commented?
if (contentsWithImage.getTotalCount() > 0) { | ||
break; | ||
} else { | ||
Thread.sleep(1000); |
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.
Change still not made?
It has proven wasteful and confusing to remove forks.
This changes the
parent
andchild
commands to use branches with a name based on the newimage-tag
combination.This will have the following benefits:
filename:Dockerfile
instead oflanguage:Dockerfile
which picks up more resultsParent and Child are covered by #72 - All will keep the current strategy.