The builder should check the `AllowedAPKSigningKeys` at build time, so
that the CI can check if somebody gives a wrong value that doesn't match
a compared RB binary. In the event it fails, it gives useful
information, and in the event it succeeds, it makes it clear that this
build has verification back to the developer's original key.
Also, add tests for this to the test suite.
I tried to get this to indent the .yaml files properly so yamllint defaults
work with tests/metadata/dump/*.yaml, but it didn't take for some reason:
yaml.indent(mapping=4, sequence=4, offset=2)
Before this, there were separate post-parse paths for app-fields versus
build-flags. This makes all TYPE_STRING values always go through the same
post-parse code path.
My guess is that this is some kind of vestige of the old code structure,
back when there was .txt and .yml formats. This makes it a normal Python
function: input as arg, return value is the result.
This lets mirrors: in config.yml be the same list-of-dicts format as it is
in index-v2. This also includes a data format conversion to maintain the
right format for the old, unchanging index v0 and v1 formats.
#928#1107
It turns out that the maven: field was originally declared as a TYPE_STRING,
given that it was not given a different type in metadata.py's flagtypes.
The code was confused because it was given a default value of `False` rather
than `None` as the rest of the TYPE_STRING fields have.
This construct in build.py means maven: should always be a string:
if '@' in build.maven:
maven_dir = os.path.join(root_dir, build.maven.split('@', 1)[1])
else:
maven_dir = root_dir
The paths in the config must be strings because they are used in things
like env vars where they must be strings. Plus lots of other places in the
code assumes they are strings. This is the first step to defining the
border of where paths can be pathlib.Path() and where they must be strings.
This job just started failing, but wasn't before:
https://gitlab.com/eighthave/fdroidserver/-/jobs/4060582594
But I look at it, and it looks right that it fails. So how on earth
was it succeeding before? Basically the `os.getenv('ANDROID_HOME')`
returns `None` when `ANDROID_HOME` is not set. It is not set in both the
jobs, so how did it not stacktrace before?
make_v0() modified the apps data structure to copy an anti feature for a
specific version to all versions resulting in index-v1 and -v2 to
contain wrong anti feature annotations. This patch fixes this and adds a
test that the data structure is no longer modified.
The bug shadowed bugs in the AF implementation of -v1 and -v2 resulting
in not coping the version specific data. This is corrected as well.
This is also tested now.
For -v2 the AF dict is now sorted to make the result reproducible.
Finally The NoSourceSince AF was added as a per version and overall AF
in -v1 and is now only applied as an overall AF and the test is updated
accordingly.
This script is some of the only documentation of certain processes that
run in the buildserver setup. It is not really maintained, but is still
here as a kind of reference.
Signing files is a slow operation, especially with jarsigner. This speeds
up the full test run from 10-12 seconds to 2-3 seconds, which makes it
possible to run the tests interactively again. And it stops signing the
file entirely for tests that do not even touch that file.
In the long run, it would probably make sense to have each test case sign
the file as it needs it, but that's a much bigger change.
Things like apksigner and @obfusk's tools handle this now.
jarsigner is used in the test, since that's the most common use of
`common.find_sdk_tools_cmd()`.
closes#1100
* for f in locale/*/LC_MESSAGES/fdroidserver.po; do msgattrib --set-obsolete --no-wrap --ignore-file=locale/fdroidserver.pot -o $f $f; done
* sed -i 's, \.\./fdroidserver/stats\.py,,' locale/*/LC_MESSAGES/fdroidserver.po
