Migration to bullseye breaks CI for apps
Note: This issue spans multiple projects; if I should move it to a different repository, please let me know!
A while ago I contributed a step-by-step guide to integrate F-Droid builds into your own app’s CI workflow. I have since made that the default CI for all apps whose development I am involved in.
With the F-Droid server migrating to bullseye but all other CI images (ci-images-client and ci-images-base) remaining on stretch, this setup no longer works, as setting up the F-Droid server involves modifications to package sources and package installations. Without further modification, CI will fail because one of the repositories is now accessed via HTTPS, and HTTPS transport for apt is not installed. Even then, version conflicts between packages would probably cause further trouble.
One way to fix this would be to keep all images in sync, i.e. based on the same OS version. However, I cannot judge how feasible this is – there may be additional complications that I am not aware of.
Another approach would be to run CI for apps on the fdroidserver:buildserver
image, which would eliminate such OS version inconsistencies for good. I have tried building a CI config for that for one of the apps I support; you can view it at https://github.com/navit-gps/navit/tree/ci-fdroid-buildserver.
Basically I based these steps on the fdroid build
step of the CI script in this very repo, with a few modifications:
- install fdroidserver from source (as it is not the CI project but a tool required for CI)
- skip fdroiddata download (as we’re building from a recipe supplied by the CI project)
- set variables in the current environment and run
fdroid
from there
I also found that $$SDK$$/tools/bin/sdkmanager
points to the original Google version, which is incompatible with Java 11 (the old CI image seems to have had an older Java version). I fixed this by symlinking $$SDK$$/tools/bin/sdkmanager
to the output of which sdkmanager
(should be /usr/bin/sdkmanager
, which works – not sure if that is F-Droid’s own implementation or an updated Google version).
The build recipe on which I tested this is for Navit. Its prebuild
section calls a few sdkmanager
to install some missing dependencies; the build
phase calls a build script which relies on cmake. The prebuild
section completes successfully, but buils fails as the cmake binary is not on the current PATH
(this has worked in the previous version).
All in all, this is a regression of the migration to bullseye. Any recommendations on fixing this?