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.
This gathers all files that are not tracked by git into a named ZIP file,
which is available for 1 week to download from the Pipelines page for the
fork that ran the build.
If a repo is set with the gitlab-ci Secret Variable DEBUG_KEYSTORE and
there is a repo named the same as this repo with -nightly appended,
then this will automatically generate an fdroid repo of each build
produced by gitlab-ci runs on the master branch.
closes fdroidserver#256
The connected10 test runner has been at least as reliable as connected24,
and provides valuable coverage, especially for localization related
crashers.
clbin is just for making the logs easy to read, if it fails, the build
should not be marked as failed, especially since the logs are probably
not needed if the rest of the job succeeded.
Since we have all these lovely scripts for cleaning up the
translations, gitlab-ci is a handy way to enforce that they get used.
Since weblate merges happen via merge requests, this will work nicely
now. I can't think of any false positives that will arise, but we
shall find out!
connected24 tests are frequently failing saying that while an emulator
is running, its not compatible. This is bizarre. This just adds debug
output to help troubleshoot that.
