| 8 Oct 2021 |
 proletarius101 | In reply to @deimos:kde.org
that's what i was really getting at, 128 cores should run around 100 parallel jobs yeah i have a stale MR for that: https://gitlab.com/fdroid/fdroid-gitlab-runner/-/merge_requests/3#note_543891209 | 15:53:03 |
 deimos | i'm sensing this is the story of fdroid, "stale MRs" | 15:53:29 |
| proletarius101 | you may pick it up if you're interested | 15:54:26 |
| deimos | https://forum.gitlab.com/t/how-to-increase-disk-space-of-a-gitlab-runner/56037 | 15:57:07 |
| deimos | ha | 15:57:08 |
| deimos | "no answer" | 15:57:16 |
| proletarius101 | In reply to @deimos:kde.org
"no answer" For on-premises runners, that can be setup in the config file... | 16:14:07 |
| proletarius101 | The only problem is we are using the hosted runners | 16:14:33 |
| proletarius101 | 21GB is fair enough. It's just we are wasting half of it | 16:15:04 |
| 9 Oct 2021 |
|  outsidecontext left the room. | 02:39:53 |
| outsidecontext joined the room. | 02:58:46 |
|  mimi89999 left the room. | 04:03:36 |
| mimi89999 joined the room. | 04:04:07 |
 Sylvia | linsui: Could you take a look at https://gitlab.com/fdroid/fdroiddata/-/merge_requests/9891 when you have time and merge it if I've done it correctly? Never used UpdateCheckData before so I'd like to be sure I'm doing it right :) CI seems to like it (and complain because, yes, 3.1.8 exists already) so I think it's good but first time I'd rather be extra certain :) | 14:57:14 |
 Andreas | An Öffi developer suggested it might help reproducible builds to execute gradle clean explicitly before gradle build, in order to download all SDK components before the actual build starts. Do you think this is a valid point?
If yes, how can I accomplish this in a metadata file? Would
gradle:
- clean
- aosp
execute in one gradle invocation, or in two?
| 17:00:40 |
| proletarius101 | In reply to @andreas:schildbach.de
An Öffi developer suggested it might help reproducible builds to execute gradle clean explicitly before gradle build, in order to download all SDK components before the actual build starts. Do you think this is a valid point?
If yes, how can I accomplish this in a metadata file? Would
gradle:
- clean
- aosp
execute in one gradle invocation, or in two?
You may try. But you can always execute gradle clean in the Build section which will be executed before gradle | 17:10:35 |
| proletarius101 | According to https://f-droid.org/en/docs/Build_Metadata_Reference/#build_gradle it will be 2 | 17:12:05 |
![@_oftc_Licaon_Kter[xmpp]:matrix.org](./avatar/Licaon_Kter%5Bxmpp%5D) Licaon_Kter[xmpp] | It uses clean iirc | 17:28:41 |
| 10 Oct 2021 |
| proletarius101 | In reply to @_oftc_Licaon_Kter[xmpp]:matrix.org
It uses clean iirc At least not in the ci, which causes No Space Left if we have many versions to build | 07:42:09 |
 linsui | When gradle is used, fdroidserver run gradle clean automatic before build. The build artifact is removed after build in the CI. | 07:53:02 |
| Licaon_Kter[xmpp] | proletarius101: | 08:02:24 |
| Licaon_Kter[xmpp] | > At least not in the ci, which causes No Space Left if we have many versions to build | 08:02:24 |
| Licaon_Kter[xmpp] | Odd | 08:02:24 |
| proletarius101 | In reply to @_oftc_Licaon_Kter[xmpp]:matrix.org
Odd Or maybe it's cleaned right before the Gradle build step? https://gitlab.com/proletarius101/fdroiddata/-/jobs/1664240571 | 08:04:51 |
| Licaon_Kter[xmpp] | Grep through python, I know it's run once or maybe twice, as sometimes this interferes with builds :)) | 08:05:35 |
| linsui | In reply to @proletarius101:matrix.org
Or maybe it's cleaned right before the Gradle build step? https://gitlab.com/proletarius101/fdroiddata/-/jobs/1664240571 Yes. gradle cleam is run between prebuild and build. | 08:06:46 |
| proletarius101 | In reply to @rdfg77:kde.org
Yes. gradle cleam is run between prebuild and build. Well that's explains the the errror | 08:07:17 |
| proletarius101 | Maybe it should also clean after a build | 08:08:19 |
| proletarius101 | Or right before a build | 08:08:37 |
| proletarius101 | Or maybe we just dynamically generate ci jobs which will also bypass the issue | 08:09:18 |
