Any efforts to resolve the extreme build delays in `fdroidserver`?

A common frustration of mine as an OSS maintainer deploying to F-Droid is in the sheer delay in applications being built. Currently, Auxio has a massive breakage that I’ve pushed patches for, but since I didn’t get them in before the next build job, the patches have not been pushed for almost a week now.

Is there any efforts to improve this situation at all? I don’t see why apps that need updating can’t, say, be placed in a queue, letting the server constantly do work building and publishing new APKs. Is it a security thing?

1 Like

Yes, it is.

Read more: FAQ · Wiki · F-Droid / wiki · GitLab

All apps want that :slight_smile: :frowning:

I’m not fully understanding the security reasoning still. Could builds at least be continuous and then signing can still be periodic?

1 Like

How would that help, a delay is a delay.

Also, we’re aware of it and we’ll investigate.

How would that help a delay is a delay

It would be a lesser delay. It seems like from the documentation currently the the cycle is like:

[ 3 DAY BUILD CYCLE ] [ WAIT 3 DAYS ] [ SIGN & PUBLISH ] [ ANOTHER DELAY UNTIL THE NEXT BUILD CYCLE ??? ]...

(Order is probably wrong here)

Which means you are usually waiting 6 days. Sometimes 3 days if you’re lucky. Meanwhile if builds were queued and continuously built:

[ WAIT 3 DAYS ] [ SIGN & PUBLISH ] ...
[ CONTINUOUSLY DISCOVERING UPDATES AND BUILDING ] ...

That would be a delay of 3 days on average. A net improvement, I’d say.

1 Like

There could be a priority property for the updates, most developers would use it honestly, I think

E.g. it might well be justified to run a custom run for updates declaring to have a security fix (and to a less degree those that make a app work again)

You forgot to put in the same [ DELAY ] here…

There’s no need, since the builds are continuous and no longer need to be manually triggered every X days. Imagine i.e a webhook that notifies fdroidserver when the build metadata of an app changes. It then queues a build to occur later automatically. Every once in awhile someone logs into the airgapped server and signs all the built apps.

This is the DELAY I talked about…

Sure, but that delay is still lesser than the combined build cycle + signing delay that’s currently going on.

Maybe or maybe not, there’s a todo with multiple servers and signers, in the near to far future been discussed.