| 25 Jan 2025 |
 zowoq | No, the buildbot badge plugin doesn't work with buildbot-nix. | 01:26:37 |
 Roberto Abdelkader Martínez Pérez | Ah, got it, thanks for the info! | 01:34:11 |
| Roberto Abdelkader Martínez Pérez | Sorry to ask again, but I’d like to enable Mergify for my repository and I'm not sure if it's already enabled organization-wide. Do I just need to add a .mergify.yml file to the root of my repo, or do the admins need to perform any additional setup? | 02:19:32 |
| zowoq | Only needs to be approved by an admin, it doesn't require any additional setup. We can't enable it org wide as it adds status checks to every repo. | 02:28:06 |
| Roberto Abdelkader Martínez Pérez | zowoq: Could you please enable Mergify for my repository autofirma-nix? Thanks! | 02:36:01 |
| zowoq | Done. | 02:37:40 |
| Roberto Abdelkader Martínez Pérez | 
Download image.png | 03:04:08 |
| Roberto Abdelkader Martínez Pérez | zowoq: Thanks for enabling Mergify. However, Merge Queue and Workflow Automation are still disabled (see attached screenshot). Could you please enable both? | 03:04:33 |
| zowoq | Enabled. Didn't know those were options and that they aren't the default. | 04:12:01 |
| Roberto Abdelkader Martínez Pérez | Thank you! | 10:50:57 |
 SomeoneSerge (back on matrix) | Yes, although I'm now reflecting whether runtime tests (which we need the GPU instance for) should be the first priority if the goal is to ensure stability of GPU-accelerated software.
Now that there's a community-funded hydra we can be sure to observe build failures retrospectively, and the public substituter helps with iteration times - it's a big difference compared to the previous state of affairs.
Adding the GPU instance, while sounds very cool, would further increase visibility but only for discovering breakages that already happened.
Arguably, we'd get a much bigger impact by focusing on integration with the forge now.
There are two ways we could integrate with the forge: channel-blocking and OfBorg-like.
The former is mostly about working hours: we maintain our own channel, or we enhance the logic that advances the channels so that instead of being triggered by one jobset in the official hydra it could also get a report from an external source, namely the community hydra.
The latter, like runtime tests, is about resources: we'd need a CI that can react to on-push events in Nixpkgs to evaluate and build stuff with {cuda,rocm}Support, and we'd need a github action to fetch the report. We don't even need to block PRs, we just need a linting feature that would inform authors that their change also affects the GPU variants of nixpkgs and that they could maybe ping the responsible team | 14:53:46 |
| SomeoneSerge (back on matrix) | I imagine that on-push jobs would be a lot more pressure, but as long as we can reasonably argue that this is the right platform to build this kind of CI I think there are a few more sources we can attract to the opencollective | 14:59:23 |
|  connor (burnt/out) (UTC-8) joined the room. | 15:32:46 |
|  @luxzi:matrix.org changed their display name from luxzi (they/she) to luxzi (she/they). | 20:01:16 |
