Weblate settings are changed to rebase commits onto our master continuously. All
that's needed to pull in translations now is to pull, rather than locking, using
a custom script, and resetting the Weblate repo.
Committing translatable strings is now done on every commit and checked on PR,
so that is no longer part of the import process.
Commits on Weblate are squashed using the "squash git commits" addon. It is
configurable to squash all commits into one and add co-author commit messages,
like we do now. Instead I've set it to just squash commits from a single author
for clearer attribution.
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
Was used to update all the duplicate versions of toxcore spread around the
repo. Now all builds and user instructions for the version come from
buildscripts/download/download_toxcore.sh directly, so this script serves no
purpose.
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
Relying on git doesn't work in awful lot of cases, e.g. when there's a
shallow `git clone`.
Instead have "hardcoded" version in files, and update it before release.
Closes#4165.
`lzip` is used for its great compression (better even than `xz`) and
properties that make it a viable format for long-term archiving (feature
that `xz` is missing).
http://www.nongnu.org/lzip/xz_inadequate.html
Also add some docs regarding release process.
Re: #3912, #4045
Anthony Bilinski
Mick Sayson
sudden6
Zetok Zalbavar