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.
Unfortunately, something in the way that the docker image is created is
making it impossible to run `android update sdk`. Even though it runs as
root, it cannot upgrade things, and in the process, it seems to break the
Android SDK bits that are there.
Installing Android Support Repository, revision 40
Failed to rename directory /android-sdk/extras/android/m2repository to /android-sdk/temp/ExtraPackage.old01.
Failed to create directory /android-sdk/extras/android/m2repository
Done. Nothing was installed.
A problem occurred configuring project ':app'.
> Failed to notify project evaluation listener.
> You have not accepted the license agreements of the following SDK components:
[Android Support Repository].
Before building your project, you need to accept the license agreements and complete the installation of the missing components using the Android Studio SDK Manager.
Alternatively, to learn how to transfer the license agreements from one workstation to another, go to http://d.android.com/r/studio-ui/export-licenses.html
> Could not resolve all dependencies for configuration ':app:compile'.
> Could not find com.android.support:support-v4:24.2.1.
Required by:
project :app
> Could not find com.android.support:appcompat-v7:24.2.1.
Required by:
project :app
> Could not find com.android.support:support-annotations:24.2.1.
Required by:
project :app
This makes sure that the latest version of the core SDK components are
all current before running, which means that the builds will keep
working even when the docker image gets out of date. Then we can
finish the task we are working on before having to deal with updating
the docker image. Without that update line, we have to drop everything
and update the docker image when things are out of date.
Disk space and bandwidth is cheap, developer time is very scarce. We
should aim to keep the tests working as much as possible so that we
waste less developer time. Updating everytime only means it downloads
a little bit of XML each time, that's nothing compared to what gradle
downloads on every build.
