Skip to content

Add ability for maintainers to provide reason for yanking a release #7916

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

Merged
merged 13 commits into from
May 18, 2020
Merged

Add ability for maintainers to provide reason for yanking a release #7916

merged 13 commits into from
May 18, 2020

Conversation

daneah
Copy link
Contributor

@daneah daneah commented May 9, 2020

Resolves #7856
Fixes #7886

Copy link
Contributor Author

@daneah daneah left a comment

Choose a reason for hiding this comment

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

I'm trying to think about where to add tests...the process of adding a reason and making sure it shows up feels like a functional test, of which there are rather few. This new feature didn't introduce new methods/functions, so maybe I'm also overthinking it. Coverage remains at 100%, but I wouldn't mind exercising the new feature more explicitly.

@daneah
Copy link
Contributor Author

daneah commented May 12, 2020

@di Let me know if you have any guidance on the above notes! Is it okay if I force push a rebase of this branch, or do y'all prefer a fresh PR?

@di
Copy link
Member

di commented May 12, 2020

@daneah This is on my list to review today. A force push is totally fine!

Copy link
Member

@di di left a comment

Choose a reason for hiding this comment

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

This looks pretty good! A few thoughts:

  • We probably want to unset yanked_reason when the release is unyanked.
  • We should surface yanked_reason in the JSON API as well (and add it to the corresponding docs)
  • I think the yanked_reason in the JSON API should probably be None when the release is not yanked
  • We probably want to display the yanked_reason in the "Yanked Releases" table as well
  • We should include yanked_reason in the additional field when we call record_event during yanking

For tests, I would expect to see updates for yanked_reason anywhere where we're doing assert release.yanked or assert not release.yanked to ensure this field is actually getting set in the view. Same for the JSON API tests.

@daneah
Copy link
Contributor Author

daneah commented May 14, 2020

@di thanks for the review! I can definitely address some of those points readily, and I'm sure I'll have a couple of follow up questions 😄 will report back.

Copy link
Member

@di di left a comment

Choose a reason for hiding this comment

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

LGTM! I'll give @ewdurbin or @dstufft a chance to review if they want to.

@di di merged commit 3fe4e45 into pypi:master May 18, 2020
@di
Copy link
Member

di commented May 18, 2020

Thanks @daneah!

@pradyunsg
Copy link
Contributor

Wohoo! Thanks @daneah and @di! ^>^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants