| 13 Apr 2023 |
 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 |
| Lily Foster | (I think massive rebuilds to master should be red regardless, but I do wish build failures were also more obvious to others with ofborg) | 15:31:07 |
| 7c6f434c | Well, some large single-package updates that will timeout on their own are master-targeted because they are too often security updates.
(The list of transient failures to keep gray so that people stop caring about red is a complicated question; are ENOSPC rare enough?) | 15:53:11 |
| Artturin | In reply to @sandro:supersandro.de
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. we could comment if 10.rebuild-linux: 501+ and targetting master
https://docs.github.com/en/actions/managing-issues-and-pull-requests/commenting-on-an-issue-when-a-label-is-added
| 17:50:13 |
| K900 | Oh that's probably easier than hacking this into ofborg | 17:52:49 |
| K900 | That's actually way easier, wow | 17:53:44 |
| 7c6f434c | (Oh, and of course red on build failures in OfBorg is pure negative without recognition of dep failures — marking stuff with currently-being-fixed deps as broken just because of them is absolutely pointless) | 18:29:15 |
| Lily Foster | In reply to @7c6f434c:nitro.chat
(Oh, and of course red on build failures in OfBorg is pure negative without recognition of dep failures — marking stuff with currently-being-fixed deps as broken just because of them is absolutely pointless) (Does that occur often? Marking something red does not prevent merging if it really needs) | 18:32:56 |
| 7c6f434c | I think it occurs quite often if you consider Darwin a platform, or if you consider staging a branch | 18:33:49 |
| 7c6f434c | And OfBorg design choice is extremely low tolerance to making pointless noise red. | 18:35:02 |
| Lily Foster | In reply to @7c6f434c:nitro.chat
I think it occurs quite often if you consider Darwin a platform, or if you consider staging a branch Problems that are transitive dep failures though, not timeouts or anything? | 18:35:14 |
