OfBorg | 165 Members | |
| Number of builds and evals in queue: <TBD> | 61 Servers |
| Sender | Message | Time |
|---|---|---|
| 12 Oct 2023 | ||
| I agree that we should at the very least try to measure how often these problems happen before making any decision, but I don't think a low rate of false positives necessarily needs to be a blocker - it would still be a massive improvement | 16:06:01 | |
| (imo) | 16:06:03 | |
| Yeah I definitely want to get measurements for how often those transient failures happen, before changing anything. Stuff like build timeout, OOM, and nix daemon/builder error should be technically distinguishable from derivation-builder-error, though, so ideally we'd have the ability to do both "neutral" and "failure" conditions depending on how it failed I think there would be value in having at least some scoped conditions surrounding builds get a red X though, because I see a lot of PRs get merged with failing builds or tests because failures of, e.g. build timeouts due to rebuilding llvm or something, are not clearly distinguishable from failures due to the build just not actually working, without diving into the logs on the ofborg website I'd have to see where the decision was originally made, but I feel like, too, if there's enough of the community really wanting the red X now, we could decide to try it temporarily and roll it back if it does in fact turn out to be worse than status quo (even though that is admittedly hard to measure) | 17:53:51 | |
| I've definitely had PRs merged that were failing a build, and nobody noticed. It seems like some of the concerns (timeouts, OOM, hardware failure) are common across other CI systems, yet it is also quite common for them to mark builds as failing through the UI. | 18:14:03 | |
| Is the difference just a lack of ability to retry? | 18:15:55 | |
In reply to @adam:robins.wtfYou can actually have ofborg retry-ish now by requeueing the same attrs ( @ofborg build attr1 attr1.tests attr2 attr2.tests ...) | 18:18:57 | |
| It would be nice if there was a better way to request a retry of one build specifically though | 18:19:12 | |
In reply to @adam:robins.wtf* You can actually have ofborg retry-ish now by requeueing the same attrs (commenting @ofborg build attr1 attr1.tests attr2 attr2.tests ...) | 18:20:12 | |
* You can actually have ofborg retry-ish now by requeueing the same attrs (commenting @ofborg build attr1 attr1.tests attr2 attr2.tests ... on the PR) | 18:20:20 | |
| 22:24:38 | ||
| 13 Oct 2023 | ||
| 22:25:06 | ||
| 18 Oct 2023 | ||
| 16:52:34 | ||
| Heya! I've been redirected to here for a question A PR of mine wasn't able to be built on ofborg but I could on my end. I even tried on a separate machine then my laptop (albeit sharing a little bit of the same configuration) and it was able to build it. I don't understand why https://github.com/NixOS/nixpkgs/pull/260812#issuecomment-1766750802 | 16:54:52 | |
| 17:02:40 | ||
| Smells like a networking issue. Attempting to reproduce on my local machine, but fetching the source from blender is so slow x) | 17:02:58 | |
In reply to @cole-h:matrix.orgOhhhh yeah, I know how that feels. I've been working on PR for blender and the source fetching is always the longest | 17:04:55 | |
I submitted a "approved" review and wanted ofborg to build a test, so I put @ofborg test grow-partition in the review comment. Doesn't appear to have picked it up. Am I correct in assuming it only picks up regular comments? Should I just repeat the comment? | 17:31:14 | |
| Which PR? (Just so I can check if it appeared in the logs) | 17:31:56 | |
| https://github.com/NixOS/nixpkgs/pull/261449 | 17:32:02 | |
| Ah yeah, it seems it indeed doesn't check review comments for the purpose of looking for commands. | 17:33:32 | |
In reply to @cole-h:matrix.orgLooks like ofborg was able to build it this time | 17:33:54 | |
| Cool, maybe EM had an IPv6-resolution-hiccup in their networking. | 17:35:12 | |
In reply to @elvishjerricco:matrix.org(So yeah, submit another "normal" comment with the command and it should be picked up as normal) | 17:35:28 | |
| 20 Oct 2023 | ||
| 10:33:57 | ||
| 21 Oct 2023 | ||
| 19:14:51 | ||
| 23 Oct 2023 | ||
| nix.ci name isn't used much anymore, right? (even though occasionally referenced) The whole .ci TLD has broken DNSSEC right now, so it isn't accessible by default to some users. (vast majority in some countries, small minority in others) | 09:33:28 | |
| * nix.ci name isn't used much anymore, right? (even though occasionally referenced) The whole .ci TLD has broken DNSSEC right now, so it isn't accessible by default to some users. (vast majority in some countries, small minority in others, and minority globally as well I think) | 09:34:11 | |
| 09:52:59 | ||
| 09:53:04 | ||
| 14:27:48 | ||