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.

Sign up for GitHub

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

Jump to bottom

Support converting PR back to draft #2778

Closed
Marcono1234 opened this issue Feb 22, 2024 · 2 comments · Fixed by #3057
Closed

Support converting PR back to draft #2778

Marcono1234 opened this issue Feb 22, 2024 · 2 comments · Fixed by #3057

Comments

@Marcono1234
Copy link

Marcono1234 commented Feb 22, 2024 •
edited
Loading

Subject of the issue

Would it possible to support converting a pull request back to draft? #1064 says this is not possible, but it appears the GraphQL API supports this, see https://github.com/orgs/community/discussions/45174#discussioncomment-4768134.

Maybe it would be good to have a separate input for this though and make it opt-in because some users might prefer to not convert PRs back to draft once they have been marked as ready.

Context

The reason for this feature request is mainly as another workaround to trigger other workflows for the pull request, probably the same which was proposed here: #48 (comment)

So the create-pull-request action creates the PR as draft, the user marks it as ready which then automatically runs the other workflows. And if create-pull-request updates the PR, it converts it back to draft again.

Unfortunately though by default on: pull_request does not include the ready_for_review activity (see documentation)1, so all workflows would have to explicit specify that activity type as well, which might be quite error-prone.
Not sure if this renders this workaround (and also the request to convert back to draft) pointless. What do you think?

Footnotes

  1. I find it a bit weird that ready_for_review is not included by default, but maybe the rationale is that by default workflows run for draft pull requests anyway, and therefore covering ready_for_review would be redundant. Though that seems quite error-prone for users who configure their workflows to not run for draft PRs and then forget to consider that they have to explicitly specify ready_for_review as additional activity type. Might be worth asking GitHub support about this (?).
    Edit: Have created https://github.com/orgs/community/discussions/139644 ↩
@peter-evans
Copy link
Owner

Hi @Marcono1234

Interesting workaround for triggering further workflows. I don't think ready_for_review not being a default event on pull_request makes it pointless. It just means if you want to use this workaround you would have to explicitly add that event.

As for converting back to draft, I suppose that matches the design of the rest of the action. I've tried to make update of PRs be consistent with the inputs supplied, so the action does it's best to reflect that. The draft input is about the only input that works differently. I wouldn't be against supporting this and having the option to always be consistent with the action input.

I think there is a path I can take to use the same draft input, but also not break existing users. Don't think that will be a problem.

I summary, I think I would be happy to support this, assuming the GraphQL API works as expected.

@peter-evans
Copy link
Owner

Hi @Marcono1234

I'm adding this feature to the upcoming v7 release.

You can set always-true to convert back to draft on updates. Feel free to try the release candidate like this:

- uses: peter-evans/create-pull-request@v7-rc
  with:
    draft: always-true

@peter-evans peter-evans mentioned this issue Aug 18, 2024
Merged
39 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

v7 - signed commits peter-evans/create-pull-request
2 participants
@Marcono1234 @peter-evans