GitLab doesn't currently support any kind of build or env matrix, so we
have to duplicate this code. This is due to change in upcoming releases,
at which point I'll fix this.
Be more explicit about what we're running. This also means that we wont
run the "read log here" stuff if the build failed, which didn't make any
sense. That should only be run if the unit tests fail.
Advantages:
* Failing unit tests don't keep the android tests from running
* CI should be overall faster as the tasks get run in parallel and the
former `gradle` task was the longest by far
This will later simplify the multiplexing of the android tests onto
multiple emulators.
This is the common pattern I've seen in travis-ci builds. It should
speed things up a little bit since the adb connection process will
happen in parallel with waiting for the screen lock to be dismissed.
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.
