Enabling CI for fdroiddata fork

fdroiddata
gitlab-ci

#1

Before I submit a merge request for fdroiddata, I would like to run my changes through CI to see if things work as I expect them to. (I do not have an f-droid server of my own.)

I see the main repo has CI in place, but it does not seem to be enebled by default on my repo (which I forked from the main repo before CI was added to it).

Are there any instructions how to get the same CI for my repo as well? Or any docs on the CI system used by F-Droid (as GitLab offers a handful of them and I don’t know which is the right one)? Or any other starting point?


#2

Unfortunately it’s currently broken. A lint job should run on your fork, a build job doesn’t exist in a working form atm.


#3

Too bad… once it is up and running again, what would I need to do in order to set it up?


#4

It would be great to get your docker-based image running ci for fdroiddata, @bubu. That should be a lot easier to make reliable. We just need to add some detection to skip apps that don’t build with gradle or the NDK.

@bubu do you think there is something missing in your docker image?


#5

@stanton to get the full buildserver CI builds working again, someone needs to troubleshoot why they stopped working. Anyone can setup their own copy of this VM using https://gitlab.com/fdroid/fdroid-bootstrap-buildserver, then register it as a gitlab runner on their fdroiddata fork. Then they can submit merge requests.


#6

ummm… that is just what I wanted to test with CI: a very custom build process.

The app is Navit, of which F-Droid still has a version that is over three years old. I have recently created a build script, which runs both on a regular Linux box (Ubuntu 18.04) and CircleCI (which the Navit project uses for CI).

Any chance of testing that?


#7

For F-Droid, the interface is the build metadata file and fdroid build. You can put whatever script you want in your app’s metadata file, just like you can in the Circle CI file.


#8

I’ll revisit this soon. I wanted it to be able to build all apps, including the ones that require NDK. For doing that the plan is to make fdroidserver auto-download the ndk if it’s not already installed (potentially with a config option if that’s deemed necessary).

The other thing that’s missing is an automated way to generate the docker image. For the first POC I did some manual steps involving the list of sdk compenents to install.


#9

While both of those are good goals, I think its definitely worth deploying without those in place.


#10

You can put whatever script you want in your app’s metadata file, just like you can in the Circle CI file.

Triggering the build script is not the issue, I am aware that I can specify any shell commands here. What I wanted to test is if the script completes without errors—specifically, if the F-Droid server has all necessary build dependencies (or if it can get them).

Build dependencies (packages) are: cmake gettext libsaxonb-java librsvg2-bin pkg-config libprotobuf-c-dev protobuf-c-compiler

Also, in addition to the Android SDK and NDK, the Android CMake component must have been installed via sdkmanager "cmake;3.6.4111459" (or the build script must run with permissions to install it). (Might work without if ninja-build is installed locally.)


#11

If your build needs dependencies, you need to ensure they’re installed as part of your build metadata file. If you need root, e.g. for apt-get install then use the sudo: build field.


#12

Just to clarify: what is the execution order of sudo=, prebuild= and build=?


#13

In any case I have an updated build recipe at https://gitlab.com/mvglasow/fdroiddata/commit/a53937db4ceb2fe9444e75deaa3a6d675d1567d6. Is there any way of testing this before I submit a merge request?


#14

sudo=, prebuild= then build=


#15

OK, then this should work as expected. Also, I just learned work is underway to enable auto-updating.

That leaves me with two questions now:

  • Any way I can test my build recipe? (I see some successful pipelines again, is CI back up and running?)
  • How can I specify a new build recipe to be used from the next (auto-detected) version onwards? If I add a new section, what would I put in the Build: line if I don’t know the version code yet?