[ee7]

Problem specifications

Exercise description
Canonical data

Implementation details

The example solution is deliberately kept very similar to the other resistor exercise: resistor-color.

[ee7]

I cannot change this pull request to be "ready for review". See exercism/exercism#4751.

Maybe somebody with write access to this repo could try to change the state of this PR?

[cmccandless]

@ee7 the "Ready for review" button is visible for me, so I will go ahead and push it.

[ee7]

@cmccandless Thanks. The "Ready for review" button has reappeared for me too.

By the way, it looks like Travis doesn't run automatically when you "un-draft" a pull request.

But it does run if there's a force-push after it's "ready for review". So I force-pushed a commit that only changes a timestamp.

[cmccandless]

@ee7

By the way, it looks like Travis doesn't run automatically when you "un-draft" a pull request.

I wouldn't expect it to, since no new commits were added. I didn't notice; did Travis run on commit(s) added to the draft PR?

[ee7]

@cmccandless That's what I mean: Travis didn't run on the draft PR. It ran for the first time after I made that force-push.

This behavior should be visible on https://travis-ci.org/exercism/python/requests.

Here's what happens:

Step	Description	Travis runs?
1	Create a draft pull request from some branch	No
2	Push to that branch	No
3	Press the "Ready for review" button	No
4	Push to that branch	Yes

[cmccandless]

Hmm... that is interesting. Perhaps checks simply don't run on Draft PRs then? I would not expect that to be correct behavior... I'm going to run some experiments to verify this.

[ee7]

Perhaps checks simply don't run on Draft PRs then? I would not expect that to be correct behavior...

From the Travis docs:

If a pull request isn’t built or doesn’t show up in Travis CI’s user interface, that usually means that it can’t be merged. We rely on the merge commit that GitHub transparently creates between the changes in the source branch and the upstream branch the pull request is sent against.
So when you create or update a pull request, and Travis CI doesn’t create a build for it, make sure the pull request is mergeable.

Draft pull requests are a very recent feature. But if they aren't considered "mergeable", then the observed behavior could be "correct".

But yes, it would be more convenient and intuitive if either of these triggered a build:

• Opening or pushing to a draft PR.
• Setting a draft PR as "ready for review".

[cmccandless]

Apologies for leaving this hanging. I've been trying to decide how to fit this into the track, and finally just settled on leaving it as core: false, unlocked_by: null. I'm part-way through an effort to overhaul the track exercise ordering anyway, and this can just fold into that.

I'll go ahead and merge; thanks for working on this!