| 9 Apr 2023 |
 emily | In reply to @artturin:matrix.org
See yesterdays discussion oh, my bad. ty | 14:47:52 |
| emily | * logs.nix.ci no longer resolves for me 👀
❯ dig @1.1.1.1 A logs.nix.ci
; <<>> DiG 9.18.8 <<>> @1.1.1.1 A logs.nix.ci
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43105
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;logs.nix.ci. IN A
;; AUTHORITY SECTION:
ci. 7200 IN SOA ns.nic.ci. hostmaster.ns.nic.ci. 2023041183 480 300 1209600 7200
;; Query time: 53 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Sun Apr 09 16:46:02 CEST 2023
;; MSG SIZE rcvd: 93
| 14:48:34 |
| 10 Apr 2023 |
 hexa | the logviewer still wants to read from logs.nix.ci | 13:20:59 |
| hexa |
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://logs.nix.ci/logs/nixos/nixpkgs.225507. (Reason: CORS request did not succeed). Status code: (null).
| 13:21:11 |
 cole-h | ...right, cuz the repo for that is separate from ofborg itself.
OK, one moment. | 13:22:05 |
| cole-h | Try now? | 13:24:53 |
 K900 | Can we make ofborg scream if a PR with, say, 2000 or more rebuilds targets master? | 13:26:11 |
| K900 | Preferably in a way that blocks merging | 13:26:39 |
| K900 | Or at least makes the button scary | 13:26:49 |
| cole-h | ofborg does not block merging. It's only guidance, because it's not always 100% correct. | 13:27:05 |
| cole-h | I would think that the big red "1000+ rebuilds" labels would already kinda make the button scary though, no? | 13:27:25 |
| K900 | No one sees those if there's like 100 comments | 13:27:45 |
| K900 | And the merge button is at the bottom | 13:27:51 |
| K900 | https://github.com/NixOS/nixpkgs/pull/218331 happened earlier today | 13:28:41 |
| K900 | We already have a check that fails when you try to target a channel branch | 13:29:39 |
| K900 | Would be nice to have something like that for staging | 13:29:57 |
| cole-h | While not ideal, I don't necessarily want to give PRs a big red X (a failed status check) unless something is broken. | 13:30:41 |
| K900 | Well github doesn't exactly have a warning state | 13:31:24 |
| K900 | And I think a big red X is preferable to merging 5000 rebuilds into master directly | 13:32:02 |
| cole-h | I'd also argue that there are valid cases where we'd want to merge a large rebuild to master (say, a massive vulnerability in glibc or openssl that allows RCE or things). | 13:32:15 |
| K900 | I'd expect anyone that actually needs to do this to know this is not fatal | 13:32:24 |
| K900 | Like, you can always ignore the check and merge | 13:32:50 |
| cole-h | Related to my last message is I don't want to cheapen the "big red X" from ofborg. If you get a big red X, that PR should not be merged in its current state, period. | 13:33:03 |
| K900 | That's not really true either though | 13:33:40 |
| K900 | There are also valid situations where you might want to merge something that's still broken but maybe becomes less broken | 13:34:02 |
| K900 | And then there's staging where pretty much every PR is red because ofborg can't catch up | 13:34:26 |
| K900 | (not that it should try to( | 13:34:34 |
| K900 | * (not that it should try to) | 13:34:38 |
| cole-h | Is there a documented number somewhere in nixpkgs that says "builds greater than this amount should target staging"? | 13:38:50 |
| K900 | https://nixos.org/manual/nixpkgs/unstable/#submitting-changes-staging-branch | 13:39:19 |
