Open Marcono1234 opened 4 months ago
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.
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: https://github.com/peter-evans/create-pull-request/issues/48#issuecomment-1411863193
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 theready_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?[^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 coveringready_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 specifyready_for_review
as additional activity type. Might be worth asking GitHub support about this (?).