| 8 Oct 2021 |
 proletarius101 | and it seems to be safe to align fdroid build's GIT_DEPTH to that of the pages` job:
variables:
GIT_DEPTH: "5000"
https://gitlab.com/proletarius101/fdroiddata/-/blob/master/.gitlab-ci.yml#L199-200
| 01:04:53 |
| proletarius101 | Before we start building anything, it's already
$ df -h
Filesystem Size Used Avail Use% Mounted on
overlay 21G 8.9G 12G 44% /
tmpfs 64M 0 64M 0% /dev
tmpfs 1.8G 0 1.8G 0% /sys/fs/cgroup
/dev/sda1 21G 8.9G 12G 44% /builds
shm 64M 0 64M 0% /dev/shm
tmpfs 1.8G 0 1.8G 0% /sys/devices/virtual/dmi/id
https://gitlab.com/proletarius101/fdroiddata/-/jobs/1660668108
| 01:22:35 |
| proletarius101 | Track this issue at https://gitlab.com/fdroid/fdroiddata/-/issues/2503 | 01:30:38 |
 deimos | is this a VM? who has 21GB anymore? | 03:41:57 |
 linsui | It's the gitlab ci. | 03:46:13 |
| deimos | yeah, so docker images | 03:52:40 |
| deimos | i didn't clickon the links yet, at the tail end of writing a 45 page proposal | 03:53:16 |
| proletarius101 | Redacted or Malformed Event | 12:05:03 |
| proletarius101 | In reply to @eighthave:matrix.org
actually yes, this is based on actual real world measurements on our exising infra. the all-in-one image took 01:35 to pull: https://gitlab.com/proletarius101/fdroiddata/-/jobs/1662392786, while our current image took 01:00 to pull: https://gitlab.com/proletarius101/fdroiddata/-/jobs/1662392784.
However, our current image still need more than 5min to install the dependencies | 13:03:12 |
| deimos | I think most of the problem is using gitlab native CI | 15:17:28 |
 cde | do you mean using their runners? | 15:19:34 |
| cde | or just ci in general | 15:19:38 |
| deimos | their runners | 15:26:10 |
| deimos | esp because we're not on enterprise or whatever their expensive plan is | 15:26:39 |
| deimos | i thought there was a way to specify container size | 15:27:24 |
| deimos | but maybe that's only ee | 15:27:30 |
| deimos | i'm looking at https://gitlab.com/proletarius101/fdroiddata/-/jobs and .gitlab-ci.yml | 15:28:45 |
| deimos | as crazy as iit might sound, use gitlab-ci to run a script that ssh into a server, and then runs the ci | 15:29:30 |
| deimos | instead of relying on gitlab's runners | 15:29:50 |
 jochensp | or just register your own runners, as F-Droid does already for some things | 15:30:47 |
| proletarius101 |
esp because we're not on enterprise or whatever their expensive plan is
we can. actually they are waiting for us to sign the contract for the top level plan for free
| 15:37:57 |
| proletarius101 | but that doesn't provide more powerful runners | 15:38:13 |
| proletarius101 | maybe we can open an ticket for that? | 15:38:22 |
| proletarius101 | In reply to @deimos:kde.org
as crazy as iit might sound, use gitlab-ci to run a script that ssh into a server, and then runs the ci the emulator job is using that model. one of the reasons it's slow due to the enormous queue | 15:41:27 |
| deimos | i'm just reading through the fdroidserver repo | 15:42:19 |
| deimos | In reply to @proletarius101:matrix.org
the emulator job is using that model. one of the reasons it's slow due to the enormous queue would more cores/ram help? | 15:50:07 |
| proletarius101 | our own runners are already running in full speed i think. the issue might be the runner not parallel (we don't run multiple runners or doing auto-scaling) | 15:51:32 |
| proletarius101 | the hosted runners have only 1 core each. so indeed kind of slow for java or c++ | 15:52:10 |
| deimos | that's what i was really getting at, 128 cores should run around 100 parallel jobs | 15:52:29 |
| proletarius101 | but it doesn't matter. the issue here is it's out of space | 15:52:27 |
