[ci] revisit build stages

[blueyed]

It is a bit frustrating to have a PR fail fast due to the early "linting" stage failing.

Normally "linting" should come on top, i.e. in the end.

I can see that it is useful to have an initial stage that fails the build quickly (instead of letting all jobs fail slowly), but that should not be "linting", but one of the other jobs that is rather fast.
But since it will only run one job then first, I suggest to instead put "py27", "py34", "py35", and "py36" into the first stage ("py37" uses sudo=false, so is slower) - typically 4 jobs are run in parallel, so this would be faster in the successful case, but would still avoid running all other jobs in case one of them fails.

[nicoddemus]

I agree, that seems more useful indeed. How about adding linting to the list of initial jobs as well? And I would also consider putting only py27 and py36 as a quick overall check. After those pass, we then go to more specialized ones.

So I suggest these stages:

1. "<some good name>": py27, py36, linting
2. all the rest
3. deploy

What do you think?

[blueyed]

Sounds good!

For "some good name" we could use "quick tests".

[blueyed]

Let me know if I should do it.

[nicoddemus]

Please go ahead. 👍

As it was @RonnyPfannschmidt who introduced the linting stage, we can wait for his opinion over the PR.

[RonnyPfannschmidt]

I like the idea, Let's call it baseline

[nicoddemus]

I like baseline 👍 😁