Remove adding ubuntu-toolchain-r-test PPA by default

[Flamefire]

Don't add the toolchain repo by default anymore.

Using $ADD_UBUNTU_TOOLCHAIN_PPA=true allows to still add it for Drone.
For GHA there is the sources matrix entry for this purpose.

Most issues should be fixable by using a suitable Ubuntu version

[sdarwin]

@Flamefire , please don't break backwards compatibility with all existing drone CI installations, causing CI to switch to red on many repos. Toolchain is not such a terrible mistake. Arguably, it is convenient, and not such a problem.

The variable "$UBUNTU_TOOLCHAIN_DISABLE" already exists.

What could be done: in the example drone.sh file, set "$UBUNTU_TOOLCHAIN_DISABLE" == "true" so that developers start out with the more strict setting if they clone drone.sh as their example.

Optionally: download the whole boost.org superproject, search for drone installations, and submit pull requests to set "$UBUNTU_TOOLCHAIN_DISABLE" == "true", along with other necessary fixes so the tests complete. That would migrate those other repositories to the stricter setting.

Then, when they all generally do not depend on toolchain anymore... the switch is more plausible.

[sdarwin]

Adding to the previous comment - in fact there are difficulties with omitting toolchain.

In order to test new compilers, it forces you to use non-LTS releases of Ubuntu, which themselves are not recommended, and often buggy. It's trading one issue for another.

It means you have to keep toggling your drone.star file, to use different operating system versions. Instead of being able to just set it up and it works for a long time. So the point is, that neither solution is 'perfect'. It is a trade-off both ways.

[Flamefire]

There is now ADD_UBUNTU_TOOLCHAIN_PPA to opt-in for drone jobs

[Flamefire]

In order to test new compilers, it forces you to use non-LTS releases of Ubuntu, which themselves are not recommended, and often buggy. It's trading one issue for another.

It means you have to keep toggling your drone.star file, to use different operating system versions. Instead of being able to just set it up and it works for a long time. So the point is, that neither solution is 'perfect'. It is a trade-off both ways.

This was suggested by @pdimov . The main change is basically just that the default is different so not everyone gets this in every job even when just a few need it.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (734e1fd) to head (315051d).

Additional details and impacted files

@@            Coverage Diff            @@
##            master      #252   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            3         3           
  Lines           24        24           
  Branches        11        11           
=========================================
  Hits            24        24           

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 734e1fd...315051d. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Flamefire]

@sdarwin Coming back to this.
IMO it should be uncontroversial to remove it from the reusable workflow as we control pretty much everything there.
Not so sure about the others, but should be fine nowadays and so early in the release cycle that fallout can be fixed, if there is any.

IIRC you did some investigation where this is still required and hence need updates?

Reason for me wanting to do this is that launchpad connections are flaky causing unnecessary failures