| 2 Apr 2021 |
 cdesai | on rebase committer gets set to the person rebasing, but that's it I think | 11:28:37 |
 _hc | proletarius101: have you seen fdroidserver/vmtools.py? Basically, if there was a Docker buildserver image, then fdroid build could automatically start and run the job in that image, based on user config and code in fdroidserver/vmtools.py | 11:32:38 |
| _hc | izzy: those settings are easy to change and change back, so I recommend trying them out. You can edit them for fdroiddata, right? | 11:33:38 |
 izzy | I should be able to, yes – let me check… | 11:34:47 |
 Sylvia | So... we're building again | 11:35:46 |
| Sylvia | But I don't see a new update or an update known APKs commit | 11:36:01 |
| izzy | Yes, I an. So shall I set it to FF? "Fast-forward merge: No merge commits are created. Fast-forward merges only. When there is a merge conflict, the user is given the option to rebase." | 11:36:11 |
| Sylvia | Did it timeout waiting for Ciaran after 5 days? | 11:36:15 |
| izzy | Sylvia: sometimes Ciaran pushes that a bit delayed. Not sure if that's the case here, though. | 11:37:56 |
 proletarius101 | In reply to @eighthave:matrix.org
proletarius101: have you seen fdroidserver/vmtools.py? Basically, if there was a Docker buildserver image, then fdroid build could automatically start and run the job in that image, based on user config and code in fdroidserver/vmtools.py I'll take a look | 11:50:15 |
| _hc | proletarius101: but maybe it makes more sense to just tell docker users to use the buildserver image as a "docker executable" and skip that layer of abstraction | 11:53:03 |
| proletarius101 | Yeah, from the user perspective it's true. Maybe that's why I don't see exactly how we could change | 11:55:01 |
| izzy | _hc: so I switch fdroiddata to fast-forward merging? | 11:58:24 |
| _hc | izzy: that's the one that makes the fewest commits | 12:02:15 |
| _hc | proletarius101: so then just making a buildserver image with the provisioning scripts seems the most straightforward | 12:03:11 |
| izzy | Yepp. And makes a clearly ordered history. So let's try it, right? | 12:03:22 |
| _hc | build it like ci-images-base | 12:03:23 |
| _hc | izzy: I like that one the most, but I'm not a fdroiddata maintainer. You can always just try it for one merge request, then flip the setting back | 12:04:20 |
| izzy | OK, I'm going to ask LK if he agrees. If he doesn't oppose, we simply give it a try. Should it cause issues, we can always switch back. I've just no idea how existing MRs will be handled. | 12:05:39 |
|  FstplttnSchntzl joined the room. | 12:24:40 |
| cdesai | on GitHub you're able to select what to do directly when merging the MR (Merge / Rebase / Squash) | 12:36:27 |
| _hc | izzy: that setting will change the merge behavior immediately, it is based on when you click Merge, not when the MR was opened | 12:43:17 |
| izzy | _hc: thanks, that makes the decision easier! I'm just talking with LK, looks like he's OK with it. | 12:44:04 |
| izzy | OK, switched MRs on fdroiddata to FF for now. Should that cause any difficulties, feel free switching back to "merge commit" immediately. | 12:49:56 |
| izzy | Next, fossdd FstplttnSchntzl and I should analyze issuebot reports to see which parts of them are not "essential" for our reviews and should be moved to artifacts, then open an issue on issuebot for Hans to process. | 12:51:30 |
| izzy | _hc: could you wrap the entire body of the issuebot comments in "<details>" for "less scrolling"? Some of those require multiple page-downs (especially when NodeJS is involved). | 12:52:38 |
| Sylvia | We completely skipped the deploy step (see wiki) | 13:14:28 |
| Sylvia | :( | 13:14:33 |
| _hc | I emailed that to Ciaran | 13:32:58 |
| _hc | proletarius101: did you have any luck getting the auto-scaling gitlab runner setup working? | 13:36:52 |
