 | Nix Milan | 116 Members |
| https://milano.nix.pizza/ | 9 Servers |
| Nix Milan | 116 Members |
| https://milano.nix.pizza/ | 9 Servers |
| Sender | Message | Time |
|---|---|---|
| 18 Mar 2026 | ||
 gecko | Ah che bello, ora ho woodpecker-ci attacato a GitHub e che autoscala gli agenti su hetzner su macchine badass. Also atticd. Son un bimbo felice ora. | 21:38:08 |
| 19 Mar 2026 | ||
 Andrea Ciceri | sono curioso di sapere meglio come lo hai implementato, ho fatto molti esperimenti analoghi. | 11:21:56 |
| gecko | Ho messo woodpecker-server sul mio server insieme all'autoscaler configurato per tirare su istanze sul cloud di Hetzner on demand (default 0 agenti). Ho installato l'app GitHub così ho i pallini verdi sui commit. Sullo stesso server ho messo atticd usando come backing storage un bucket S3 di Hetzner e poi mi creo grossomodo una cache per progetto. Nella CI metto come segreto un token di GitHub (che uso per ghcr, il container registry di GitHub) e il token per poter pullare e pushare sulla cache atticd. Non ho un forge (Gitea, Gitlab o simili) perché mi va bene usare GitHub. Non ho un container registry perché i container devo usarli in giro per il mondo e la mia speranza è che ghcr abbia una CDN fatta benino. C'è qualcosa in particolare che ti interessa? | 15:15:01 |
| 20 Mar 2026 | ||
| Andrea Ciceri | I vari repo sono tutti flake, giusto? E la CI dei progetti e' semplicemente buildare tutti gli output? Ogni job (triggerato da push o eventi simili su GitHub suppongo) crea una istanza su hetnzer nel senso di un host cloud (una vps proprio) con su nix che esegue un comando per buildare i vari output quindi? Quindi 1 job = 1 comando che builda tutti gli output? Chiedo perche' in passato facevo una cosa simile usando nix-fast-build (tra l'altro supporta attic nativamente) che in output ti da un json con lo stato (build fallita o meno) per ogni output del flake, e poi partendo da quel json popolavo i vari checks di GitHub (le varie spunte verdi di fianco al commit, una per ogni output).Il problema e' nix-fast-build loggava tutto assieme e non si capiva niente quando qualcosa falliva, quindi poi ho deciso di creare un job per ogni output del flake ed eseguirli in parallelo sulla stessa macchina (stesso nix store e demone) cosi' da non avere il rischio che la stessa cosa venga buildata due volte (nix ti dice tipo "waiting for lock blah blah" e aspetta che la stessa derivazione venga buildata in un altro job), almeno cosi' ho i log separati per output. Anche questa soluzione non mi soddisfa appieno pero'.Comunque parlando di cache ho appena scoperto questa: https://github.com/Mic92/niks3 Altra cosa che ho fatto (altro ambito qui) e' stata decidere di usare un singolo server bare metal corazzato di hetzner invece, non scala come soluzione ma avere un unico store sull'ssd condiviso tra tutti i repo dell'organizzazione velocizzava parecchio le build. Se uno ha clienti diversi e non vuole "mischiare gli store" non va bene come soluzione poi. | 09:43:35 |
| gecko | Francamente io tendo a non usare le feature della CI. Faccio uno scriptone che posso eventualmente migrare ad altri sistemi di CI. Per ora listo alcuni package del flake che mi interessano e li buildo. Il mio goal in realtà è produrre e pushare immagini di container, per cui la cache mi serve più che altro come cosa privata della CI. Su Hetzner ti tira su una VM, sì. La VM runna una ubuntu che runna l'agente di woodpecker. Poi quello spawna un'immagine in un container che gli dico io ( nix:latest tipo).Per il check, se exit code è 1, viene verde. Non ho investigato robe più sofisticate. | 11:36:58 |
| gecko | * Francamente io tendo a non usare le feature della CI. Faccio uno scriptone che posso eventualmente migrare ad altri sistemi di CI. Per ora listo alcuni package del flake che mi interessano e li buildo. Il mio goal in realtà è produrre e pushare immagini di container, per cui la cache mi serve più che altro come cosa privata della CI. Su Hetzner ti tira su una VM, sì. La VM runna una ubuntu che runna l'agente di woodpecker. Poi quello spawna un'immagine in un container che gli dico io ( nix:latest tipo).Per il check, se exit code è 0, viene verde. Non ho investigato robe più sofisticate. | 13:27:45 |
| Andrea Ciceri | Ovviamente ognuno ha le sue esigenze e scende ai propri compromessi ma secondo me una cosa molta ganza di nix e' che la CI puo' essere super generalista e agnostica, nel senso di qualcosa che prende e builda ignorantemente gli output del flake (o attrset nel default.nix) producendo "checks CI" (nell'accezione alla GitHub) con i log per ogni output. Quindi a chi lavora sul repo non gliene frega niente di creare e lavorare su vari file yaml o script, semplicemente definisce derivazioni in output. Inoltre cosi' hai anche completamente riproducilita' di quello che avviene in CI localmente, che e' una cosa abbastanza rognosa di solito (a me capita di fare duemila commit "CI: please work" continuamente amendando)Poi a volte in CI uno vuole avere side effects, quindi questo modello si rompe. TIpo Hercules CI usa gli effects che sembrano derivazioni ma non sono sandboxate e hanno accesso a segreti configurati a livello di runner (buildbot-nix li supporta quindi potrebbe diventare una sorta di standard). Altrimenti uno potrebbe decidere di usare le impure derivations. | 15:44:23 |
| gecko | Ci penso, ma qui devo pushare dei container. Quella logica in qualche modo la devo encodare. Non voglio solo buildare derivazioni e cacharle, almeno in questo caso. | 16:51:16 |
 Marco Turchetto | Hydra fa una cosa carina, tagghi una derivation come da eseguire, e hydra la builda e poi la esegue. Chiaramente l'ambiente e i segreti disponibili sono affari tuoi. | 17:09:45 |
| Marco Turchetto | * Hydra fa una cosa carina, pero' la fa male. Tagghi una derivation come da eseguire, e hydra la builda e poi la esegue. Chiaramente l'ambiente e i segreti disponibili sono affari tuoi. | 17:10:01 |
| Marco Turchetto | Manca sempre un modo per descrivere i segreti e i permessi di esecuzione di queste derivation speciali, e li secondo me non e' compito di nix farlo. | 17:13:35 |
| 22 Mar 2026 | ||
 Nonno Felice | Credo che alla fine userò questo, ho visto il video del tizio che l'ha creato in cui fa un'overview di tutto e la velocità di upload alla fine è quello che è più importante per me | 10:07:55 |
| gecko | Sigh, tutto il casino per tirare su la CI su VM cloud per poi rendermi conto che non supportavano KVM, quindi non posso prepararci le immagini di Windows `:( | 11:45:48 |
| gecko | * Sigh, tutto il casino per tirare su la CI su VM cloud per poi rendermi conto che non supportavano KVM, quindi non posso prepararci le immagini di Windows :( | 11:45:50 |
| Marco Turchetto |  Download image.jpeg | 11:47:19 |
| Marco Turchetto | At work avevamo adibito un laptop come runner della CI con KVM, funzionava meglio delle EC2 | 11:48:29 |
| Marco Turchetto | Poi abbiamo comprato una workstation tower, sempre accesa in ufficio | 11:49:08 |
 Matteo Joliveau | Runnare su ferro economico è estremamente sottovalutato dalle aziende, specialmente per robe che non necessitano di HA come runner | 15:43:39 |
| 29 Feb 2024 | ||
 @admin:nixos.org changed the history visibility to "world_readable" from "shared". | 12:19:16 | |
 NixOS Moderation Bot joined the room. | 12:19:31 | |
| @admin:nixos.orgchanged room power levels. | 12:20:33 | |
| @admin:nixos.org left the room. | 12:20:52 | |
 fgaz joined the room. | 15:24:24 | |
| 1 Mar 2024 | ||
 aciceri | Questa room ha ora come alias principale #milan:nixos.org ora. E siamo nello space di NixOS! | 11:39:05 |
| aciceri | * Questa room ha ora come alias principale #milan:nixos.org. E siamo nello space di NixOS! | 13:29:32 |
| 2 Mar 2024 | ||
| Matteo Joliveau joined the room. | 09:58:50 | |
| Matteo Joliveau | 👋 | 09:58:29 |
| Matteo Joliveau changed their profile picture. | 09:58:51 | |
| aciceri | In reply to @telegram_25591608:t2bot.iobenvenuto | 15:35:50 |
| Matteo Joliveau | In reply to @aciceri:nixos.devthx | 15:55:41 |