Closed lzaoral closed 3 years ago
Thanks for merging #368, @mchalupa! That should speed-up the CI a bit. This PR is mostly done as FreeBSD is not supported by GitHub Actions yet1 and the coloured output seems to be buggy (I will look into that in more detail when I have more time). However, some things still have to be fixed before merging:
dg
here, though.)build log: https://github.com/lzaoral/dg/runs/1517668920
Note, that the ccache
thingy is a bit of an experiment but if it proves to be useless it can be disabled/removed quite easily, also GitHub stores the cache for each job only for a week if there are no new commits in the meantime.
1 Nevertheless, I have set-up a VM and can confirm that dg
builds and runs fine on FreeBSD.
EDIT: LLVM 3.7 was fixed and macOS fixes are in #374
I will probably drop the support for Google Sparsehash. It looked like it works well but there are problems with this library. TSL hashmap works better than Google Sparsehas for us.
I have made some simplifications and disabled LLVM 3.{5,6} as these releases are way too old and making them compatible with dg
is probably not that important either.
Has there been any progress regarding Google Sparsehash?
I think I finally know why the colours were not working. The output in GitHub Actions VMs is not a tty
so ninja
strips from the output every escape code it sees. Since https://github.com/ninja-build/ninja/commit/bf7107bb864d0383028202e3f4a4228c02302961 one can set CLICOLOR_FORCE
to change this behaviour so at least Ubuntu 20.04 will be coloured (unless GitHub changes their output to a tty
).
Has there been any progress regarding Google Sparsehash?
Not yet. But you can just leave it out from the CI configuration for now, can't you?
Ok, google sparse hash dropped.
Thanks! I have just one final question. Do you want to run the CI for every push and PR (as it is now) or just for master
related things?
I'm rather busy at the moment, but I'll try make this PR ready by the end of this week.
Thanks! I have just one final question. Do you want to run the CI for every push and PR (as it is now) or just for master related things?
I thank you. Rather keep it as it is now -- every push and PR. Mainly PRs, so that we are sure that a new PR does not break things.
In that case, I think we are ready! 😄
Hmm, the jobs taking way too long to start but I suspect it's just some temporary problem on GitHub's end as the log says this:
Ubuntu 64-bit (ubuntu-16.04, 3.9, clang)
GitHub Actions has encountered an internal error when running your job.
The good news is that when such error happens, the job is usually restarted automatically.
This is a draft that adds support for GitHub Actions.
At first, I wanted to extend the current CI to more recent releases of LLVM and Ubuntu so that no commits would break compatibility with LLVM\Clang\GCC versions that were not covered before.
However, the total time (even when some jobs were skipped) was around 8 hours which is unacceptable (see https://travis-ci.org/github/lzaoral/dg/builds/744414197) and some jobs would even time-out as Travis has 50 minutes limit for a single job.
So I decided to try GitHub Actions instead. There is a higher limit on a single job (6 hours) and more jobs can run in parallel. While this PR is just a draft and some things still have to be implemented (see list below), the CI finishes in 20 minutes.
I have also decided to make
dg
compatible with systems that have more installations of LLVM and to useninja
as a build-system as its output is less bloated when compared tomake
.Only inconvenience is that Action failure e-mails can only be disabled per account in your notifications settings and not per Action/repository.
TODO: