| 13 Oct 2021 |
 proletarius101 | for shared runners, we don't really care on what it runs | 15:47:04 |
 deimos | Hardware is cheap. Hosting is cheap. | 15:48:16 |
| proletarius101 | humens are expensive... | 15:48:41 |
| deimos | Alternative is to use k8s with linode or some place and fire up hundreds of containers to build each apk concurrently. | 15:50:32 |
| proletarius101 | we only use gitlab runners to execute gitlab jobs (e.g. for fdroiddata MRs). not the production server | 15:52:31 |
| proletarius101 | due to security concerns | 15:52:41 |
| deimos | Sane | 15:53:07 |
 cde | wouldn't an easy solution be to just have a bunch more runners allocated? Then it'd automatically use the free runner.
Do we have the servers available to put up a few more runners? | 15:58:49 |
| deimos | I've offered to make servers appear. | 15:59:45 |
| proletarius101 | i think we are only using self hosted runners for emulators? | 16:00:39 |
| deimos | Hardware or virtual. I'll provide root too if security of some stranger on the internet is a concern (as it should be) | 16:01:14 |
| proletarius101 | the concern here is only that we can easily share the runners among our contributors | 16:01:52 |
| cde | this would be just for ci, and we're already using the shared runners there. | 16:02:16 |
| cde | CI build is super useful for figuring out issues. | 16:02:34 |
| proletarius101 | * the concern here is only that we can easily share the self-hosted runners among our contributors | 16:02:47 |
| proletarius101 | In reply to @proletarius101:matrix.org
the concern here is only that we can easily share the self-hosted runners among our contributors due to the gitlab runner register procedure, it generate one registration key per repo. Since contributors fork the repos, they'll have to register runners by themselves | 16:04:42 |
| proletarius101 | but how can we automate the registration process> | 16:04:56 |
| proletarius101 | since pairing the runners need prior access to the runner | 16:05:59 |
| proletarius101 | such that you can enter the key there | 16:06:09 |
| cde | admin ticket + one of us does it manually? | 16:06:38 |
| proletarius101 | In reply to @cdesai:matrix.org
admin ticket + one of us does it manually? Limited ppl can access the machine now. Maybe just Hans | 16:11:06 |
| proletarius101 | In reply to @cdesai:matrix.org
admin ticket + one of us does it manually? That's the current procedure | 16:11:20 |
| deimos | We can expand that access with more machines? | 16:12:41 |
| cde | https://gitlab.com/fdroid/issuebot/-/merge_requests/41 please read it in full, thanks! | 19:07:17 |
| 14 Oct 2021 |
| deimos | i wish i could make the next meeting to figure out how to help on this buildserver/fdroidserver issue. | 04:20:09 |
 _hc | deimos: cde proletarius101 the blocker is someone implementing the runners in a way that is maintainable. The auto-scaling docker setup is proven to do that. servers/hardware are not the blocker at all. | 06:52:47 |
| _hc | Multiple people have access to the CI runner hardware. I've been asking for years for people to take them over and maintain them. We need sysadmins and dev time. | 06:53:21 |
| _hc | I can hand over a 16-core/32-thread/140GB RAM bare metal box to devote to gitlab CI runners to any one willing to set it up and maintain it | 06:54:57 |
| deimos | ok, what does "takeover" involve? | 07:06:01 |
| deimos | and/or what dev needs to be done? | 07:06:29 |
