| 10 Apr 2023 |
 tea | https://discourse.nixos.org/t/nixpkgs-update-runs-nixpkgs-review-on-every-pr/6701 | 14:02:22 |
| tea | Redacted or Malformed Event | 14:02:54 |
| 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 |
 Vladimír Čunát | Well, merging before eval checks happen isn't great either. | 08:58:25 |
| Vladimír Čunát | (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 |
| Artturin | Looks like it's possible | 09:09:27 |
| Artturin | 
Download 9adc2cdc-11f0-4f1c-8727-6a649db73a66.jpeg | 09:09:30 |
| Sandro 🐧 | I just got an idea: if we only block merge in the presence of a mass rebuild and ignore the absence completely, it would work | 09:46:14 |
| Sandro 🐧 | In reply to @7c6f434c:nitro.chat
Well, OfBorg is very conservative with red… I am talking about this for months if not a year already: failed pipelines should be red instead of grey. If people don't know how to fix it, they should mark the package broken. Also saves hydra resources. | 09:47:02 |
| tea | In reply to @k900:0upti.me
You can still merge even if it's red yes. we should make more checks red imo but a bit off topic | 09:48:02 |
| 7c6f434c | If you make build failures red now, you'll get timeouts red. | 09:49:56 |
| Sandro 🐧 | So? Would that be a bad thing? | 12:11:42 |
| Sandro 🐧 | If things time out we probably want to restart them anyway | 12:11:53 |
| K900 | Staging times out all the time | 12:14:22 |
| K900 | So probably not the best idea | 12:14:27 |
| Sandro 🐧 | so exclude PRs targeting staging? I really want to push for that because most new people think grey can be ignored which it usually cannot especially for new packages. | 13:59:08 |
| Sandro 🐧 | * so exclude PRs targeting staging? I really want to push for that because many new people think grey can be ignored which it usually cannot especially for new packages. | 13:59:20 |
| 7c6f434c | Chromium update will timeout on its own | 15:26:08 |
 Lily Foster | I also occasionally get ofborg timeouts for larger packages or if some big rebuilds (e.g. nodejs) are on master (generally just for darwin builders though -- usually linux builders don't suffer from build timeouts unless it's to staging or something is wrong). Could ofborg differentiate between timeout/failure and set timeout to neutral and propagate the failure red? | 15:30:01 |
