The android-10 emulator does not report test failures so it is pretty
useless at the moment. After lots and lots of trying, the most recent
emulator that I could get running on gitlab-ci was 17, so let's hope that
turns out to be more useful. I also had to reduce the RAM that was used,
it seems that gitlab-ci does not let the docker images use much RAM.
This might be able to be improved by creating an pre-setup AVD image in the
docker image used by this.
I find that the logs dumped into the gitlab-ci screens are generally
unreadable, so here, only the errors are dumped into the build log, then
the rest are uploaded to clbin, a paste bin, where the whole text can be
viewed and downloaded in a clean, raw format.
This makes it a lot easier to setup all the testing stuff. Mostly,
I'm tired of fighting Android Studio's fragility, so I want to remove
as much non-standardness as possible in the hopes of improving that
situation.
closes#534https://gitlab.com/fdroid/fdroidclient/issues/534
* splitting out the tools script allows less things to happen on the
main job, and runs the tools script in parallel, which should speed
things up.
* `gradle check` also runs lint, and anything else we might add to
that meta-target.
* `gradle build` also runs tests, `gradle assemble` does not
This stores the Android SDK tarball and gradle caches between builds
to speed things up. Since the unpacked SDK gets unpacked very time,
updating the version is just a matter of changing the variable. Since
only the gradle caches are stored, i.e. the jars and gradle binaries,
updates there will only add more files to the cache.
It doesn't include all of the Android style checks as found in Android Studio,
but it's a start.
Bump Gradle to 2.7 because the checkstyle plugin in earlier versions is just
not good enough.
Its boot animation is "stopped" but on my laptop the CPU is still at 100%,
which means it's probably still working and not ready yet. The tests fail if
you run them right after wait-for-emulator is done. If you wait a few seconds
though, they do work since the CPU load drops.
Until we can figure out a better solution, have a generous 30-second sleep
after it tells us it's ready.
This will make sure that all projects in the repository are built and tested.
Should come in handy for !126, which splits up the app into two apps and one
library.
Spotted by Hans at fdroidserver. The 'update sdk' tool will download the
package index at each run, so installing one package at a time will be rather
inefficient.
