search

boostorg / python

Boost.org python module
http://boostorg.github.io/python
Boost Software License 1.0
468 stars 201 forks source link

Travis Going Away - Need CI Replacement #334

Closed teeks99 closed 3 years ago

teeks99 commented 3 years ago

It looks like travis-ci.org is going to get a lot more restricted for open source projects. At the end of the month, it will have to be moved to travis-ci.com at the very least.

teeks99 commented 3 years ago

I'd like to propose moving to Github Actions, a lot of other people who were previously using Travis are heading there.

Towards that end, I'm submitting pull request #335 . This is only a start (hence opening this issue to track to completion). I attempted to match the eight tests that are currently running on linux, without allowed failures. This doesn't include Mac OS (but it could) nor does it include pypy or documentation. Trying to walk before running.

I had attempted to use Github's ubuntu-latest (18.04) or ubuntu-20.04 images for this, but wasn't able to get it working. Too many issues with installed versions of python and ld (see this branch). Instead, I made docker images (docker hub) for gcc and clang that are basically a more controlled way of organizing the tools and doing the caching that was done in travis.

teeks99 commented 3 years ago

There are a bunch of other CI services that are worth investigating. Notable among them (and ones I've used or at least played with, and can recommend) are CircleCI and Azure Pipelines.

teeks99 commented 3 years ago

The current travis files depend on boost 1.66 for testing. This seems rather old, is this the last one that supported C++98? Would it make sense to move to the latest version (currently 1.75)? Should we be testing against boostorg/boost master/develop branches?

stefanseefeld commented 3 years ago

Boost.Python's dependency on the rest of Boost is rather limited, so I haven't taken the time to "upgrade" to a more recent Boost version. But if we move away from Travis-CI, we can of course change all that.

stefanseefeld commented 3 years ago

Thank @teeks99 for raising the issue with Travis-CI. I'm looking into github actions right now, trying to figure out how to migrate. If you have suggestions or want to help, I'd be happy to hear it.

teeks99 commented 3 years ago

Yeah, I've gotten most of it setup in the pull request that I mentioned above. Did you get to look at that?

teeks99 commented 3 years ago

If we're going to include a boost version in the docker images, I'm thinking we should put that in the tag....I'll update the docker stuff to include that.

Any interest in running against more compiler versionss (I keep a good stable of gcc/clang versions here, easy to add)?

teeks99 commented 3 years ago

How about interest in running against other c++ std's?

stefanseefeld commented 3 years ago

It's good to have such build variants available (compilers, C++ standards), but I think it would be wasteful to run all of those on each commit / PR.

teeks99 commented 3 years ago

Maybe nightly against master/develop?

stefanseefeld commented 3 years ago

...or even weekly, yes. (I need to familiarize myself with what schedulers exist with github actions.)

teeks99 commented 3 years ago

Instead of having a workflow that is triggered by a push/pull request, you can have it triggered by cron.

teeks99 commented 3 years ago

I've got a branch going with an attempt at support for mac, but it is failing to find boost/config.hpp or build/src/clang++-12.0.0/x86_64/shared/libboost_python27.so. I'm not fluent in Faber, is there something that needs to be setup for these? I'm especially confused about the first one as I tried to keep it very close to what is working on travis.

stefanseefeld commented 3 years ago

The transition away from Travis-CI is completed.