| 17 Oct 2022 |
 Artturin | ci passed | 18:03:23 |
| 22 Oct 2022 |
 @zseri:matrix.org | huh, why does https://github.com/NixOS/nixpkgs/pull/190730/checks?check_run_id=9036063946 get marked as "neutral" instead of "failure/error" (one of the modified packages itself failed to compile)? | 11:47:03 |
 7c6f434c | Build failures are always reported as neutral outcomes, because failures are for things that are even more unambiguous (you'd need to check for disk full, transient network issues etc. to be sure about build failures) | 11:48:23 |
 Sandro | No, it is stupid. GitHub treats it as being ignorable which it often isn't and broken packages should be marked as such. | 13:05:34 |
| @zseri:matrix.org | In reply to @7c6f434c:nitro.chat
Build failures are always reported as neutral outcomes, because failures are for things that are even more unambiguous (you'd need to check for disk full, transient network issues etc. to be sure about build failures) like, you need to check for that anyways on failures, and failures just say "well, it failed (probably to compile)", but you can ignore it if it is a false-positive... | 13:37:53 |
| 7c6f434c | ofBorg is tuned carefully to minimise false-positive red-failures | 13:38:44 |
| @zseri:matrix.org | uhm but when does it report red-failures then? | 13:41:00 |
| @zseri:matrix.org | * uhm but when does it report red-failures then? only syntax-errors? | 13:41:18 |
| 7c6f434c | Failed eval, for example | 13:41:24 |
| 7c6f434c | It's more than syntax errors | 13:41:36 |
| @zseri:matrix.org | well, as you now need to check it anyways when it returns "neutral", I don't think that distinction is that useful. | 13:46:27 |
| Sandro | also github collapses the checks when they are green and neutral only | 22:39:37 |
