The setup and build_all jobs take a very long time to run, so its really
annoying when they are marked as failed just because one small thing in the
test suite failed. So move the test suite to its own job that can be run
more frequently.
Debug logging is not saved in buildserver logs. Also move this line into
build.py's main() to avoid duplication: common.setup_vcs(app) may be
called from parse_metadata() too.
Since this code was not setting the "create system" and "compress type",
Python uses it's defaults. Those will be different than what the Android
tools produces if this is run on UNIX. The Android tools uses the bare
bones "Windows" ZIP format, e.g. no permissions, etc.
For example:
https://verification.f-droid.org/eu.siacs.conversations_234.apk.diffoscope.html
This came about testing on OSX, where there are often multiple versions of
the JDK installed. This was choosing the oldest version. It should
choose the most recent version.
The OSX tests seem to run slower, they often timeout. So only run
the test suite with the installed version of fdroid, instead of the
three rounds that ./complete-ci-tests does.
This reverts commit 5f5d3ea896.
These new scanner rules for JARs causes most builds on fdroiddata to
break. For example, at least the past 20 releases of
org.fdroid.fdroid. fdroiddata needs to be cleaned up and prepared for
this before we can include 5f5d3ea896
I'm running fdroid scanner on the whole archive now, I'll post the log
to an issue once its done. Ignoring test files would eliminate some
of these build failures, at least for most org.fdroid.fdroid builds.
refs #!325
This fixes a problem when there is a broken symlink with the name
AndroidManifest.xml which will then lead to a crash when trying to open
it for trying to remove the debuggable flag.
Wow, this is hacky and weird, but its been there for a long time. I
don't know if its even relevant anymore, but is isolated so it
shouldn't hurt anything. Plus there is a test for it in
tests/complete-ci-tests, so it seems worth fixing.
* `make -C locale` updates all the sources
* `make -C locale compile` can compile the binaries, but the preferred way
is `python3 setup.py compile_catalog`.
The way to officially include a new language in the source tarball is to
add it to the MANIFEST.in. Otherwise, it will not be included in the
source tarball, and therefore won't be installed when using apt, pip, etc.
