| 2 Apr 2021 |
 _hc | the resulting image would be published to a registry, and then the fdroid build: job would use image: fdroid:buildserver or whatver its called | 11:10:21 |
| _hc | docker-in-docker is also possible, but I don't think its necessary | 11:10:50 |
 proletarius101 | Hmm I mean in the ci we don't have vagrant, do we? | 11:11:19 |
| _hc | apt-get install vagrant? | 11:11:38 |
| _hc | but vagrant isn't needed in the fdroid build: job | 11:11:56 |
| proletarius101 | In reply to @eighthave:matrix.org
but vagrant isn't needed in the fdroid build: job Yeah | 11:12:06 |
| _hc | the fdroid build job is running inside the buildserver guest directly, not the host | 11:12:22 |
| _hc | vagrant is only needed for the host | 11:12:29 |
| proletarius101 | In reply to @eighthave:matrix.org
vagrant is only needed for the host That's right | 11:12:42 |
| _hc | that's why it runs fdroid build --on-server | 11:12:49 |
| proletarius101 | Yep | 11:13:05 |
| _hc | docker-in-docker could be used to build and publish this new image | 11:13:44 |
| _hc | like in ci-images-base | 11:13:50 |
| _hc | that would install and use vagrant | 11:14:39 |
| _hc | I could frame something out if you are interested in working on this | 11:14:55 |
| proletarius101 | Hmm I suppose building docker images shouldn't really involve vagrant which complicated the steps but give no more reusable components? | 11:17:05 |
| _hc | vagrant gives us the tool to use the same provisioning across Docker, VirtualBox, and libvirt | 11:17:42 |
| _hc | I wouldn't start a new project with vagrant, but it is already there and running | 11:17:57 |
| proletarius101 | .gitlab-ci.yml shows ci image base is just built by dockerfile | 11:19:18 |
| _hc | you could probably even skip vagrant and just build the Docker image by running the existing provisioning | 11:19:39 |
| proletarius101 | In reply to @eighthave:matrix.org
vagrant gives us the tool to use the same provisioning across Docker, VirtualBox, and libvirt I would love to do it if it makes it more reusable, although I don't really understand how it works now | 11:20:01 |
| _hc | e.g. make buildserver/Dockerfile | 11:20:03 |
 izzy | _hc: isn't Suqashing already set as default for new MRs? | 11:20:12 |
| proletarius101 | In reply to @eighthave:matrix.org
e.g. make buildserver/Dockerfile If it's just a entrypoint difference, it could be done easily | 11:21:02 |
| _hc | gitlab-ci ignores entrypoint, so it can be used for people who want to use the image as a command line tool | 11:23:04 |
| _hc | izzy: ah right, I guess I really meant forcing linear history: https://gitlab.com/fdroid/fdroiddata/edit#js-merge-request-settings | 11:25:11 |
| _hc | e..g. "Fast-forward merge" | 11:25:38 |
 cdesai | could also set it to rebase | 11:25:54 |
| _hc | that's what Fsat-forward merge forces | 11:26:11 |
| izzy | I've not much experience with that. Any side-effects to be expected? | 11:27:09 |
