DanRStevens
commented
3 years ago Closing issue.
PR #227 added a second build so we cover both GCC and Clang, so that part is done.
PR #333 removed support for TravisCI.
The other idea was to add pull request builds, which I don't think we should bother with. They add significantly to the test build time without adding significant test value. In particular, there isn't much concurrent activity on this project, and PR builds only provide value when changes have been merged to master after the current branch was branched off. Lately work is largely serial, one branch at a time. Additionally, a PR build can be simulated by merging master into the branch and doing a branch build.
Currently CircleCI builds with a single compiler, and only does branch builds. It does them much faster than other CI solutions though, and with less hassle to keep things updated.
Recently, in #225, the Dockerfile used by CircleCI was updated to support building with either GCC or Clang. This work can be extended to do concurrent builds with both GCC and Clang. I believe the proper way to configure this is with Workflows.
Another area of improvement, is doing pull request builds, that test the result after a branch would be merged to master (or the pull request base branch). This means no surprises after merging. This could be done in addition to branch builds, which test branch changes in isolation from other development on master. To perform a PR build, the checkout step would need to be updated to put the source tree in a state after a merge.
Of course if this can be done on CircleCI, that may make some of the TravisCI builds redundant. In that case, we could potentially retire the redundant builds.