StarMirror/qTox
1
0
Fork 0
mirror of https://github.com/qTox/qTox.git synced 2024-03-22 14:00:36 +08:00
Code Issues Projects Releases Wiki Activity
e316a683ff
qTox/.github/workflows/build-test-deploy.yaml

576 lines
22 KiB
YAML
Raw Normal View History

chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
name: Build, test, and deploy
chore(CI): Run tests on pushed commits So that each commit in repo is tested, including merge commits that aren't present in PRs. Also prepares for running releases only on push but not on PRs. Workflows have a global runs-on, so commit format check needs to be split out from the shared PR and push workflow to since checking all commit messages on pushes always fails due to very old commits not following the proper format.
2021-09-23 18:39:01 +08:00
on: [pull_request, push]
chore(ci): Migrate PR CI from travis-ci.org and circleci to GitHub Actions 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.
2021-06-21 14:56:15 +08:00
jobs:
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
update-nightly-tag:
name: Update nightly release tag
runs-on: ubuntu-latest
if: github.event_name == 'push' && github.ref == 'refs/heads/master'
fix(CI): Grant action content write permission for release upload By default our organization on GH only grants a more restricted read permission to actions for content APIs, which include both writing to repo for nightly tag creation, and writing to releases for nightly and tag release creation or updates.
2022-01-10 16:01:32 +08:00
permissions:
contents: write
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
steps:
- uses: actions/checkout@v2
- name: Move nightly tag to head for nightly release
run: git tag -f nightly && git push origin nightly -f
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-11-08 13:27:45 +08:00
build-flatpak-docker:
name: Build flatpak docker
runs-on: ubuntu-latest
chore(ci): Migrate PR CI from travis-ci.org and circleci to GitHub Actions 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.
2021-06-21 14:56:15 +08:00
steps:
- uses: actions/checkout@v2
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-11-08 13:27:45 +08:00
- uses: ./.github/actions/build-docker-image
name: "Build docker image"
with:
docker_image_name: flatpak
build-ubuntu-lts-docker:
name: Build ubuntu LTS docker image
runs-on: ubuntu-latest
chore(ci): Migrate PR CI from travis-ci.org and circleci to GitHub Actions 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.
2021-06-21 14:56:15 +08:00
steps:
- uses: actions/checkout@v2
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-11-08 13:27:45 +08:00
- uses: ./.github/actions/build-docker-image
name: "Build docker image"
with:
docker_image_name: ubuntu_lts
build-debian-docker:
name: Build debian docker image
runs-on: ubuntu-latest
chore(ci): Migrate PR CI from travis-ci.org and circleci to GitHub Actions 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.
2021-06-21 14:56:15 +08:00
steps:
- uses: actions/checkout@v2
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-11-08 13:27:45 +08:00
- uses: ./.github/actions/build-docker-image
name: "Build docker image"
with:
docker_image_name: debian
build-debian-old-docker:
name: Build old debian docker image
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: ./.github/actions/build-docker-image
name: "Build docker image"
with:
docker_image_name: debian_old
chore(CI): Replace CentOS 8 CI with AlmaLinux CentOS is EOL, and AlmaLinux seems like the closest successor
2022-02-08 16:26:06 +08:00
build-almalinux-docker:
name: Build almalinux docker image
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-11-08 13:27:45 +08:00
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: ./.github/actions/build-docker-image
name: "Build docker image"
with:
chore(CI): Replace CentOS 8 CI with AlmaLinux CentOS is EOL, and AlmaLinux seems like the closest successor
2022-02-08 16:26:06 +08:00
docker_image_name: almalinux
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-11-08 13:27:45 +08:00
build-fedora-docker:
name: Build fedora docker image
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: ./.github/actions/build-docker-image
name: "Build docker image"
with:
docker_image_name: fedora
build-opensuse-docker:
name: Build opensuse docker image
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: ./.github/actions/build-docker-image
name: "Build docker image"
with:
docker_image_name: opensuse
build-windows-docker:
name: Build windows docker image
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: ./.github/actions/build-docker-image
name: "Build docker image"
with:
docker_image_name: windows_builder
build-windows-i686-docker:
name: Build 32 bit windows docker image
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: ./.github/actions/build-docker-image
name: "Build docker image"
with:
docker_image_name: windows_builder.i686
chore(CI): Replace CentOS 8 CI with AlmaLinux CentOS is EOL, and AlmaLinux seems like the closest successor
2022-02-08 16:26:06 +08:00
build-almalinux:
name: Almalinux
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-11-08 13:27:45 +08:00
runs-on: ubuntu-latest
chore(CI): Replace CentOS 8 CI with AlmaLinux CentOS is EOL, and AlmaLinux seems like the closest successor
2022-02-08 16:26:06 +08:00
needs: build-almalinux-docker
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-11-08 13:27:45 +08:00
strategy:
matrix:
features: [full, minimal]
build_type: [Debug, Release]
steps:
- uses: actions/checkout@v2
- uses: ./.github/actions/load-docker-image
name: Load docker image
with:
chore(CI): Replace CentOS 8 CI with AlmaLinux CentOS is EOL, and AlmaLinux seems like the closest successor
2022-02-08 16:26:06 +08:00
docker_image_name: almalinux
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-11-08 13:27:45 +08:00
- name: Run build
chore(CI): Remove travis config and directory Move all CI scripts to generic .ci-scripts dir
2022-02-17 00:11:27 +08:00
run: docker-compose run --rm almalinux ./.ci-scripts/build-qtox-linux.sh --build-type ${{ matrix.build_type }} --${{ matrix.features }}
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-11-08 13:27:45 +08:00
build-fedora:
feat(CI): Run AddressSanitizer on Fedora build Keep disabled for jobs that produce artifacts to not affect user performance. Keep disabled for other distros that don't produce artifacts as well since other versions of Qt fail themselves in e.g. TestSmileyPack's QGuiApplication usage. Don't enable thread sanitizer yet due to many Qt internal errors. This should still give us a significant increase in qTox coverage, even if we have low platform coverage.
2022-02-17 23:36:14 +08:00
name: Fedora with ASAN
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-11-08 13:27:45 +08:00
runs-on: ubuntu-latest
needs: build-fedora-docker
strategy:
matrix:
features: [full, minimal]
build_type: [Debug, Release]
steps:
- uses: actions/checkout@v2
- uses: ./.github/actions/load-docker-image
name: Load docker image
with:
docker_image_name: fedora
- name: Run build
feat(CI): Run AddressSanitizer on Fedora build Keep disabled for jobs that produce artifacts to not affect user performance. Keep disabled for other distros that don't produce artifacts as well since other versions of Qt fail themselves in e.g. TestSmileyPack's QGuiApplication usage. Don't enable thread sanitizer yet due to many Qt internal errors. This should still give us a significant increase in qTox coverage, even if we have low platform coverage.
2022-02-17 23:36:14 +08:00
run: docker-compose run --rm fedora ./.ci-scripts/build-qtox-linux.sh --build-type ${{ matrix.build_type }} --${{ matrix.features }} --sanitize
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-11-08 13:27:45 +08:00
build-opensuse:
name: Opensuse
runs-on: ubuntu-latest
needs: build-opensuse-docker
strategy:
matrix:
features: [full, minimal]
build_type: [Debug, Release]
steps:
- uses: actions/checkout@v2
- uses: ./.github/actions/load-docker-image
name: Load docker image
with:
docker_image_name: opensuse
- name: Run build
chore(CI): Remove travis config and directory Move all CI scripts to generic .ci-scripts dir
2022-02-17 00:11:27 +08:00
run: docker-compose run --rm opensuse ./.ci-scripts/build-qtox-linux.sh --build-type ${{ matrix.build_type }} --${{ matrix.features }}
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-11-08 13:27:45 +08:00
build-debian:
name: Debian
runs-on: ubuntu-latest
needs: build-debian-docker
strategy:
matrix:
features: [full, minimal]
build_type: [Debug, Release]
steps:
- uses: actions/checkout@v2
- uses: ./.github/actions/load-docker-image
name: Load docker image
with:
docker_image_name: debian
- name: Run build
chore(CI): Remove travis config and directory Move all CI scripts to generic .ci-scripts dir
2022-02-17 00:11:27 +08:00
run: docker-compose run --rm debian ./.ci-scripts/build-qtox-linux.sh --build-type ${{ matrix.build_type }} --${{ matrix.features }}
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-11-08 13:27:45 +08:00
build-debian-old:
name: Debian Old
runs-on: ubuntu-latest
needs: build-debian-old-docker
strategy:
matrix:
features: [full, minimal]
build_type: [Debug, Release]
steps:
- uses: actions/checkout@v2
- uses: ./.github/actions/load-docker-image
name: Load docker image
with:
docker_image_name: debian_old
- name: Run build
chore(CI): Remove travis config and directory Move all CI scripts to generic .ci-scripts dir
2022-02-17 00:11:27 +08:00
run: docker-compose run --rm debian_old ./.ci-scripts/build-qtox-linux.sh --build-type ${{ matrix.build_type }} --${{ matrix.features }}
feat(i18n): Check for new translatable strings on every PR We've only been updating translatable strings for Weblate rarely based on MAINTAINING.md#translations-from-weblate. Since Weblate pulls in commits live from qTox, we should generate the translatable strings as soon as they're introduced so that translators can not waste time translating deleted strings, and can spend time translating new strings. We can't auto-commit the changes in CI due to our requirement of signed commits, so just fail CI if any new strings are found. Move it into its own job, it doesn't depend on docker or the build, and doesn't need to run for debug/release/full/minimal
2022-02-19 04:44:20 +08:00
translation-check:
name: Check for translatable strings
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Install deps
run: sudo apt-get update && sudo apt-get install qttools5-dev
- name: Test for modified translatable strings
run: ./tools/update-translation-files.sh ALL && git diff --exit-code
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-11-08 13:27:45 +08:00
build-ubuntu:
name: Ubuntu LTS
runs-on: ubuntu-latest
needs: build-ubuntu-lts-docker
strategy:
matrix:
features: [full, minimal]
build_type: [Debug, Release]
steps:
- uses: actions/checkout@v2
- uses: ./.github/actions/load-docker-image
name: Load docker image
with:
docker_image_name: ubuntu_lts
- name: Run build
chore(CI): Remove travis config and directory Move all CI scripts to generic .ci-scripts dir
2022-02-17 00:11:27 +08:00
run: docker-compose run --rm ubuntu_lts ./.ci-scripts/build-qtox-linux.sh --build-type ${{ matrix.build_type }} --${{ matrix.features }}
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-11-08 13:27:45 +08:00
- name: Code coverage
chore(ci): Migrate PR CI from travis-ci.org and circleci to GitHub Actions 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.
2021-06-21 14:56:15 +08:00
run: |
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-11-08 13:27:45 +08:00
# https://github.com/actions/runner/issues/491
if [ "${{ matrix.build_type }}" == "Release" ] && [ "${{ matrix.features }}" == "full" ]; then
chore(CI): Remove travis config and directory Move all CI scripts to generic .ci-scripts dir
2022-02-17 00:11:27 +08:00
docker-compose run --rm ubuntu_lts ./.ci-scripts/lcov.sh
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-11-08 13:27:45 +08:00
# Upload report to codecov.io
bash <(curl -s https://codecov.io/bash) -f coverage.info || echo "Codecov did not collect coverage reports"
fi
build-appimage:
name: Appimage
runs-on: ubuntu-latest
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
needs: [build-ubuntu-lts-docker, update-nightly-tag]
if: |
always() &&
needs.build-ubuntu-lts-docker.result == 'success' &&
(needs.update-nightly-tag.result == 'success' ||
needs.update-nightly-tag.result == 'skipped')
fix(CI): Grant action content write permission for release upload By default our organization on GH only grants a more restricted read permission to actions for content APIs, which include both writing to repo for nightly tag creation, and writing to releases for nightly and tag release creation or updates.
2022-01-10 16:01:32 +08:00
permissions:
contents: write
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-11-08 13:27:45 +08:00
steps:
- uses: actions/checkout@v2
- uses: ./.github/actions/load-docker-image
name: Load docker image
with:
docker_image_name: ubuntu_lts
- name: Run build
fix(CI): Fix regression in logging from docker compose run Replace "docker compose run" with "docker-compose run". Seems like some kind of github actions regression: https://github.com/github/feedback/discussions/11011
2022-02-15 22:49:15 +08:00
run: docker-compose run --rm ubuntu_lts ./appimage/build.sh --src-dir /qtox
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-11-08 13:27:45 +08:00
- name: Upload appimage
uses: actions/upload-artifact@v2
with:
name: qTox-${{ github.sha }}.x86_64.AppImage
path: qTox-*.x86_64.AppImage
chore(release): Create release on tag push Release will be created as a draft, remaining private until manually published. All generated artifacts will be uploaded, but will still need to be signed, and the code archives still need to be created following MAINTAINING.md#after-tagging Fix #6345
2022-01-06 11:07:59 +08:00
- name: Get tag name for appimage release file name
if: contains(github.ref, 'refs/tags/v')
id: get_version
run: echo ::set-output name=VERSION::$(echo $GITHUB_REF | cut -d / -f 3)
chore(CI): Remove knowledge of build context from AppImage build script * Since nightlies are now published under qTox/qTox, different update info is not needed for the zsync file. * The github action yaml already handles naming files correctly otherwise.
2022-02-19 16:03:11 +08:00
# The zync file names MUST match the pattern "qTox-*.x86_64.AppImage.zsync"
# indefinitely for older versions to be able to update https://github.com/AppImage/AppImageSpec/blob/master/draft.md#github-releases
chore(release): Create release on tag push Release will be created as a draft, remaining private until manually published. All generated artifacts will be uploaded, but will still need to be signed, and the code archives still need to be created following MAINTAINING.md#after-tagging Fix #6345
2022-01-06 11:07:59 +08:00
- name: Rename appimage for release upload
if: contains(github.ref, 'refs/tags/v')
run: |
cp qTox-*.x86_64.AppImage qTox-${{ steps.get_version.outputs.VERSION }}.x86_64.AppImage
sha256sum qTox-${{ steps.get_version.outputs.VERSION }}.x86_64.AppImage > qTox-${{ steps.get_version.outputs.VERSION }}.x86_64.AppImage.sha256
cp qTox-*.x86_64.AppImage.zsync qTox-${{ steps.get_version.outputs.VERSION }}.x86_64.AppImage.zsync
- name: Upload to versioned release
if: contains(github.ref, 'refs/tags/v')
uses: ncipollo/release-action@v1
with:
allowUpdates: true
draft: true
token: ${{ secrets.GITHUB_TOKEN }}
artifacts: "qTox-${{ steps.get_version.outputs.VERSION }}.x86_64.AppImage,qTox-${{ steps.get_version.outputs.VERSION }}.x86_64.AppImage.sha256,qTox-${{ steps.get_version.outputs.VERSION }}.x86_64.AppImage.zsync"
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
- name: Rename artifact for nightly upload
chore(release): Create release on tag push Release will be created as a draft, remaining private until manually published. All generated artifacts will be uploaded, but will still need to be signed, and the code archives still need to be created following MAINTAINING.md#after-tagging Fix #6345
2022-01-06 11:07:59 +08:00
if: github.event_name == 'push' && github.ref == 'refs/heads/master'
chore(CI): Fix appimage missing rename for nightly zsync upload
2022-02-26 08:34:28 +08:00
run: |
cp qTox-*.x86_64.AppImage qTox-nightly.x86_64.AppImage
cp qTox-*.x86_64.AppImage.zsync qTox-nightly.x86_64.AppImage.zsync
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
- name: Upload to nightly release
uses: ncipollo/release-action@v1
if: github.event_name == 'push' && github.ref == 'refs/heads/master'
with:
allowUpdates: true
tag: nightly
chore(CI): Don't overwrite nightly release name and description Allows maintainers to write a user friendly message rather than just having the last commit desription.
2022-02-21 17:07:58 +08:00
omitBodyDuringUpdate: true
omitNameDuringUpdate: true
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
prerelease: true
replacesArtifacts: true
token: ${{ secrets.GITHUB_TOKEN }}
chore(CI): Revert nightly AppImage name to "nightly" Changed in 41a555def943fed19cc19867f985b71b94f5c8fd, I think by accident. Causes our release uploader to no longer replace the old version, instead adding a new version each time it runs. Keeping named overwrite instead of removing release artifacts and uploading new ones, since removing old artifacts would require a new job that all other jobs depend on to avoid re-removing, and would also create a gap while CI is running run where no artifact is available. We could upload artifacts using actions/upload-artifact in each job then download them at the end and update the release at that point too, if we really want to keep sha name in the nightly release artifacts. I don't see much value of having the sha in the filename though.
2022-02-21 16:49:09 +08:00
artifacts: "qTox-nightly.x86_64.AppImage,qTox-nightly.x86_64.AppImage.zsync"
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-11-08 13:27:45 +08:00
build-flatpak:
name: Flatpak
runs-on: ubuntu-latest
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
needs: [build-flatpak-docker, update-nightly-tag]
if: |
always() &&
needs.build-flatpak-docker.result == 'success' &&
(needs.update-nightly-tag.result == 'success' ||
needs.update-nightly-tag.result == 'skipped')
fix(CI): Grant action content write permission for release upload By default our organization on GH only grants a more restricted read permission to actions for content APIs, which include both writing to repo for nightly tag creation, and writing to releases for nightly and tag release creation or updates.
2022-01-10 16:01:32 +08:00
permissions:
contents: write
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-11-08 13:27:45 +08:00
steps:
- uses: actions/checkout@v2
- uses: ./.github/actions/load-docker-image
name: Load docker image
with:
docker_image_name: flatpak
- name: Run build
fix(CI): Fix regression in logging from docker compose run Replace "docker compose run" with "docker-compose run". Seems like some kind of github actions regression: https://github.com/github/feedback/discussions/11011
2022-02-15 22:49:15 +08:00
run: docker-compose run --rm flatpak ./flatpak/build.sh
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-11-08 13:27:45 +08:00
- name: Upload flatpak
uses: actions/upload-artifact@v2
with:
name: qTox-${{ github.sha }}.x86_64.flatpak
path: qtox.flatpak
chore(release): Create release on tag push Release will be created as a draft, remaining private until manually published. All generated artifacts will be uploaded, but will still need to be signed, and the code archives still need to be created following MAINTAINING.md#after-tagging Fix #6345
2022-01-06 11:07:59 +08:00
- name: Get tag name for flatpak release file name
if: contains(github.ref, 'refs/tags/v')
id: get_version
run: echo ::set-output name=VERSION::$(echo $GITHUB_REF | cut -d / -f 3)
- name: Rename flatpak for release upload
if: contains(github.ref, 'refs/tags/v')
run: |
cp qtox.flatpak qTox-${{ steps.get_version.outputs.VERSION }}.x86_64.flatpak
sha256sum qTox-${{ steps.get_version.outputs.VERSION }}.x86_64.flatpak > qTox-${{ steps.get_version.outputs.VERSION }}.x86_64.flatpak.sha256
- name: Upload to versioned release
if: contains(github.ref, 'refs/tags/v')
uses: ncipollo/release-action@v1
with:
allowUpdates: true
draft: true
token: ${{ secrets.GITHUB_TOKEN }}
artifacts: "qTox-${{ steps.get_version.outputs.VERSION }}.x86_64.flatpak,qTox-${{ steps.get_version.outputs.VERSION }}.x86_64.flatpak.sha256"
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
- name: Rename artifact for nightly upload
chore(release): Create release on tag push Release will be created as a draft, remaining private until manually published. All generated artifacts will be uploaded, but will still need to be signed, and the code archives still need to be created following MAINTAINING.md#after-tagging Fix #6345
2022-01-06 11:07:59 +08:00
if: github.event_name == 'push' && github.ref == 'refs/heads/master'
chore(CI): Add more artifacts to nightly release To match functionality of old qTox/qTox-nightly-releases/releases nightlies. Add flatpak sha, Windows zip shas, Windows installers, macOS sha.
2022-03-06 11:38:21 +08:00
run: |
cp qtox.flatpak qTox-nightly.flatpak
sha256sum qTox-nightly.flatpak > qTox-nightly.flatpak.sha256
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
- name: Upload to nightly release
uses: ncipollo/release-action@v1
if: github.event_name == 'push' && github.ref == 'refs/heads/master'
with:
allowUpdates: true
tag: nightly
chore(CI): Don't overwrite nightly release name and description Allows maintainers to write a user friendly message rather than just having the last commit desription.
2022-02-21 17:07:58 +08:00
omitBodyDuringUpdate: true
omitNameDuringUpdate: true
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
prerelease: true
replacesArtifacts: true
token: ${{ secrets.GITHUB_TOKEN }}
chore(CI): Add more artifacts to nightly release To match functionality of old qTox/qTox-nightly-releases/releases nightlies. Add flatpak sha, Windows zip shas, Windows installers, macOS sha.
2022-03-06 11:38:21 +08:00
artifacts: "qTox-nightly.flatpak,qTox-nightly.flatpak.sha256"
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-11-08 13:27:45 +08:00
build-windows:
name: Windows
runs-on: ubuntu-latest
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
needs: [build-windows-docker, update-nightly-tag]
if: |
always() &&
needs.build-windows-docker.result == 'success' &&
(needs.update-nightly-tag.result == 'success' ||
needs.update-nightly-tag.result == 'skipped')
fix(CI): Grant action content write permission for release upload By default our organization on GH only grants a more restricted read permission to actions for content APIs, which include both writing to repo for nightly tag creation, and writing to releases for nightly and tag release creation or updates.
2022-01-10 16:01:32 +08:00
permissions:
contents: write
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-11-08 13:27:45 +08:00
strategy:
matrix:
build_type: [debug, release]
steps:
- uses: actions/checkout@v2
- uses: ./.github/actions/load-docker-image
name: Load docker image
with:
docker_image_name: windows_builder
- name: Run build
chore(ci): Windows docker build fixes * Fix unit tests not running in windows build * Fix missing comment ports from old build script
2022-01-10 04:55:55 +08:00
run: docker-compose run --rm windows_builder ./windows/cross-compile/build.sh --arch x86_64 --build-type ${{ matrix.build_type }} --run-tests --src-dir /qtox
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-11-08 13:27:45 +08:00
- name: Upload installer
chore(CI): Don't try to upload installer on debug builds The installer is only built on release builds. We used to ignore failure to upload prior to 5fcf86b5212b1c36686eaacf9c844ceb0e15adb1. We stopped ignoring because a07ab89cc84bcab3a75277dd4efd1608535127bb tried to make our upload targetted, but it only resolved the issue for the zip, not the installer.
2022-03-03 02:52:02 +08:00
if: matrix.build_type == 'release'
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-11-08 13:27:45 +08:00
uses: actions/upload-artifact@v2
with:
name: setup-qtox-x86_64-${{ matrix.build_type }}.exe
path: package-prefix/setup-qtox.exe
- name: Upload zip
uses: actions/upload-artifact@v2
with:
fix(CI): Remove "setup" from Windows zip file name Matches previous behaviour, and the zips don't do any installation.
2022-02-18 03:35:47 +08:00
name: qtox-x86_64-${{ matrix.build_type }}.zip
chore(CI): Upload release Windows zips from GH actions workflow
2022-01-06 04:03:39 +08:00
path: install-prefix/qtox-x86_64-${{ matrix.build_type }}.zip
chore(release): Create release on tag push Release will be created as a draft, remaining private until manually published. All generated artifacts will be uploaded, but will still need to be signed, and the code archives still need to be created following MAINTAINING.md#after-tagging Fix #6345
2022-01-06 11:07:59 +08:00
- name: Rename exe for release upload
if: contains(github.ref, 'refs/tags/v') && matrix.build_type == 'release'
run: |
cp package-prefix/setup-qtox.exe setup-qtox-x86_64-release.exe
sha256sum setup-qtox-x86_64-release.exe > setup-qtox-x86_64-release.exe.sha256
- name: Upload to versioned release
if: contains(github.ref, 'refs/tags/v') && matrix.build_type == 'release'
uses: ncipollo/release-action@v1
with:
allowUpdates: true
draft: true
token: ${{ secrets.GITHUB_TOKEN }}
artifacts: "setup-qtox-x86_64-release.exe,setup-qtox-x86_64-release.exe.sha256"
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
- name: Rename zip for nightly upload
if: github.event_name == 'push' && github.ref == 'refs/heads/master'
chore(CI): Add more artifacts to nightly release To match functionality of old qTox/qTox-nightly-releases/releases nightlies. Add flatpak sha, Windows zip shas, Windows installers, macOS sha.
2022-03-06 11:38:21 +08:00
run: |
cp install-prefix/qtox-x86_64-${{ matrix.build_type }}.zip qtox-nightly-x86_64-${{ matrix.build_type }}.zip
sha256sum qtox-nightly-x86_64-${{ matrix.build_type }}.zip > qtox-nightly-x86_64-${{ matrix.build_type }}.zip.sha256
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
- name: Upload zip to nightly release
if: github.event_name == 'push' && github.ref == 'refs/heads/master'
uses: ncipollo/release-action@v1
with:
allowUpdates: true
tag: nightly
chore(CI): Don't overwrite nightly release name and description Allows maintainers to write a user friendly message rather than just having the last commit desription.
2022-02-21 17:07:58 +08:00
omitBodyDuringUpdate: true
omitNameDuringUpdate: true
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
prerelease: true
replacesArtifacts: true
token: ${{ secrets.GITHUB_TOKEN }}
chore(CI): Add more artifacts to nightly release To match functionality of old qTox/qTox-nightly-releases/releases nightlies. Add flatpak sha, Windows zip shas, Windows installers, macOS sha.
2022-03-06 11:38:21 +08:00
artifacts: "qtox-nightly-x86_64-${{ matrix.build_type }}.zip,qtox-nightly-x86_64-${{ matrix.build_type }}.zip.sha256"
- name: Rename exe for nightly upload
if: github.event_name == 'push' && github.ref == 'refs/heads/master' && matrix.build_type == 'release'
run: |
cp package-prefix/setup-qtox.exe qtox-nightly-x86_64-${{ matrix.build_type }}.exe
sha256sum qtox-nightly-x86_64-${{ matrix.build_type }}.exe > qtox-nightly-x86_64-${{ matrix.build_type }}.exe.sha256
- name: Upload exe to nightly release
if: github.event_name == 'push' && github.ref == 'refs/heads/master' && matrix.build_type == 'release'
uses: ncipollo/release-action@v1
with:
allowUpdates: true
tag: nightly
omitBodyDuringUpdate: true
omitNameDuringUpdate: true
prerelease: true
replacesArtifacts: true
token: ${{ secrets.GITHUB_TOKEN }}
artifacts: "qtox-nightly-x86_64-${{ matrix.build_type }}.exe,qtox-nightly-x86_64-${{ matrix.build_type }}.exe.sha256"
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-11-08 13:27:45 +08:00
build-windows-i686:
name: Windows i686
runs-on: ubuntu-latest
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
needs: [build-windows-i686-docker, update-nightly-tag]
if: |
always() &&
needs.build-windows-i686-docker.result == 'success' &&
(needs.update-nightly-tag.result == 'success' ||
needs.update-nightly-tag.result == 'skipped')
fix(CI): Grant action content write permission for release upload By default our organization on GH only grants a more restricted read permission to actions for content APIs, which include both writing to repo for nightly tag creation, and writing to releases for nightly and tag release creation or updates.
2022-01-10 16:01:32 +08:00
permissions:
contents: write
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-11-08 13:27:45 +08:00
strategy:
matrix:
build_type: [debug, release]
steps:
- uses: actions/checkout@v2
- uses: ./.github/actions/load-docker-image
name: Load docker image
with:
docker_image_name: windows_builder.i686
- name: Run build
chore(ci): Windows docker build fixes * Fix unit tests not running in windows build * Fix missing comment ports from old build script
2022-01-10 04:55:55 +08:00
run: docker-compose run --rm windows_builder.i686 ./windows/cross-compile/build.sh --arch i686 --build-type ${{ matrix.build_type }} --run-tests --src-dir /qtox
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-11-08 13:27:45 +08:00
- name: Upload installer
chore(CI): Don't try to upload installer on debug builds The installer is only built on release builds. We used to ignore failure to upload prior to 5fcf86b5212b1c36686eaacf9c844ceb0e15adb1. We stopped ignoring because a07ab89cc84bcab3a75277dd4efd1608535127bb tried to make our upload targetted, but it only resolved the issue for the zip, not the installer.
2022-03-03 02:52:02 +08:00
if: matrix.build_type == 'release'
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-11-08 13:27:45 +08:00
uses: actions/upload-artifact@v2
with:
name: setup-qtox-i686-${{ matrix.build_type }}.exe
path: package-prefix/setup-qtox.exe
- name: Upload zip
uses: actions/upload-artifact@v2
with:
fix(CI): Remove "setup" from Windows zip file name Matches previous behaviour, and the zips don't do any installation.
2022-02-18 03:35:47 +08:00
name: qtox-i686-${{ matrix.build_type }}.zip
chore(CI): Upload release Windows zips from GH actions workflow
2022-01-06 04:03:39 +08:00
path: install-prefix/qtox-i686-${{ matrix.build_type }}.zip
chore(release): Create release on tag push Release will be created as a draft, remaining private until manually published. All generated artifacts will be uploaded, but will still need to be signed, and the code archives still need to be created following MAINTAINING.md#after-tagging Fix #6345
2022-01-06 11:07:59 +08:00
- name: Rename exe for release upload
if: contains(github.ref, 'refs/tags/v') && matrix.build_type == 'release'
run: |
cp package-prefix/setup-qtox.exe setup-qtox-i686-release.exe
sha256sum setup-qtox-i686-release.exe > setup-qtox-i686-release.exe.sha256
- name: Upload to versioned release
if: contains(github.ref, 'refs/tags/v') && matrix.build_type == 'release'
uses: ncipollo/release-action@v1
with:
allowUpdates: true
draft: true
token: ${{ secrets.GITHUB_TOKEN }}
artifacts: "setup-qtox-i686-release.exe,setup-qtox-i686-release.exe.sha256"
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
- name: Rename zip for nightly upload
if: github.event_name == 'push' && github.ref == 'refs/heads/master'
chore(CI): Add more artifacts to nightly release To match functionality of old qTox/qTox-nightly-releases/releases nightlies. Add flatpak sha, Windows zip shas, Windows installers, macOS sha.
2022-03-06 11:38:21 +08:00
run: |
cp install-prefix/qtox-i686-${{ matrix.build_type }}.zip qtox-nightly-i686-${{ matrix.build_type }}.zip
sha256sum qtox-nightly-i686-${{ matrix.build_type }}.zip > qtox-nightly-i686-${{ matrix.build_type }}.zip.sha256
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
- name: Upload zip to nightly release
if: github.event_name == 'push' && github.ref == 'refs/heads/master'
uses: ncipollo/release-action@v1
with:
allowUpdates: true
tag: nightly
chore(CI): Don't overwrite nightly release name and description Allows maintainers to write a user friendly message rather than just having the last commit desription.
2022-02-21 17:07:58 +08:00
omitBodyDuringUpdate: true
omitNameDuringUpdate: true
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
prerelease: true
replacesArtifacts: true
token: ${{ secrets.GITHUB_TOKEN }}
chore(CI): Add more artifacts to nightly release To match functionality of old qTox/qTox-nightly-releases/releases nightlies. Add flatpak sha, Windows zip shas, Windows installers, macOS sha.
2022-03-06 11:38:21 +08:00
artifacts: "qtox-nightly-i686-${{ matrix.build_type }}.zip,qtox-nightly-i686-${{ matrix.build_type }}.zip.sha256"
- name: Rename exe for nightly upload
if: github.event_name == 'push' && github.ref == 'refs/heads/master' && matrix.build_type == 'release'
run: |
cp package-prefix/setup-qtox.exe qtox-nightly-i686-${{ matrix.build_type }}.exe
sha256sum qtox-nightly-i686-${{ matrix.build_type }}.exe > qtox-nightly-i686-${{ matrix.build_type }}.exe.sha256
- name: Upload exe to nightly release
if: github.event_name == 'push' && github.ref == 'refs/heads/master' && matrix.build_type == 'release'
uses: ncipollo/release-action@v1
with:
allowUpdates: true
tag: nightly
omitBodyDuringUpdate: true
omitNameDuringUpdate: true
prerelease: true
replacesArtifacts: true
token: ${{ secrets.GITHUB_TOKEN }}
artifacts: "qtox-nightly-i686-${{ matrix.build_type }}.exe,qtox-nightly-i686-${{ matrix.build_type }}.exe.sha256"
chore(ci): Migrate PR CI from travis-ci.org and circleci to GitHub Actions 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.
2021-06-21 14:56:15 +08:00
build-osx:
name: macOS
runs-on: macos-10.15
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
needs: update-nightly-tag
if: |
always() &&
(needs.update-nightly-tag.result == 'success' ||
needs.update-nightly-tag.result == 'skipped')
fix(CI): Grant action content write permission for release upload By default our organization on GH only grants a more restricted read permission to actions for content APIs, which include both writing to repo for nightly tag creation, and writing to releases for nightly and tag release creation or updates.
2022-01-10 16:01:32 +08:00
permissions:
contents: write
chore(ci): Migrate PR CI from travis-ci.org and circleci to GitHub Actions 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.
2021-06-21 14:56:15 +08:00
steps:
- uses: actions/checkout@v2
- name: homebrew
run: brew upgrade && brew bundle --file ./osx/Brewfile
chore(build): Remove qTox-Mac-Deployer-ULTIMATE.sh * It is only partially covered by CI and doesn't simplify the build process much for users. Replacing it in CI with just build-osx.sh significantly reduces script complexity and is fully tested. * bootstrap-osx.sh copying system libs and headers locally is unneeded. Already the DMG file contains them, and re-linking the app against updated system files may be desirable. * Update INSTALL.md for macOS to use brewfile, use common dependency build scripts, and use cmake rather than wrapper scripts. * Build macOS in Release mode in CI, for release artifact creation * Don't copy all used libs into a local folder, macdeployerqt already handles this for the dmg, and for local running of the app using the system libs and relinking on update is desirable to avoid running out of date dependencies unexpectedly.
2022-01-05 03:11:09 +08:00
- name: Install toxcore and toxext
run: buildscripts/build_toxcore_linux.sh
- name: Build qTox
chore(CI): Remove travis config and directory Move all CI scripts to generic .ci-scripts dir
2022-02-17 00:11:27 +08:00
run: ./.ci-scripts/build-osx.sh
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-11-08 13:27:45 +08:00
- name: Upload dmg
uses: actions/upload-artifact@v2
with:
name: qTox-${{ github.sha }}.dmg
chore(build): Remove qTox-Mac-Deployer-ULTIMATE.sh * It is only partially covered by CI and doesn't simplify the build process much for users. Replacing it in CI with just build-osx.sh significantly reduces script complexity and is fully tested. * bootstrap-osx.sh copying system libs and headers locally is unneeded. Already the DMG file contains them, and re-linking the app against updated system files may be desirable. * Update INSTALL.md for macOS to use brewfile, use common dependency build scripts, and use cmake rather than wrapper scripts. * Build macOS in Release mode in CI, for release artifact creation * Don't copy all used libs into a local folder, macdeployerqt already handles this for the dmg, and for local running of the app using the system libs and relinking on update is desirable to avoid running out of date dependencies unexpectedly.
2022-01-05 03:11:09 +08:00
path: qTox.dmg
chore(release): Create release on tag push Release will be created as a draft, remaining private until manually published. All generated artifacts will be uploaded, but will still need to be signed, and the code archives still need to be created following MAINTAINING.md#after-tagging Fix #6345
2022-01-06 11:07:59 +08:00
- name: Create shasum for versioned release
if: contains(github.ref, 'refs/tags/v')
run: sha256sum qTox.dmg > qTox.dmg.sha256
- name: Upload to versioned release
if: contains(github.ref, 'refs/tags/v')
uses: ncipollo/release-action@v1
with:
allowUpdates: true
draft: true
token: ${{ secrets.GITHUB_TOKEN }}
artifacts: "qTox.dmg,qTox.dmg.sha256"
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
- name: Rename artifact for nightly upload
chore(release): Create release on tag push Release will be created as a draft, remaining private until manually published. All generated artifacts will be uploaded, but will still need to be signed, and the code archives still need to be created following MAINTAINING.md#after-tagging Fix #6345
2022-01-06 11:07:59 +08:00
if: github.event_name == 'push' && github.ref == 'refs/heads/master'
chore(CI): Add more artifacts to nightly release To match functionality of old qTox/qTox-nightly-releases/releases nightlies. Add flatpak sha, Windows zip shas, Windows installers, macOS sha.
2022-03-06 11:38:21 +08:00
run: |
cp qTox.dmg qTox-nightly.dmg
sha256sum qTox-nightly.dmg > qTox-nightly.dmg.sha256
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
- name: Upload to nightly release
uses: ncipollo/release-action@v1
if: github.event_name == 'push' && github.ref == 'refs/heads/master'
with:
allowUpdates: true
tag: nightly
chore(CI): Don't overwrite nightly release name and description Allows maintainers to write a user friendly message rather than just having the last commit desription.
2022-02-21 17:07:58 +08:00
omitBodyDuringUpdate: true
omitNameDuringUpdate: true
chore(release): Create nightly release on master branch pushes * Tag is required to create a release, so tag "nightly" is moved to latest commit on each run. * Each time the tag is moved, the existing "nightly" release is updated automatically by github to point to the new tag and bundle the new commit's source code. * Artifacts are uploaded with intentionally conflicting names to replace last commit's version of artifacts, rather than deleting the whole release and making a new one. * This has two benefits, it doesn't notify of a new release on each commit, and it doesn't leave a gap where there's no nightly release available.
2022-01-06 04:00:16 +08:00
prerelease: true
replacesArtifacts: true
token: ${{ secrets.GITHUB_TOKEN }}
chore(CI): Add more artifacts to nightly release To match functionality of old qTox/qTox-nightly-releases/releases nightlies. Add flatpak sha, Windows zip shas, Windows installers, macOS sha.
2022-03-06 11:38:21 +08:00
artifacts: "qTox-nightly.dmg,qTox-nightly.dmg.sha256"
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-11-08 13:27:45 +08:00
build-docs:
name: Docs
chore(CI): Move gitstats and docs to ubuntu-latest They're not platform dependent and the rest of our jobs run on ubuntu-latest. Might as well move this one over so we don't have to remember to update it. gitstats is not available in repo any longer, so install manually.
2022-02-22 00:03:11 +08:00
runs-on: ubuntu-latest
chore(ci): Migrate PR CI from travis-ci.org and circleci to GitHub Actions 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.
2021-06-21 14:56:15 +08:00
env:
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-11-08 13:27:45 +08:00
DOXYGEN_CONFIG_FILE: doxygen.conf
chore(ci): Migrate PR CI from travis-ci.org and circleci to GitHub Actions 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.
2021-06-21 14:56:15 +08:00
steps:
- uses: actions/checkout@v2
chore(CI): Revert 8a72928ad1451a8a76151a1a070fb35c022aa53b "chore(travis): don't fail generating docs when there's no git version" No longer a concern on GH actions which allows deep clones.
2022-02-17 00:13:32 +08:00
with:
fetch-depth: 0
chore(ci): Migrate PR CI from travis-ci.org and circleci to GitHub Actions 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.
2021-06-21 14:56:15 +08:00
- name: Run
chore(CI): Remove travis config and directory Move all CI scripts to generic .ci-scripts dir
2022-02-17 00:11:27 +08:00
run: ./.ci-scripts/build-docs.sh
fix(doxygen): Re-enable deploying of doxygen to qtox.github.io Hasn't been run since the travis days. Now managed through a deploy key rather than an access token to limit scope to a single repo. Private key is stored in qTox/qTox as a repository secret, and the public portion is saved to qTox/doxygen as a deploy key.
2022-02-22 00:42:40 +08:00
- name: Deploy
chore(CI): Don't try to deploy from forks Gitstats and doxygen deploys require deploy keys to update qTox's website. Don't try to do this from forks, since it will always fail.
2022-03-03 19:58:01 +08:00
if: github.ref == 'refs/heads/master' && github.owner == 'qTox'
fix(doxygen): Re-enable deploying of doxygen to qtox.github.io Hasn't been run since the travis days. Now managed through a deploy key rather than an access token to limit scope to a single repo. Private key is stored in qTox/qTox as a repository secret, and the public portion is saved to qTox/doxygen as a deploy key.
2022-02-22 00:42:40 +08:00
env:
chore(CI): Correct doxygen deploy access
2022-02-24 21:50:07 +08:00
access_key: ${{ secrets.DOXYGEN_DEPLOY_KEY }}
fix(doxygen): Re-enable deploying of doxygen to qtox.github.io Hasn't been run since the travis days. Now managed through a deploy key rather than an access token to limit scope to a single repo. Private key is stored in qTox/qTox as a repository secret, and the public portion is saved to qTox/doxygen as a deploy key.
2022-02-22 00:42:40 +08:00
run: ./.ci-scripts/deploy-docs.sh
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-11-08 13:27:45 +08:00
build-gitstats:
name: Gitstats
chore(CI): Move gitstats and docs to ubuntu-latest They're not platform dependent and the rest of our jobs run on ubuntu-latest. Might as well move this one over so we don't have to remember to update it. gitstats is not available in repo any longer, so install manually.
2022-02-22 00:03:11 +08:00
runs-on: ubuntu-latest
chore(CI): Split Win deps into their own job Previously, the four matrix Windows jobs would run in parallel and each build deps, which is redundant since both debug and release qTox use the same deps. Now, the win-deps job builds only the needed two versions of deps, and the four windows builds wait for it to complete before running in parallel.
2021-09-23 18:10:11 +08:00
env:
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-11-08 13:27:45 +08:00
GITSTATS_DIR: gitstats
chore(CI): Split Win deps into their own job Previously, the four matrix Windows jobs would run in parallel and each build deps, which is redundant since both debug and release qTox use the same deps. Now, the win-deps job builds only the needed two versions of deps, and the four windows builds wait for it to complete before running in parallel.
2021-09-23 18:10:11 +08:00
steps:
- uses: actions/checkout@v2
chore(CI): Deep clone for gitstatus initially instead of recloning
2022-02-19 15:57:45 +08:00
with:
fetch-depth: 0
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-11-08 13:27:45 +08:00
- name: Install gitstats
chore(CI): Move gitstats and docs to ubuntu-latest They're not platform dependent and the rest of our jobs run on ubuntu-latest. Might as well move this one over so we don't have to remember to update it. gitstats is not available in repo any longer, so install manually.
2022-02-22 00:03:11 +08:00
run: |
sudo apt-get install gnuplot
git clone git://github.com/hoxu/gitstats.git
cd gitstats
sudo make install
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-11-08 13:27:45 +08:00
- name: Run
chore(CI): Remove travis config and directory Move all CI scripts to generic .ci-scripts dir
2022-02-17 00:11:27 +08:00
run: ./.ci-scripts/build-gitstats.sh
fix(gitstats): Re-enable deploying of gitstats to qtox.github.io Hasn't been run since the travis days. Now managed through a deploy key rather than an access token to limit scope to a single repo. Private key is stored in qTox/qTox as a repository secret, and the public portion is saved to qTox/gitstats as a deploy key.
2022-02-17 00:55:08 +08:00
- name: Deploy
chore(CI): Don't try to deploy from forks Gitstats and doxygen deploys require deploy keys to update qTox's website. Don't try to do this from forks, since it will always fail.
2022-03-03 19:58:01 +08:00
if: github.ref == 'refs/heads/master' && github.owner == 'qTox'
fix(gitstats): Re-enable deploying of gitstats to qtox.github.io Hasn't been run since the travis days. Now managed through a deploy key rather than an access token to limit scope to a single repo. Private key is stored in qTox/qTox as a repository secret, and the public portion is saved to qTox/gitstats as a deploy key.
2022-02-17 00:55:08 +08:00
env:
access_key: ${{ secrets.GITSTATS_DEPLOY_KEY }}
chore(CI): Remove travis config and directory Move all CI scripts to generic .ci-scripts dir
2022-02-17 00:11:27 +08:00
run: ./.ci-scripts/deploy-gitstats.sh
Reference in New Issue Copy Permalink