fdroidserver is a suite of tools to publish and work with collections of Android apps (APK files) and other kinds of packages. It is used to maintain the f-droid.org application repository. These same tools can be used to create additional or alternative repositories for publishing, or to assist in creating, testing and submitting metadata to the f-droid.org repository, also known as fdroiddata.
For documentation, please see https://f-droid.org/docs.
In the beginning, fdroidserver was the complete server-side setup that ran f-droid.org. Since then, the website and other parts have been split out into their own projects. The name for this suite of tooling has stayed fdroidserver even though it no longer contains any proper server component.
There are many ways to install fdroidserver, including using a range of package managers. All of the options are documented on the website: https://f-droid.org/docs/Installing_the_Server_and_Repo_Tools
The production setup of fdroidserver for f-droid.org is run directly from the master branch. This is put into production on an schedule (currently weekly). So development and testing happens in the branches. We track branches using merge requests. Therefore, there are many WIP and long-lived merge requests.
There are also stable releases of fdroidserver. This is mostly intended for running custom repositories, where the build process is separate. It can also be useful as a simple way to get started contributing packages to fdroiddata, since the stable releases are available in package managers.
To run the full test suite:
tests/run-tests
To run the tests for individual Python modules, see the tests/test_*.py files, e.g.:
python -m unittest tests/test_metadata.py
It is also possible to run individual tests:
python -m unittest tests.test_metadata.MetadataTest.test_rewrite_yaml_special_build_params
There is a growing test suite that has good coverage on a number of key parts of this code base. It does not yet cover all the code, and there are some parts where the technical debt makes it difficult to write unit tests. New tests should be standard Python unittest test cases. Whenever possible, the old tests written in bash in tests/run-tests should be ported to Python.
This test suite has built over time a bit haphazardly, so it is not as clean, organized, or complete as it could be. We welcome contributions. The goal is to move towards standard Python testing patterns and to expand the unit test coverage. Before rearchitecting any parts of it, be sure to contact us to discuss the changes beforehand.
These tests are also run on various configurations through GitLab CI. This is
only enabled for master@fdroid/fdroidserver because it takes longer to
complete than the regular CI tests. Most of the time you won't need to worry
about them, but sometimes it might make sense to also run them for your merge
request. In that case you need to remove these lines from .gitlab-ci.yml
and push this to a new branch of your fork.
Alternatively run them
locally
like this: gitlab-runner exec docker ubuntu_lts
The API documentation based on the docstrings gets automatically
published here on every commit
on the master branch.
It can be built locally via
pip install -e .[docs]
cd docs
sphinx-apidoc -o ./source ../fdroidserver -M -e
sphinx-autogen -o generated source/*.rst
make htmlTo additionally lint the code call
pydocstyle fdroidserver --countWhen writing docstrings you should follow the numpy style guide.
Everything can be translated. See Translation and Localization for more info.
