Run tests that call native TESTING_ functions on Android. This requires
building a separate version of libsignal_jni.so with the testing functions
included. The test code is still omitted from the published artifacts.
Clean the contents of the default target directory before switching.
This should hopefully help us to avoid running out of disk space during
the following steps (running cross-version tests).
Use the GitHub CLI utility, if present, to fetch the size from the logs of the
"Build and Test" workflow run for the merge-base of the current branch and
upstream main. This represents the true "delta" attributable to the current
branch, as opposed to the integral of changes since the last release.
- use int instead of promoting to long
- add missing return type to fix compilation
- run auto-formatter
Also add the check that would have caught all of these to CI
...in addition to our usual nightly.
Move the run commands for latest-stable to the Slow Tests (reusing the
cross-protocol-version testing job rather than making a new one).
Adjust the attributes so that git will treat the generated acknowledgment files
as binary for the purposes of merging. This will ensure that a merge of two
branches that both alter the acknowledgments will require manual resolution
(ideally by re-running the generation script).
The new version introduced a couple changes that are reflected here:
- Rename override_git_commit -> override-git-commit in about.toml since
that's now the canonical spelling.
- Regenerate the license list since a bug was fixed that changed the
semantics of the count.
Also pin the version in our documentation and in the script to prevent
differences in behavior depending on when cargo-about was installed on
developer machines.
The Rust jobs are currently the long pole in the CI tests, but the
32-bit tests have to recompile everything except the proc-macros, so
they add the most time on top of the other steps. By separating them
to their own jobs (one for stable, one for nightly), we pay a little
extra in CI-minutes to save in turnaround time.
The Android emulator works a lot better with hardware acceleration,
but as of 2023-02-23 that can be done with larger Linux runners as
well as macOS instances. Switch over for better reliability (and lower
cost).
The JNI tests have also been conditionalized in case we want to take
this out for Android as well. (Node still unconditionally depends on
it being present.) I've given it a separate feature flag from just
ffi/jni/node so that we can preserve the tests Jessa wrote for each
platform.
...which handles enum variants slightly differently under the
configuration options we have ('remove_underscores', relevant for
generic types rather than enum variants). The new style is closer to
Apple-idiomatic anyway.
Rather than building the Rust parts of libsignal as part of `pod
install`, fetch them from build-artifacts.signal.org. This requires
adding
ENV['LIBSIGNAL_FFI_PREBUILD_CHECKSUM'] = '...'
to the consuming Podfile. The referenced archives are downloaded to
~/Library/Caches/org.signal.libsignal, and are unarchived as part of
the build. (The archives are outside the build directory so that a
clean build does not require a new download.)
Building with LibSignalClient as a local pod is still supported; in
that case everything will refer to the local target/ directory
instead. Use swift/build_ffi.sh to build as usual.
These are intertwined: older versions of Rust don't support the newer
NDK, but the newer Rust can't successfully compile BoringSSL against
the older NDK.
This requires a boring-sys update to find the Android NDK sysroot in
the right place.
And
- Use modern output-setting syntax
- Replace actions-rs/toolchain and JS-DevTools/npm-publish
- Use setup-node's node-version-file argument instead of reading
from .nvmrc manually.
- Pin dorny/paths-filter
- Replace svenstaro/upload-release-action with ncipollo/release-action
The only supported way to target an older glibc is to build against
that glibc; consequently, we need to build on an Ubuntu 16 system (or
similar) to target Ubuntu 16. This requires downloading second-party
versions of Clang and CMake, which are too old in the default Ubuntu
repository, as well as building our own Python.
Do all this in a new Dockerfile based on Ubuntu 16.04. This isn't as
rigorous as the Java "reproducible build" Dockerfile, since we're not
pinning the base image or the repositories we're fetching from, but
it's still an image with the environment and tools we need.
