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

KAFKA-15201: Allow git push to fail gracefully #14645

Merged
merged 4 commits into from
Feb 8, 2024

Conversation

Owen-CH-Leung
Copy link
Contributor

As described in the ticket KAFKA-15201, this PR allows the git push action to fail gracefully in case of error.

Committer Checklist (excluded from commit message)

  • Verify design and implementation
  • Verify test coverage and CI build status
  • Verify documentation (including upgrade notes)

release.py Outdated
@@ -730,7 +730,7 @@ def select_gpg_key():
fail("Ok, giving up")
if not user_ok("Ok to push RC tag %s (y/n)?: " % rc_tag):
fail("Ok, giving up")
cmd("Pushing RC tag", "git push %s %s" % (PUSH_REMOTE_NAME, rc_tag))
cmd("Pushing RC tag", "git push %s %s" % (PUSH_REMOTE_NAME, rc_tag), num_retries=0)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to have allow_failure=True here too?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we put allow_failure=True, when git push failed, the program will continue to run the remaining lines after git push instead of failing gracefully. So I think we should just keep num_retries=0 so that it triggered the fail function and proceed to do the cleanup

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we don't pass this argument, the default for num_retries is already 0.

num_retries = kwargs.pop("num_retries", 0)

So, I assume that this line change does not really change anything?

Copy link
Contributor Author

@Owen-CH-Leung Owen-CH-Leung Oct 30, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can I ask like when git push failed, do we expect the program to perform clean up like the logic defined in the def fail ? Or the program can directly exit with error ?

The current infinite loop lies in the fact that the API def cmd calls def fail , which in turn calls back def cmd, and hence the program never exits. If we can exit directly with error upon failed git push, the implementation can be a lot simplified.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, I don't have the logs now and it will take me time to reproduce.

I agree with your assessment on the cmd/fail loop. Perhaps, we can detect that the failure is due to git and in such cases, mark delete_gitrefs=false. That will ensure that fail() does not call git commands again.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the original implementation is that whenever cmd fails, the clean-up logic will always be fired (i.e. switch to the original working branch, delete the release branch & the tag). If we add the git-failure check, we may lose such feature.

I've modified the git push part to avoid using the cmd function (thereby avoiding the cmd/fail loop). Could you take a look and leave me some feedback ?

The proposed logic is that when git push fails, the program will exit gracefully without cleaning the release branch & tag (so the user will have to manually clear them in order to restart)

@Owen-CH-Leung
Copy link
Contributor Author

@divijvaidya Can I get your feedback for this PR ? Many Thanks

release.py Outdated
@@ -730,7 +730,7 @@ def select_gpg_key():
fail("Ok, giving up")
if not user_ok("Ok to push RC tag %s (y/n)?: " % rc_tag):
fail("Ok, giving up")
cmd("Pushing RC tag", "git push %s %s" % (PUSH_REMOTE_NAME, rc_tag))
cmd("Pushing RC tag", "git push %s %s" % (PUSH_REMOTE_NAME, rc_tag), num_retries=0)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we don't pass this argument, the default for num_retries is already 0.

num_retries = kwargs.pop("num_retries", 0)

So, I assume that this line change does not really change anything?

release.py Outdated
Comment on lines 83 to 85
cmd("Resetting repository working state to branch %s" % starting_branch, "git reset --hard HEAD && git checkout %s" % starting_branch, shell=True, allow_failure=True)
cmd("Deleting git branches %s" % release_version, "git branch -D %s" % release_version, shell=True, allow_failure=True)
cmd("Deleting git tag %s" %rc_tag , "git tag -d %s" % rc_tag, shell=True, allow_failure=True)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the first line fails which is correctly switching the branch, we will proceed with next line and end up deleting an incorrect branch. We don't want that. Am I missing something?

Copy link
Contributor

@divijvaidya divijvaidya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you. Looks good!

@Owen-CH-Leung
Copy link
Contributor Author

@divijvaidya shall we merge this PR ? Thanks

@mimaison
Copy link
Member

mimaison commented Feb 8, 2024

@divijvaidya Should we merge this PR?

@divijvaidya divijvaidya merged commit cd328d8 into apache:trunk Feb 8, 2024
1 check failed
yyu1993 pushed a commit to yyu1993/kafka that referenced this pull request Feb 15, 2024
clolov pushed a commit to clolov/kafka that referenced this pull request Apr 5, 2024
Phuc-Hong-Tran pushed a commit to Phuc-Hong-Tran/kafka that referenced this pull request Jun 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants