GitHub: How to rerun a pipeline if PR changes from draft -> ready or vice versa

We have a step like this:

  - block: "Build draft PR"
    blocked_state: "failed"
    if: "build.pull_request.draft"

Which would be lovely to unblock if the associated PR is moved out of Draft. Do you know of a good way to do this?

1 Like

Hey @john.soo!

You should be able to do this in the Pipeline settings, as seen below.

AFAIK, there isn’t a way to do the opposite; create a build when a PR changes from ready to review to “draft”.



Hey @bmc, thank you! We do have that option enabled. However rebuilds do not happen. I think because of this?

According to the docs:

When the blocked_state of a block step is set to failed, the step that triggered it will be stuck in the running state until it is manually unblocked.

But using passed gives too many false positives and running creates too much clutter. What we really want is to allow pending as a blocked_state.

Hello, @john.soo! Thank you for your feedback. Unfortunately, passed, failed, and running are the only 3 values that are currently available for the blocked_state attribute.


Hi @karen.sawrey do you know how I can get builds to run when the PR changes out of draft?

I tried using blocked_state: "passed" which did nothing. Here are our github settings:

But a build is not triggered when a pull request becomes ready. What am I missing?

Hi, @john.soo! With a block step in your yml, even with the “passed” value for the blocked_state attribute, you’ll still need someone to unblock it manually for the build to proceed.

And to be able to get your builds to automatically rerun when a PR’s state changes from “draft” to “ready for review,” you need to disable “Skip pull request builds for existing commits” in your pipeline settings:

As for the vice versa action - to get the build to rerun when a PR’s state changes to “draft” - it is unfortunately not supported.


Thank you! I am looking into this. We lean pretty heavily on skipping builds for existing commits. I think what would work best for us would be to make the block_state of the block somehow “not run”. I suppose if we could build for existing commits, this could work, but these features do seem mutually exclusive.