Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move CI to GitHub Actions #176

Closed
Morwenn opened this issue Nov 23, 2020 · 4 comments
Closed

Move CI to GitHub Actions #176

Morwenn opened this issue Nov 23, 2020 · 4 comments
Labels
Milestone

Comments

@Morwenn
Copy link
Owner

Morwenn commented Nov 23, 2020

I planned to move the continuous integration to GitHub Actions at some point, but the recent changes to Travis CI mean that we will likely have to move sooner rather than later.

@Morwenn Morwenn added this to the 1.9.0 milestone Nov 23, 2020
Morwenn added a commit that referenced this issue Nov 23, 2020
First step to move the build to GitHub Actions: move the coverage
generation from Travis to Actions. It doesn't generate additional
information with lcov anymore, and now always runs on the latest
available Ubuntu.

[ci skip]
Morwenn added a commit that referenced this issue Nov 26, 2020
The following modifications were needed:
- Use the GitHub Action codecov/codecov-action
- Rename the workflow from codecov.yml to code-coverage.yml, otherwise
  the Codecov Action things it is the Codecov configuration file
- Change codecov.yml to ensure that the test files are not covered

[ci skip]
Morwenn added a commit that referenced this issue Jan 2, 2021
This commit also comments the Travis CI MacOS configurations, because
they there too slow to run to completion anyway.

[ci skip]
Morwenn added a commit that referenced this issue Jan 3, 2021
This commit is hopefully the last to get things to work with MacOS
builds. Compared to the old Travis CI builds, we don't have Valgrind
builds, but we have g++, ubsan and asan ones, which is more coverage
than what we used to have.

[ci skip]
@Morwenn
Copy link
Owner Author

Morwenn commented Jan 4, 2021

Forgot to mention it, but commit 1de7526 add a workflow for Ubuntu.

@Morwenn
Copy link
Owner Author

Morwenn commented Jan 5, 2021

I got the following kinds of builds working:

  • Debug, Release
  • Ubuntu, MacOS, Windows
  • g++ (including MinGW-w64), clang++ (including AppleClang)
  • Valgrind, asan, ubsan
  • libstdc++ and libc++ (I think)

While a bit different from the old Travis CI builds, I believe that I cover an equivalent amount of possibilities. There main differences are as follows:

  • No Clang build older than Clang 6
  • GCC builds for MacOS
  • Asan and ubsan builds for MacOS
  • No Valgrind builds for MacOS

This is pretty satisfying as everything runs smoothly. There are a few additional steps before closing the issue:

  • Deactivate the Travis builds for cpp-sort
  • Remove .travis.yml
  • Remove the OSX suppression file since I don't have Valgrind build on MacOS anymore
  • Remove the mtime_cache_globs.txt file, not used anymore
  • Change the README to mention the new supported (as in tested) compilers
  • New README badges for the builds, move them to "Compiler support & tooling"
  • Use strategy.matrix.config to simplify build YAMLs
  • Re-enable ccache through actions/cache, I don't think that mtime_cache is needed anymore

Morwenn added a commit that referenced this issue Jan 5, 2021
- Remove the license badge, redudant with GitHub UI
- Better text for release and Conan badges
- Remove the Travis CI badge
- Add build badges to the compiler support section
- Update the information about supported compilers
@Morwenn
Copy link
Owner Author

Morwenn commented Jan 5, 2021

Commits 2cc9016 and 13157e2 simplify the MacOS and Ubuntu build matrices respectively, making them more understandable, less redundant, and easier to maintain.

@Morwenn
Copy link
Owner Author

Morwenn commented Jan 5, 2021

actions/cache@v2 has some significant drawbacks so far:

  • No way to clean the cache through the UI
  • Rather verbose
  • Doesn't play well with ccache so far, it still lacks critical features for that

Considering that the build times are currently decent even with a full rebuild, I consider that making the workflows more complicated is not worth my time. I might give it another try in the future once features and usages have evolved, but currently it's got more cons than pros.

As such, I consider that this issue is in a good enough state for now, and ready to ship.

@Morwenn Morwenn closed this as completed Jan 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant