https://gitlab.com/fdroid/ci-images-client/-/jobs/957371759
```
A fatal error has been detected by the Java Runtime Environment:
SIGSEGV (0xb) at pc=0x00007f6775b513c0, pid=1923, tid=0x00007f675eef6700
JRE version: OpenJDK Runtime Environment (8.0_275-b01) (build 1.8.0_275-8u275-b01-1~deb9u1-b01)
Java VM: OpenJDK 64-Bit Server VM (25.275-b01 mixed mode linux-amd64 compressed oops)
Problematic frame:
V [libjvm.so+0x92d3c0]
Core dump written. Default location: /builds/test/fdroidclient/app/core or core.1923
An error report file with more information is saved as:
/builds/test/fdroidclient/app/hs_err_pid1923.log
Compiler replay data is saved as:
/builds/test/fdroidclient/app/replay_pid1923.log
If you would like to submit a bug report, please visit:
http://bugreport.java.com/bugreport/crash.jsp
```
This fully replaces gradle-witness and goes far beyond what it offered. As
far as I can tell, this actually will verify every single artifact that
gradle downloads and uses.
This was generated in two passes to get both the PGP and the SHA256 info:
```
./gradlew --write-verification-metadata pgp,sha256 build connectedFullDebugAndroidTest --export-keys
./gradlew --write-verification-metadata sha256 build connectedFullDebugAndroidTest
```
Thanks to @vlsi who made me aware of this, and helped make it possible.
closes!837
This reverts commit c5daf1981a7f00de16e19120ac42575c0e4bc424.
Turns I was confused here. Yes, the job has to be called "pages" if the
job is deploying to GitLab Pages. But in the case of `fdroid nightly`, the
thing that is deploying to GitLab Pages is the .gitlab-ci.yml that is in
the *-nightly repo, which is auto-generated by `fdroid nightly`.
fdroid/fdroidserver#649
There are soo many of these:
org.fdroid.fdroid.net.HttpDownloaderTest > downloadThenCancel[avd27(AVD) - 8.1.0] FAILED
Test failed to run to completion. Reason: 'Instrumentation run failed due to 'Process crashed.''. Check device logcat for details
The merge_requests feature is really confusing, and doesn't seem to do
anything useful for what we need it to. Like it doesn't let new
contributors' merge requests run on the fdroid runners.
It seems that ARM emulators timeout even when just trying to run the
assumeTrue() tests via Espresso. There needs to be one test still enabled
in the file, otherwise, the run fails with:
org.fdroid.fdroid.MainActivityEspressoTest > initializationError[Nexus_One_API_19(AVD) - 4.4.2] FAILED
java.lang.Exception: No runnable methods
at org.junit.runners.BlockJUnit4ClassRunner.validateInstanceMethods(BlockJUnit4ClassRunner.java:191)
The emulator runs are super crashy on gitlab-ci, so just run the emulator
tests for the "full" build flavor. Once these prove stable, the task
should be switched to connectedCheck to test all the build flavors
Before, it was running:
* testBasicDebugUnitTest
* testBasicReleaseUnitTest
* testFullDebugUnitTest
Since there are no Robolectric tests for only "basic", and there are no
tests specific to "release" or "debug", those three runs will be running
the same tests, except for the handful of "full" tests. So running
testFullDebugUnitTest covers all cases.
This also only runs one emulator test by default, then runs 3 SDK
levels for final commits. The single default test is the optimized
F-Droid system image included in the Docker image.
