Have you seen the updated description of #1259? While the tests run much faster now, it's still wasteful to run long builds for commits that didn't change any code.

IMHO, Travis currently takes 15 minutes to run the whole thing, which isn't that long. It's not an ideal allocation of compute resources, but I don't see the harm - a few extra occurrences of 15 minute builds isn't going to really impact global warming, and since the builders are free, it's not going to break the bank either :)

Plus, if you run full tests for each PR, you always know the full tests pass. If you get "fancy" and try to run a subset, it's possible to make a mistake and not run a test that should have been run due an error in the test harness. I think KISS is the way to go.

In this PR, the tests also fast fail (that's due to the set -e in the scripts section) so if there's a failure, it'll be reported as quickly as possible and the rest of the steps don't run. I also ordered it so the fastest stuff is first.

Ok, let's do it for now. If we want to improve this in the future, here are some links:

One thing I currently don't like is that Docker images are re-built every time – looks like the layer caching is missing. This is not only inefficient but also produces a lot of noise in Travis logs. I'm not sure how Docker caches this but if this could be added to cache, it would be great.

Overall, it's awesome to see the test passing on a CI! 🤖

Thanks for the changes, I'll take a look shortly.

I'd just like to ask for "normal commits" in the future, not force-pushes. For example, the .travis.yml evolved over several commits which is not evident from the history of this PR, and some of the links are broken:

Also, the iis.md formatting fix was first here, then it wasn't (the first force-push), now it's back again (maybe a mistake during the second force-push?), it's all quite confusing.

We prefer multiple smaller commits, some of them heavy WIP, over "clean" (but fake) history.

We prefer multiple smaller commits, some of them heavy WIP, over "clean" (but fake) history.

No problem - different projects have different requirements, and I've recently been working on ones that use a different model :)

Thank you, it's not documented very well right now, our fault ;)

Thanks, @candrews! I've created a separate issue for Docker caching: #1419.