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.
Although these didn't used to fail at all, they now _always_ fail due to
the Docker setup we run on GitLab. Until we get that fixed, the CI is
not very helpful if it fails every time, and we merge anyway. This
allows us to at least correctly use the "Merge when succeeds" behaviour.
gitlab-ci used to run all of our jobs in parallel, now it mostly seems
to run them sequentially. So splitting up the various parts of the CI
suite into separate jobs mostly slows things down. This combines the
static tests into one job (lint, pmd, checkstyle, tools) with the JVM
tests aka Robolectric. That makes three jobs from the previous six.
