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

1

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
2

Yes, it is.

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

All apps want that :slight_smile: :frowning:

3

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

1 Like
4

How would that help, a delay is a delay.

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

5

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
6

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)

7

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

8

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.

9

This is the DELAY I talked about…

10

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

11

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

12

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.