Good question! It's not possible at the moment, but wouldn't be too tricky to add in future. Right now we're focussed on integrating into GitHub, but once that's finished (likely ~6 months I'm afraid) I'll pick this up. I also hope we'll have support for vendoring around then!

Similar reasoning - internally we block CI/CD on draft status - a lot of our teams have dependabot configured to create 1 PR at a time to avoid flooding the CI server with jobs - having them open as draft would solve that.

It would serve as very useful in combination with Github Actions as well. Right now I am excluding workflows from being run on draft PRs, which could be very useful for dependabot PRs too.

I also believe #1963 is a duplicate here?

Has there been any movement on this? My team is also using draft status to block certain expensive CI checks and would like to use this approach with our dependabot PRs as well.

Has there been any movement on this? My team is also using draft status to block certain expensive CI checks and would like to use this approach with our dependabot PRs as well.

AFAIK it's still not possible, but to save money on just the dependabot PRs you can use:
rebase-strategy: disabled

Then it'll only run when the PR is created and each time afterwards will require a manual rebase.

You can already use either the PR's name or label to prevent running expensive CI checks. Draft is not available on private repositories for free accounts, so these solutions are more widely applicable than using "draft" to accomplish the same goal.

Option 1: Using PR name

Set a "[Draft]" prefix in the PR's name:

version: 2
updates:
  - package-ecosystem: npm
    directory: "/"
    schedule:
      interval: daily
      time: "11:00"
    commit-message:
      prefix: "[Draft]"

Set your github action to not run if that prefix exists, but to recheck when the name changes. When you want to "take it out of draft" you just rename the PR. To "put it back into draft" you rename it back.

on:
  pull_request:
    types: [ opened, synchronize, reopened, edited ]
    branches: [ main ]
      
jobs: 
  expensive_ci_job:
    if: !contains(github.event.pull_request.title, '[Draft]')
    name: Spend Money

Option 2: Using PR label

Set a "draft" label when the PR is created:

version: 2
updates:
  - package-ecosystem: npm
    directory: "/"
    schedule:
      interval: daily
      time: "11:00"
    labels:
      - "draft"

Set your github action to not run if that label exists, but to recheck when the labels change. When you want to "take it out of draft" you just remove the label. To "put it back into draft" you re-add the label:

on:
  pull_request:
    types: [ opened, synchronize, reopened, labeled, unlabeled ]
    branches: [ main ]
      
jobs: 
  expensive_ci_job:
    if: !contains( github.event.pull_request.labels.*.name, 'draft')
    name: Spend Money

You can already use either the PR's name or label to prevent running expensive CI checks. Draft is not available on private repositories for free accounts, so these solutions are more widely applicable than using "draft" to accomplish the same goal.

Do note that the PR's name is set at initial creation, while the labels are set slightly afterwards, so if you're not using concurrency to kill previous jobs, using name instead of labels would be more reliable.

+1

This is possible with Renovate https://docs.renovatebot.com/configuration-options/#draftpr.

Related:

• When Dependabot is Rebasing or otherwise updating a PR, it should be put into Draft #2379

Any update on this in terms of when it might be planned? We provide a CI service that creates PR previews for various git providers including GitHub, and we get asked a lot about not building dependabot PRs, so having a create as draft option for dependabot PRs would be very helpful for GitHub customers.

Do we have any updates here? seems like quite a lot of folks would like this.

Another use case (not related to CI) that would benefit from ability to create draft PRs is automatic PR review requests based on the code owners.
Right now, since PR is created as ready for review, reviews are requested asap. This creates unnecessary noise in situations when PR needs some manual polishing to ensure that CI passes. We would prefer the PR assignee to first look over the new PR and once it has been confirmed that everything is good - mark PR as ready for review which would then automatically request review of code owners and notify them.

+1

+1. This would be useful.

I opened #9169 without seeing this issue. I think it would be very helpful.