1
0
mirror of https://github.com/qTox/qTox.git synced 2024-03-22 14:00:36 +08:00
Commit Graph

12 Commits

Author SHA1 Message Date
Anthony Bilinski
b05c069dfe
fix(appimage): Patch snore to enable notifications in AppImage
Patch for other builds as well since the patch is harmless and it simplifies
the build script.

Fix #6411
2022-02-23 21:11:42 -08:00
Anthony Bilinski
e9f74bb50a
chore(deps): Add msgpack to archlinux dockerfile
Missed in last update since it's not covered in CI.
2022-02-19 21:25:00 -08:00
Anthony Bilinski
2fca383e70
chore(deps): Update c-toxcore to v0.2.16 2022-02-19 06:32:51 -08:00
Anthony Bilinski
e076d4b7a7
chore(deps): Add support for msgpack dependency 2022-02-19 06:32:46 -08:00
Anthony Bilinski
68ca7354be
fix(Windows): Add missed openal dll since CI refactor
Old windows/cross-compile/build.sh copied OPENAL_PREFIX_DIR/bin/*.dll to be
included, but the current Dockerfile.windows_builder copies libs one by one
and misses OpenAL. qTox fails to start on launch with due to missing
OpenAL32.dll on Windows because of this.

Add a special check for OpenAL, since the generic missing dll check doesn't
cover it.
2022-02-17 12:41:09 -08:00
Anthony Bilinski
79feb19d7d
fix(CI): Update Wine from 5 to 7 in docker image to fix unit tests
Root cause is unclear, but fixes failures in test_bsu and hangs in
test_smileypack.
2022-02-17 10:10:20 -08:00
Mick Sayson
88edc66f88
fix(buildscripts): Fix license text for MIT derived works 2022-02-17 10:10:20 -08:00
Mick Sayson
1288a0a7fa
chore(ci): Windows docker build fixes
* Fix unit tests not running in windows build
* Fix missing comment ports from old build script
2022-02-17 10:10:20 -08:00
Anthony Bilinski
b657fa2bc6
chore(deps): update c-toxcore to v0.2.15 2022-02-17 08:58:05 -08:00
Anthony Bilinski
90484a1fdf
chore(CI): Replace CentOS 8 CI with AlmaLinux
CentOS is EOL, and AlmaLinux seems like the closest successor
2022-02-08 02:08:42 -08:00
Anthony Bilinski
e405868037
chore(build): Update build_toxcore_linux.sh to handle relative call paths 2022-01-09 18:52:53 -08:00
Mick Sayson
8abe8320d2 chore(CI): Use docker for CI scripts
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
2021-12-19 14:56:05 -08:00