16 Nov 2018 |
_hc | then it looks like about half of that 15 seconds is spent cleaning the repo and possible submodules | 16:22:30 |
_hc | so a simple git fetch --tags should be pretty fast | 16:23:15 |
Marcus (old) | _hc: what are you running to profile this/ | 16:23:21 |
_hc | a print() on every function and my eyes | 16:23:51 |
_hc | Marcus (BubuIIC): https://clbin.com/zPskz | 16:24:51 |
_hc | git fetch --tags takes less than 1 second | 16:25:07 |
_hc | when nothing is to be updated | 16:25:14 |
_hc | seems like checkupdates in Tags mode should just use only git fetch --tags | 16:26:18 |
_hc | I don't understand why checkupdates.check_tags() needs to do anything with the git repo except git fetch --tags | 16:32:11 |
_hc | it does all sorts of things, like cleaning it, checking for submodules, etc. | 16:32:29 |
Erik Schilling (Ablu) | Marcus (BubuIIC): alright. thanks. Will try to contribute the app then! | 16:32:58 |
_hc | excellent! | 16:33:28 |
Marcus (old) | _hc: I think it just calls gotorevision, right? | 16:34:04 |
Marcus (old) | and that makes sure that repo is in pristine state at that revision | 16:34:16 |
Marcus (old) | adn check_tags does that for all revent tags, so it's gonna take a while | 16:34:35 |
Tovok7 | there's probably lots of optimization potentional | 16:34:38 |
_hc | there is indeed | 16:34:47 |
Tovok7 | just the question if you want to start to optimize before or after taking over the job | 16:35:04 |
_hc | it is tags mode that makes it so slow | 16:35:11 |
_hc | it then loops through all tags, doing all that clean/submodule stuff | 16:35:37 |
_hc | then tries to parse versionCode/versionName/packageName | 16:35:47 |
_hc | Tags mode with s#387 and s!182 would be drastically faster | 16:37:34 |
[gibot] | [server] #387: allow the version of a build to be figured out at… - https://gitlab.com/fdroid/fdroidserver/issues/387 | 16:37:36 |
[gibot] | [server] !182: WIP: add sensible defaults to the build metadata - https://gitlab.com/fdroid/fdroidserver/merge_requests/182 | 16:37:38 |
_hc | Tovok7: I think it still makes sense to move checkupdates to gcc137 | 16:38:30 |
_hc | since migrating to something new will take a while | 16:39:19 |
_hc | the other fun one would be to allow fdroid build to run N buildserver instances in parallel | 16:40:10 |
Tovok7 | yep, just make sure we can replace the server where checkupdates runs quickly if the need arises. | 16:40:13 |
_hc | it can always revert back to CiaranG or anyone can run it and submit a MR | 16:40:44 |
_hc | seems checkupdates should just be frozen as it is and run on a fast machine, since we have it | 16:41:16 |