| 13 Apr 2023 |
 K900 | It happened again. | 08:45:32 |
| K900 | https://github.com/NixOS/nixpkgs/pull/215109 | 08:45:33 |
| K900 | I think I know what I'm doing this weekend | 08:45:45 |
 Sandro | Blocking merge to master if the rebuild amount is to high and bringing ofborg into the hot path might not be the best idea. Calculating the rebuild amount takes a good amount of time, if ofborg is overloaded potentially hours. Also there are not even a handful of people maintaining ofborg and the domain for it recently expired. | 08:56:50 |
| K900 | Well it can't actually block | 08:57:18 |
| K900 | You can still merge even if it's red | 08:57:23 |
| K900 | And it probably shouldn't be red until the rebuild count is known | 08:57:34 |
| K900 | But I think this is the kind of situation where a slow failsafe is better than no failsafe | 08:58:13 |
 vcunat | Well, merging before eval checks happen isn't great either. | 08:58:25 |
| vcunat | (Though of course, there are cases where you know what you're doing.) | 08:58:59 |
 Artturin | https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-status-checks-before-merging | 09:00:18 |
| Artturin | Afaik there's no way to block on a specific check | 09:04:35 |
| Artturin | 
Download 71f7adbd-f2a4-4444-8b8f-e4896f4c217c.jpeg | 09:07:33 |
 7c6f434c | Well, OfBorg is very conservative with red… | 09:08:16 |
