13 Oct 2021 |
Sylvia | I haven't seen any sadly, I guess nobody bothers to check GitLab even though it is supported this year too | 05:47:05 |
linsui | I didn't see that news somewhere else except this channel. Maybe a post on mastodon helps. | 06:41:28 |
| kempe2 joined the room. | 07:26:04 |
Izzy | Good idea – toot sent. Let's see :) | 07:50:06 |
proletarius101 | Might also help if you post on our forum and reddit | 09:48:21 |
proletarius101 | Or even a blog post on f-droid.org | 09:48:52 |
proletarius101 | In reply to @proletarius101:matrix.org Or even a blog post on f-droid.org Which I think might attract someone to translate this msg | 09:49:56 |
cde | _hc: mind taking a look at https://gitlab.com/fdroid/privileged-extension/-/merge_requests/67 | 11:35:31 |
jochensp | _hc: do you have any idea for the fdroidserver CI test on Windows failing? https://gitlab.com/fdroid/fdroidserver/-/pipelines/387686573 | 14:03:40 |
_hc | https://gitlab.com/fdroid/fdroidserver/-/jobs/1676131013 | 14:07:38 |
_hc | hmm strange, I don't know. maybe linsui has an idea? | 14:07:52 |
_hc | or just retry it, I triggered it | 14:08:30 |
_hc | proletarius101: deimos having that auto-scalling runner setup would unblock somethings, and would be great to have. its on the higher priority side of things IMHO. | 14:08:41 |
jochensp | _hc: I think it is persistent, so it on my PRs as well | 14:09:28 |
_hc | does reverting the change fix it? | 14:10:27 |
jochensp | no | 14:10:58 |
cde | it looks like something generic with the runners / python setup - do we know of any other projects using windows + python + gitlab ci? | 14:11:46 |
jochensp | it looks like a change in chocolatey | 14:11:53 |
cde | https://gitlab.com/fdroid/fdroidclient/-/merge_requests/1063
Don't allow push-requests at all for the official client. | 14:36:38 |
cde | Thoughts? | 14:36:41 |
cde | This was a feature added 5 years ago that lets repos automatically install/uninstall apps | 14:36:53 |
proletarius101 | In reply to @eighthave:matrix.org proletarius101: deimos having that auto-scalling runner setup would unblock somethings, and would be great to have. its on the higher priority side of things IMHO. agreed. it just not easy to implement | 14:51:02 |
proletarius101 | Just know that gitlab is migrating away from docker machine, in favor of kubernetes: https://gitlab.com/gitlab-org/gitlab/-/issues/341856 | 15:35:32 |
_hc | it doesn't matter how its implemented, the key part is that we manage one runner key, and then it can run in many different runners | 15:36:38 |
proletarius101 | yeah, i mean, it doesn't worth it to invest time on the docker+machine executor as i did in my MR, since it will be unsupported soon. will need a new MR then | 15:38:40 |
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 |