You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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 (?). ↩
The text was updated successfully, but these errors were encountered:
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: #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 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?
Footnotes
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 (?). ↩The text was updated successfully, but these errors were encountered: