Motiviation:
* Reproducing issues in CI is currently difficult
* Predicting issues in CI is currently difficult if you are not on
ubuntu 18.04
* Reproducing issues submitted from other distros is currently done by
creating a VM of that distro and building qtox for it locally
* Documentation for how to build on different distros is out of date
* Issues on non-ubuntu distributions are not caught by CI
* Cross compiling for windows locally is not trivial
* Iterating when working with custom build scripts is slow, scripts
don't necessarily support re-running without re-starting the docker
container and re-building qtox again
* Updating dependencies is a pain
Changes:
* docker-compose file has been added to the root of our repo.
After `docker compose run --rm ubuntu` (or other supported distros),
you are ready to compile and run qtox
* Dependencies are owned by dependency install scripts in buildscripts/.
This allows us to use the same exact dependencies in our
OSX/windows/linux scripts
* New docker images have been added for a variety of distributions.
These are now run in CI in a variety of configurations
* Docker images are cached in CI so rebuild time for the majority of
jobs is quite quick
* Build scripts have been trimmed to leverage state of docker
containers.
* Windows build script no longer installs anything, dependencies are
now managed by the windows_builder docker images
* Build scripts should now be easily re-runnable. Usage is now `docker
compose run --rm <image>` and then run the scripts
* All artifacts are now uploaded to github after build, this means we
can take an appimage/flatpak/exe/dmg for any given PR and try it out
without having to build it ourselves
Notes:
* Docker image size is quite important. We have a maximum of 5GB cache
space on github actions. The majority of the linux distro docker
images cache at ~300-400MB, which gives us room to test ~6 distros
after accounting for the sizes of flatpak/windows docker images
* Docker layer ordering is relatively intentional. Approximate order
should be that large dependencies that change infrequently should be
farther up. This lowers the amount of rebuilding we have to do when
dependencies are updated
* download_xxx.sh scripts are the cleanest way I could find to implement
a shared dependency map between osx scripts and docker containers.
Although it would be nice to have a single dependency mapping file,
splitting it into individual scripts allows us to only rebuild some
docker layers when dependencies are updated.
* Github actions are split between docker image building and docker
image use. This allows us to re-use the same docker images for
multiple jobs, but only build it once
* Unfortunately I could not find a way to de-duplicate the stitching
between jobs, so we have a lot of copy pasta in that area
bsdtar has moved to libarchive-tools package.
Something has changed in the newer gcc or mingw that makes Opus and
Sodium fail to build with:
undefined reference to `__memcpy_chk'
The solution is to use -lssp or -fstack-protector, but while -lssp
worked for Opus, it was breaking Sodium's `make install` as it prevented
the .def file from being generated during the build time for some
reason:
/usr/bin/install: cannot stat './libsodium-24.def': No such file or directory
while -fstack-protector worked just fine, so -fstack-protector was used
for both. This adds a new library dependency on libssp-0.dll.
Partially fix#6345, only PR portion, not nightly or releases.
Unlike travis, we're not caching our brew packages. `actions/cache` doesn't
update the cache on cache hit, making it hard to use a rolling cache like
before. We also don't know what cache key we should use before running, since
it relies on the live package list of brew.
Using a docker image containing brew packages seems like a better option if we
need the speedup going forward. ATM a full build with deps only takes about 12
minutes. Windows builds don't have this issue, since deps there are keyed off of
known versions in our repo.
Current Windows matrix form works, but causes a double-build on dep change due
to both debug/release rebuilding the release deps. Instead, should probably
separate the dep jobs, block build on the dep jobs, and update the cache on dep
jobs, guaranteeing a cache hit on build jobs?
Windows stage 1 and stage 2 can probably be recombined, if they were split due
to travis single build length limits, since GH actions allows much longer single
builds.
This change adds a cmake configuration switch to enable code coverage
instrumentation during the compilation of the project. When tests are
executed, the instrumentation outputs coverage data to output files in
the build directory. Programs such as lcov/gcovr can turn that data into
reports.
This change also adds steps to the travis CI configuration to build with
this configuration switch and then use lcov to generate the consolidated
report and publish to codecov.io
Brew disabled updating from shallow clones:
https://github.com/Homebrew/brew/pull/9383
The update is also uneeded since our .travis.yml already has `update: true` for
the brew extension.
seccomp is used by the docker host, and the default version shipped with
Ubuntu 16.04 does not support syscalls used by Qt5's configure inside the
docker container. Upgrading libseccomp2 resolves this issue.
Fix#5874
Nightlies and windows releases are now done through CircleCi and travis
Branches "for-jenkins-release" and "for-jekins-testing" will be removed
when this is merged.
The reason to update is, that brew only supports 10.12 officialy and
with binary packages so our CI builds started failing because compiling took too long.
Mick Sayson
Anthony Bilinski
Maxim Biro
Jamie Westell
sudden6
jenli669
TriKriSta
Diadlo