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
ZOOKEEPER-2597: Add script to merge PR from Apache git repo to Github #85
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.
this looks really cool!
i'm not a git master, so i'm a bit confused why we are merging rather than cherry-picking
|
||
if __name__ == "__main__": | ||
import doctest | ||
(failure_count, test_count) = doctest.testmod() |
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.
what is this about?
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.
doctest (https://pymotw.com/2/doctest/) is yet another python test framework. This one run tests embedded on comments as these: https://github.com/apache/zookeeper/pull/85/files#diff-9f785a289bdb32d2570e08fbe952fbabR335
|
||
url = pr["url"] | ||
|
||
pr_title = pr["title"] |
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.
should we do some basic environ checks here? at least the JIRA_ environment variables should be set to something other than "" right?
we probably want to check that we are running the script in a zookeeper apache repo :)
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.
+1. 👍
jira_comment = "Issue resolved by pull request %s\n[%s/%s]" % (pr_num, GITHUB_BASE, pr_num) | ||
resolve_jira_issues(commit_title, merged_refs, jira_comment) | ||
else: | ||
print "JIRA_USERNAME and JIRA_PASSWORD not set" |
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.
it would be frustrating to get here and have to update the jira by hand. we should make sure we have it username and password and the start and make sure it is valid.
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.
+1. 👍
|
||
merged_refs = [target_ref] | ||
|
||
merge_hash = merge_pr(pr_num, target_ref, commit_title, body, pr_repo_desc) |
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.
why are we merging? shouldn't we be cherry picking?
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.
IMHO and AFAIK, the merge operation is the default operation (the graph clearly shows a merge of branches instead of a simply cherry picking, even though I would prefer the rebase... but I am no git expert). Cherry picking in this script is being used to "backport" the changes to other branches (possibly older ones). See my comment above.
TL;DR: the script uses the merge by default and cherry pick to backport
the commits in the PR to other branches.
|
||
# Merged pull requests don't appear as merged in the GitHub API; | ||
# Instead, they're closed by asfgit. | ||
merge_commits = \ |
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 don't understand this merge_commits logic. what is going on here? i don't understand why if we have merge_commits we cherry pick it without doing anything else.
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.
It's a bit hazy to me too. As far a I understood, the logic is this:
Say we want to merge PR 34:
- line 401 retrieves the json data that describes, among other things, any event associated with PR 34 (
pr_events
); - Line 432-433 filter only those events that are 'closed' by 'asfgit'. This indicates that PR 34 has already been merged in Apache git repo. Otherwise this list is empty.
- If list is not empty (line 435), then at lines 436-447 the script assumes that we want to backport the changes of PR 34 to other (older? newer?) branches. A merge would mess older branches with newer stuff, for example, or create lots of conflicts, so it cherry picks PR 34 commits into those (older) branches. It can be a security fix that need to be backported so it makes sense.
As far as I understand, lines 435-447 are used if we run the script a first time and later realize that PR needs to be applied to other branches as well. Then this logic makes sense if we run it a second/third/... time. I say so, because lines 463-465 basically do the same in the first pass, that is, in the process of merging the PR the first time then the script gives the option of cherry pick the commits of that PR to other branches after merging it into the main branch.
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.
Thanks for stepping up to help with this issue. 😃 I have been sidetracked by other commitments that prevented me from working on it as I would like to. Yet, count on me to help whatever I can.
|
||
if __name__ == "__main__": | ||
import doctest | ||
(failure_count, test_count) = doctest.testmod() |
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.
doctest (https://pymotw.com/2/doctest/) is yet another python test framework. This one run tests embedded on comments as these: https://github.com/apache/zookeeper/pull/85/files#diff-9f785a289bdb32d2570e08fbe952fbabR335
jira_comment = "Issue resolved by pull request %s\n[%s/%s]" % (pr_num, GITHUB_BASE, pr_num) | ||
resolve_jira_issues(commit_title, merged_refs, jira_comment) | ||
else: | ||
print "JIRA_USERNAME and JIRA_PASSWORD not set" |
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.
+1. 👍
|
||
url = pr["url"] | ||
|
||
pr_title = pr["title"] |
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.
+1. 👍
|
||
# Merged pull requests don't appear as merged in the GitHub API; | ||
# Instead, they're closed by asfgit. | ||
merge_commits = \ |
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.
It's a bit hazy to me too. As far a I understood, the logic is this:
Say we want to merge PR 34:
- line 401 retrieves the json data that describes, among other things, any event associated with PR 34 (
pr_events
); - Line 432-433 filter only those events that are 'closed' by 'asfgit'. This indicates that PR 34 has already been merged in Apache git repo. Otherwise this list is empty.
- If list is not empty (line 435), then at lines 436-447 the script assumes that we want to backport the changes of PR 34 to other (older? newer?) branches. A merge would mess older branches with newer stuff, for example, or create lots of conflicts, so it cherry picks PR 34 commits into those (older) branches. It can be a security fix that need to be backported so it makes sense.
As far as I understand, lines 435-447 are used if we run the script a first time and later realize that PR needs to be applied to other branches as well. Then this logic makes sense if we run it a second/third/... time. I say so, because lines 463-465 basically do the same in the first pass, that is, in the process of merging the PR the first time then the script gives the option of cherry pick the commits of that PR to other branches after merging it into the main branch.
|
||
merged_refs = [target_ref] | ||
|
||
merge_hash = merge_pr(pr_num, target_ref, commit_title, body, pr_repo_desc) |
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.
IMHO and AFAIK, the merge operation is the default operation (the graph clearly shows a merge of branches instead of a simply cherry picking, even though I would prefer the rebase... but I am no git expert). Cherry picking in this script is being used to "backport" the changes to other branches (possibly older ones). See my comment above.
TL;DR: the script uses the merge by default and cherry pick to backport
the commits in the PR to other branches.
@breed A quick check shows that this script is Python2. It will not run on Python3, afaik. It would require many small changes to make it compatible to Python3. |
test of jira bridging |
i think there are still quite a few improvements that can be made to this script, for example it assumes that the repo 'apache-github' is setup, so it would be nice to check for that at the start of the script and then print out how to set it up if it isn't setup. i'm thinking that we should get this checked in and then iterate on it as we use it. what do others think? |
@breed I was thinking of adding a confluence step-by-step guide on how to set up the environment variables too. |
@breed I have just added two checks to the main() function. One does check if JIRA credentials are set and other one tries to infer if the remote repos are compliant, that is, they point to a 'zookeeper' repo and that PR_REMOTE_NAME and PUSH_REMOTE_NAME are present. I don't like the echo'ing of the git commands, but couldn't see where to disable it at first look. |
Check git remote name and URL Add .strip() to trim input strings Add '.git' suffix to check_git_remote
@breed I guess this PR is a good candidate to backport to other branches (4.5, etc) besides master, don't you think? I mean, if the GH PR targets another branch then the script can disappear when that branch is checked out, right? Does it make sense what I am thinking? |
i don't think we need to backport it. you don't have to have the branch checked out to commit to it. (if i understand things correctly.) |
@breed I had understood the other way around 🤔 , that is, it creates a local branch from the target branch in addition to a local branch to the PR. Then it checkout the target branch and merge the PR branch. Need to test this tough. Oh, I have a suggestion to add a
|
+1 great job Eddie. |
Thanks @hanm ! 😃 |
Author: Edward Ribeiro <edward.ribeiro@gmail.com> Reviewers: Benjamin Reed <breed@apache.org> Closes apache#85 from eribeiro/ZOOKEEPER-2597
This change allows ZooKeeper server to read super user id string from system property, and parse it using delimiter "," to multiple client ids. Originally only one client id can be super user, this commit opens up the super user privilege to multiple clients. This commit includes non-backward-compatible changes in X509AuthenticationConfig class: setZnodeGroupAclSuperUserId is renamed to setZnodeGroupAclSuperUserIdStr getZnodeGroupAclSuperUserId is renamed to getZnodeGroupAclSuperUserIds, and return type is changed from String to Set Test modified: X509ZNodeGroupAclProviderTest.testSuperUser Test passed: all tests under org.apache.zookeeper.server.auth.znode.groupacl
Author: Edward Ribeiro <edward.ribeiro@gmail.com> Reviewers: Benjamin Reed <breed@apache.org> Closes apache#85 from eribeiro/ZOOKEEPER-2597
No description provided.