Recently travis announced their plans to kill current (concurrency-throttled, but virtually unlimited) plans for public / open-source repositories.

Public announce: https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing
Summary: https://www.theregister.com/2020/11/02/travis_ci_pricng/

That has a big impact on everybody (HQ and non HQ) and far as all the "pushes" and PRs against repositories now account by reducing the number of remaining "credits" in all the (usage-based) plans (specially in the new free plans where everybody is being moved to by default).

And that affectst both to core (where we share a default .travis.yml file that everybody is using) and in other public moodlehq repositories (say moodle-plugin-ci, codechecker, 3rd part plugins... a bunch of them) practically all accepting PRs). Again, HQ and non HQ.

There are various initiatives going around (discussions, to-pay-or-not-to-pay, ask/request for their new open-source plan and see what it provides, find-alternative ci/cd solutions out there...), and we should be unifying all them and their information soon.

While that happens (lots of open fronts right now), one simple measure to "alleviate" the spending of credits (free or paid) for all the people developing moodle-core patches around is to make the bundled .travis.yml lighter/quicker.

Right now we run 3 complete phpunit jobs there, see this, for example (random pick). And that takes 1h45m to finish (aka, ~ 100 minutes = 1000 credits).

So, an immediate action to try to reduce the spent credits would be to reduce the number of phpunit runs down to 1 (oldest php version one, surely).

Note that, later, all those branches are already re-tested, both by pre-checks and post-checks @ ci.moodle.org so, if there is any problem with any combination (php version, database version...) we'll be able to detect it there.

So, as an emergency measure... this is a proposal to perform that reduction down to just one phpunit run in core (commenting out the two highest php version ones). That will, immediately, reduce the minutes to 1/3 (aprox! ignoring other little tasks), same for credits.

Later we can think if we want to allow that to be configurable (each dev deciding via ENV configuration...) or other details. But right now, the sooner we reduce the consume of credits the better for everybody.

Let's see how the whole thing evolves, ciao