Draft pull requests not being built

Travis CI Discussions & Feedback
1

Travis CI doesn’t seem to build new Draft PRs.
So far I opened three PRs in Draft state in two different repositories, neither triggered a build nor received any status from Travis CI.
Closing and reopening doesn’t help either (as this used to fix similar issues earlier).

Verified that GitHub send a webhook event about the new PRs, all were acknowledged by Travis CI API with HTTP 204.

Reference request IDs:

  • 571bb7e0-374b-11e9-9d36-41c3b6d02c67
  • fbdc20b0-3711-11e9-9614-15d7031d32c9
  • 30842560-370d-11e9-9d74-30c92cde30fd

Environment: Open-source repository on travis-ci.org, not using Checks API.

Draft PRs is a new feature added on 14/2/2019, see https://twitter.com/github/status/1096093162345508864.

8 Likes
2

Note that once the PR changed state from Draft to Open (“XXX marked this pull request as ready for review a minute ago”), the build was triggered.

The build should be triggered for drafts too, otherwise it undermines the purpose of draft PRs.

2 Likes
3

This feels like expected behavior to me.

From the Github post introducing draft PRs:

But what if you want to signal that a pull request is just the start of the conversation and your code isn’t in any state to be judged? Perhaps the code is for a hackathon project. You have no intention of ever merging it, but you’d still like people to check it out locally and give you feedback. Or perhaps you’ve opened a pull request without any code at all in order to get the discussion started.

3 Likes
4

It definitely does not sound like the expected behaviour to me.

But what if you want to signal that a pull request is just the start of the conversation and your code isn’t in any state to be judged?

That is fine, I still want to know if it builds. Especially important for projects targeting multiple platforms or environments (i.e. DBAL).

but you’d still like people to check it out locally and give you feedback

You don’t want people to check out broken code that can’t even run.

Or perhaps you’ve opened a pull request without any code at all in order to get the discussion started.

You can use [skip ci] with an empty commit.

3 Likes
5

Hello, there.

We have an internal discussion on this topic. We have not yet reached a consensus on how to proceed. We’ll post an update when we do.

Thank you!

2 Likes
6

It definitely does not sound like the expected behaviour to me.

Nor for me. This new github’s feature mostly useless for users of travis-ci.

4 Likes
7

I am definitely missing this feature too. I want to know if my project builds, and that for every single commit. That’s also what the “continuous” in the CI stands for me :wink:

Currently I am really glad that we have the same tests running on AppVeyor, because they handle it properly :slight_smile:

8

Hi @BanzaiMan! Glad to hear there’s an ongoing conversation. Are there any updates?

I’m honestly having a hard time understanding why this wouldn’t be supported, but then again I’m not involved in implementing it :slight_smile:

3 Likes
9

We definitely need it!

10

Hey? Any news on that? We have hard time justifying the usefuleness of Draft PRs without this feature enabled

1 Like
11

In the administration panel there should be an option to enable or disable Travis for draft pull request. I really want to have Travis all the time. I work on large projects, where it is not possible to run tests locally. I need a travis for draft pull request also.

4 Likes
12

Just started to encourage our contributors to use Draft Pull Requests and found out they’re not getting built by Travis. Please enable by default and add a setting to allow disabling?

1 Like
13

Any updates on this @BanzaiMan?

1 Like
14

Related: Removing Draft doesn't trigger Travis - removing draft status doesn’t get a PR build

15

Fwiw, since I have a travis-ci account for open source stuff, the fact that a draft PR wouldn’t build in the open source repo’s travis-ci account doesn’t bother me much – because as soon as I pushed my branch to github, travis-ci picked it up there. And in my case, being able to open a draft pr while travis-ci is still running for my branch would be a good thing (especially since I want to write my PR message now and then go to a different location where I wouldn’t have my PR message – and convert the PR from draft to real once I see my travis-ci account’s build has completed successfully).

I wonder how this applies to other users, are they working on open source projects, in which case, should they just try setting up travis-ci accounts? Or are they working on closed projects, in which case, I think they can ask travis-ci to build individual branches… (And yes, I’m cognizant of the “I shouldn’t be forced to sign up for a new account” attitude, I often have share it.)

Personally, having travis-ci post a note for open source repositories explaining why it didn’t build and giving users the ability to set up their own travis-ci account seems like a reasonable path forward.

1 Like
16

Thank you all for your feedback and patience, I can confirm that we’re actively working on supporting Draft PRs, for that, we’ve had to update how we identify if a Pull Request should trigger a build or not, for example, PRs that are not mergeable won’t trigger a build.

We’ll post an update as soon as this is out, we’re taking this opportunity to also simplify a bit our logic around this :slight_smile:

17

I think you’re overcomplicating it. :confused:

for example, PRs that are not mergeable won’t trigger a build.

This sounds like a bad idea to me – there are valid use cases when PRs are non-mergeable and should still build, for example any non-rebased work (rebasing could be quite a lot of work in many cases).

18
19

If you see issues with how we handle Draft PRs, please open new topics. Thanks.

1 Like
20

@BanzaiMan,

Building draft PRs should be an option and not default behavior. And the default should be to NOT build drafts. This enables a PR to be updated without triggering builds after each revision. Think about it - a PR can be switched to draft to temporarily stop the upstream repo from rebuilding the PR while revisions are taking place then switched back to open when the author feels that the PR is in a proper state for the upstream repo to do their own tests.

Keep in mind - the whole point of a draft PR is to say - this PR is NOT ready for review!!!

If this becomes standard practice - everybody can save on building resources.

1 Like