Seein the "running" status is very good! Are the timestamps UTC or local? How long does it take on average for an update of the "last modified" in running? (ideas for a "FAQ" screen).
Timestamps are local times.
Plus maybe a raw outline of how the entire "process cycle" works, like
- checkUpdates (https://f-droid.org/repo/status/checkupdates.json) triggered cia cron job
- build process (obviously triggered manually) with running/finished
- manual signing
- deploy (https://f-droid.org/repo/status/deploy.json) – most likely triggered manually as final step of the signing process
Not sure where https://f-droid.org/repo/status/update.json fits in.
Maybe it would be good to have this also on the F-Droid documentation page. I don't think this API is already documented, is it?
@pstorch I don't know if it's the goal of your app, but maybe you should add everything about the server and the clients (apps but also F-Droid Android client) in your interface. A central point to get the logs, builds, errors... instead of browsing the wiki, all is aggregated there.
@pstorch AFAIK it's not yet documented. But I'm not the person for that part; I'd prefer someone with "deeper knowledge/experience" should do that. Truth be told, I'm already split too often, I cannot keep up with yet another task… If you want to drop your notes there, that would certainly be welcomed. You know how it works: Ask someone to document it, and you'll wait for that 'til judgement day. Just set up a totally wrong documentation, and everyone jumps in fixing it ("someone is wrong on the Internet" effect) 🤣
Just came in: https://gitlab.com/fdroid/fdroid-website/-/issues/530
Someone is reading our mind 😁
That is strange indeed. I thought my app tricks me. Because I got a build update notification, opened the App and the number was decreasing.
Wondering: could it be that there are two instances of the build server are running in parallel overwriting each others running.json?
No, this can't be, right?
Probably not, but technically it's possible. That's why the PID (process id) and a reference of the instance server would be crystal clear.
That's not provided by the current API. But I think a good idea.
BTW: I still see a flapping between 10 and 13 successful builds.
Other theory: does the website have several cluster nodes? Maybe one was not updated correctly with the last running.json?
Regarding the counts of failed and successful builds: I just found an error in the deduplication logic in the app. 😢
could it be that there are two instances of the build server are running in parallel
Not yet AFAIK. That's something that was discussed, though, too speed up the build process – but the "sync" between the two must be implemented. Back then it was decided to do the usual trick: slain it with hardware (more cores, more RAM). It's still on the list, though, as parallel processing would have another advantage: if one machine chokes, the other goes on (hopefully).
Deleting a branch is permanent. It CANNOT be undone. Continue?