13 Oct 2021 |
deimos | imho, k8s is a clusterf*ck, pun intended, and a great way to lose all control of costs and security. It's designed to make people spend more on cloud computing. | 15:43:52 |
deimos | What would we do if we didn't use gitlab's built in ci/cd? | 15:45:20 |
proletarius101 | In reply to @deimos:kde.org What would we do if we didn't use gitlab's built in ci/cd? what's the point of it 😅, it's even more costly | 15:46:01 |
deimos | I know gitlab pushes k8s and terrsform as solutions. | 15:46:01 |
proletarius101 | kubernetes is intended for self-hosted runner users | 15:46:37 |
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 |