updating boost.unordered with new boost-ci: a field-report

[tobias-loew]

Last week, I started integrating the new boost-ci with boost.unordered.
At that point, boost.unordered's tests were mostly failing and for that reason there hadn't been a PR for the new drone-ci. So, I started out on my own fork of boost.unordered and Sam Darwin enabled my account to run tests with drone. Here's a short protocol of what I did and how it worked out:

• integrating boost-ci with boost.unordered
  • the docs for integrating the new ci are easy to follow
  • the only missing point is: set executable-flag for .drone/drone.sh in git
  • after that, Travis, AppVeyor and Drone were triggered to run the tests
• since some days Travis-CI rejects the builds, and I don't know why
• AppVeyor: VisualStudio-builds work, but it has troubles setting up the mingw environments (mingw on AppVeyor failing - can we do anything about it? #75)
• Drone works mostly
  • the Address Sanitizer (asan) refuses to run for my fork, as it is considered untrusted
  • Valgrind sometimes is killed due to time limitation (time limit seems to be 1 hour)
  • drone.star instrumentation
    • problems with clang-9, 10 and 11 with boost.unordered (I had to disable clang-10)
    • in clang configs: changed the std-library version to match the clang version
    • added clang-12 config, with std-library-version 11 (std-library-version 12 doesn't seem to exists - I'm not a clang expert!)

Summary:
boost-ci integrates seamless with other boost projects and works out of the box. The upcoming problems originated from the CI-platforms (Travis refusing, Appveyor cannot install MinGW) and the failing tests in the boost-project (buggy compilers / test-code).

[Flamefire]

Some comments:

since some days Travis-CI rejects the builds, and I don't know why

Travis has a quota on the free service. So unless you pay for it it is unsuitable for Boost libs.

Valgrind sometimes is killed due to time limitation (time limit seems to be 1 hour)

Better get ASAN/UBSAN running. Can be done via B2 and the new boost-ci scripts have first-class support for that IIRC. Check the options :) (B2_ASAN=1, B2_UBSAN=1) Not sure what is meant by "considered untrusted" and why that prevents ASAN to run. Sounds like something else to me, maybe check that further.

problems with clang-9, 10 and 11 with boost.unordered (I had to disable clang-10)

Sounds like an opportunity to improve Boost.unordered. Best to open issues for that in the unordered repo

[tobias-loew]

Here are the asan-errors: (https://drone.cpp.al/tobias-loew/unordered/19/2/1)

Linux asan: linter: untrusted repositories cannot enable privileged mode
Linux asan: Error

I'm not sure whether that disappears when run against the original-repo (and not my fork)?

[Flamefire]

I'm not sure if this flag is even required. You could try removing 'DRONE_EXTRA_PRIVILEGED': 'True' and privileged=True from the drone cfg

[sdarwin]

"asan" jobs requires ptrace capabilities on the docker container. The current solution is to set the repo to "Trusted", which I have just changed for your fork of boost.unordered. By removing the privileged=True flag, the job will run without privileges. Perhaps your tests are not actually utilizing "asan" and therefore they appear to succeed because they aren't running the tests.

You have modified the std library versions to match clang. The question is, if clang and std library are separately managed projects, maybe there's no correspondence between the versions and they do not need to match? Were the builds failing because of the std library version?

• updated README.md about asan
• updated README.md about setting executable-flag for .drone/drone.sh

[tobias-loew]

Hi Sam, I realized later that libstdc++ is the gcc version and thus matching the version with the clang version is bollocks.Clang 9 - 11 give a hard error when selecting a deleted ctor in a sfinae context. By changing the stdlib I tried to address that. I have to check the original configuration again. But checking each clang with each libstdc++ would give a lot of test cases. Since I'm neither a GCC nor clang expert, I don't know what are reasonable combinations.Another thing: I think I have used up all the free Travis runs. Is there anything I can do about ( apart buying new runs), or will I get new runs in a month or so?

[sdarwin]

By changing the stdlib I tried to address that.

This is an open question - which is the best choice of stdlib to match each clang version? We can keep it in mind, and possibly change the .drone.star example file in this repo. Pull requests are welcome - especially if it's conclusive the builds won't succeed without an updated library.

I have used up all the free Travis runs. Is there anything I can do about?

The main motivation for developing Drone was to replace Travis. So, you are already following the path to a solution which is implementing Drone.

You could "Copy the ci.yml file from this repository to .github/workflows/ci.yml of your repository", and get Github Actions going also. That provides very similar test coverage, a level of redundancy.

[jeking3]

The latest Boost.CI reusable GHA workflow makes integration much easier than it was before and allows us to make changes that fix many environmental issues for our repositories from one place.