They're still slightly flaky even with insanely long timeouts, and even when not they waste a huge amount of our runner time sitting and waiting for the DHT to disconnect and reconnect.
Still run on our fedora job to get almost all of the benefit, plus AddressSanitizer is enabled there for better testing synergy.
The installer is only built on release builds. We used to ignore failure to
upload prior to 5fcf86b521. We stopped ignoring
because a07ab89cc8 tried to make our upload
targetted, but it only resolved the issue for the zip, not the installer.
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.
Changed in 41a555def9, 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.
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.
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.
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
* 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.
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.
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.
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.
