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.
* Fix compile error on macOS by marking GroupWidget::widgetIsVisible as
override
* Mark mock functions override for consistency
* Change QWARN to QVERIFY since logs will be missed in CI
* Uncomment add of offline and online friends in testSortByActivity
* Add out-of-line method definition to anchor vtable
Old windows/cross-compile/build.sh copied OPENAL_PREFIX_DIR/bin/*.dll to be
included, but the current Dockerfile.windows_builder copies libs one by one
and misses OpenAL. qTox fails to start on launch with due to missing
OpenAL32.dll on Windows because of this.
Add a special check for OpenAL, since the generic missing dll check doesn't
cover it.
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.
When ToxFile is constructed with a file size of 0, it cancels the transfer as
soon as the first chunk is received due to the received size being
larger than expected.
It hasn't had a text update since being introduced over 3 years ago despite our
English INSTALL.md having significant changes in that time.
Users requiring translation would be better off auto-translating our English
INSTALL.md.
std::atomic disallows copy construction and the default constructor disables
the parameterized constructor.
Additionally the case where paths aren't writable isn't handled and would just
segfault in Settings previously, so no safety is lost.
Paths must be aware of the "makeToxPortable" state to so that on shutdown,
saving saves to the new location.
This reverts to old behaviour which was broken in
5d56a3c039Fix#6443
Newer version of avformat_open_input, av_find_input_format,
avcodec_find_decoder previously used non-const pointers that are now
const. Support both version for compatibiltiy with other platforms.
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
* 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.
* It is untested by CI and adds a lot of complexity compared to manually
compiling toxcore and toxext in a couple commands. This also exposes
the cmake configs rather than wrapping them in an out of date list of
script configs for users.
* 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.
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.
Mick Sayson (3):
fix(filetransfer): Fix UI inconsistencies with pause/resume
refactor(filetransfer): Move file transfer progress into ToxFile
feat(filesform): Add in progress transfers to files form
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
