~/magostinelli - forgejo

Nuovo sito - Parte 2

Unknown — Sat, 20 Jun 2026 00:00:00 +0000

Vi invito a leggere la prima parte</a> se ancora non lo avete fatto.
Nel frattempo ho continuato a lavorare su altre funzionalità, che vi presenterò adesso.

Eravamo rimasti su Zola</a> che vi ricordo essere un motore per creare siti statici, dove gli articoli (o pagine) vengono scritti in linguaggio Markdown e attraverso un unico binario eseguibile</a> vengono trasformati in pagine HTML.
Innanzitutto la prima cosa che mi è piaciuta di Zola è che si tratta di un solo eseguibile da installare, e quindi molto semplice da gestire. La seconda cosa è stato l'uso di Markdown come linguaggio di scrittura, e la terza il supporto a molti temi, grazie ai quali personalizzare e diversificare il proprio sito.
Dato che il sito generato è statico, è per sua definizione sicuro, dimenticate le vulnerabilità di WordPress e software simili.

</a> Versionamento e automatismi</h3>
Torniamo un attimo alle pagine del sito scritte in Markdown. Ho deciso di versionarle con Git sulla mia istanza selfhosted di Forgejo e usare le sue actions per compilare ed effettuare il deploy automatico del sito attraverso le actions. Ho anche un'istanza di test del sito, in modo da poter visualizzare e testare prima le nuove modifiche.
La pipeline di build e deploy ha superato le 200 righe! Succede quando mi faccio prendere la mano dalle novità e voglio sempre introdurre nuove funzionalità alla ricerca della perfezione (che non arriverà mai, c'è sempre qualcosa da migliorare).
</a> Limiti</h3>
Dopo aver elogiato i vantaggi di Zola, arriviamo ai suoi limiti, che sono intrinsechi a tutti i generatori di pagine statiche. Scegliendo questa soluzione, dovremmo teoricamente rinunciare a commenti e statistiche sul sito. Ma ecco come ho girato intorno al problema: ho aggiunto queste funzionalità tramite JavaScript eseguito lato client.
Entrambi i software che seguono sono stati configurati per rispondere solo in locale (127.0.0.1) perché ho configurato il mio webserver in modo da agire come reverse proxy.
Ho usato il software Isso</a>, che ho installato con docker-compose</code>:
root@tex:/opt/isso# cat docker-compose.yml services: isso: image: ghcr.io/isso-comments/isso:release ports: - "127.0.0.1:8085:8080" volumes: - ./data/config:/config - ./data/db:/db </code></pre> Ho scelto Isso perché non ha pubblicità, non traccia gli utenti ed è leggero.
Ho usato un software molto semplice, di nome GoatCounter</a>. L'interfaccia è molto spartana, ma per quelle che sono le mie esigenze va più che bene! Alla fine a me interessa vedere quali sono gli argomenti più seguiti o le pagine più lette, non ho bisogno di funzionalità avanzate, ma soprattutto perché GoatCounter rispetta la privacy, non richiede banner dei cookie invasivi ed è infinitamente più leggero di Matomo.
Installato con docker-compose, semplicemente così:
services: goatcounter: image: arp242/goatcounter ports: - "127.0.0.1:8086:8080" volumes: - ./data:/home/goatcounter/goatcounter-data environment: - GOATCOUNTER_TLS=http - GOATCOUNTER_SMTP=smtps://${SMTP_USER}:${SMTP_PASS}@${SMTP_HOST} - GOATCOUNTER_EMAIL-FROM=${GC_EMAIL_FROM} - GOATCOUNTER_ERRORS=mailto:${GC_ERRORS} - GOATCOUNTER_DB=sqlite+./goatcounter-data/db.sqlite3 </code></pre> E un banale file .env</code> come questo:
# Credenziali SMTP SMTP_USER=me@email.com SMTP_PASS=VerySecure SMTP_HOST=smtp.mysite.com:465 # Configurazione GoatCounter GC_EMAIL_FROM=me@email.com GC_ERRORS=me@email.com </code></pre> Ho configurato SMTP perché ricevo una notifica per ogni nuovo commento, quindi se avete letto fino a qui, adesso dovete per forza lasciarmene uno sotto questo articolo!
</a> Anticipazioni</h2>
Nella terza (e ultima) parte di questa serie approfondirò:

Galleria Immagini: come ho implementato le immagini che trovate sul sito? (le immagini vengono pescate da Nextcloud!)</li>
Form della pagina contatti: sì, un form in un sito statico</li>
Immagine Docker custom: la mia immagine Docker personalizzata che uso per compilare il sito nella CI/CD di Forgejo</li> </ol>
</code></pre>

Forgejo Runner Unknown — Sun, 28 Dec 2025 00:00:00 +0000 </a> Che cos'è Forgejo Runner</h2> Se usi #forgejo e desideri automatizzare i processi di sviluppo, Forgejo Runner è uno strumento che non puoi perderti. Se, invece, non sai cos'è #forgejo, clicca sulla parola e leggi l'articolo che avevo pubblicato qui sul blog. </a> Definizione</h2> Forgejo Runner è un sistema di automazione che esegue compiti in background quando accadono determinati eventi nel tuo repository. In altre parole, ti permette di automatizzare il flusso di lavoro del tuo progetto senza intervento manuale. </a> Come funziona</h2> Quando effettui un push, apri una pull request, o altro ancora, Forgejo Runner può automaticamente: Eseguire test del codice</li> Compilare il progetto</li> Distribuire l'applicazione</li> Generare documentazione</li> Eseguire controlli di qualità</li> </ul> Il tutto accade in automatico dietro le quinte, senza che tu debba fare nulla. </a> Perché è utile</h2> Immagina di dover controllare manualmente che il tuo codice non abbia errori ogni volta che lo carichi. Sarebbe noioso, vero? Forgejo Runner elimina questo problema. Puoi definire una volta le regole che desideri applicare, e il sistema le seguirà automaticamente per ogni nuovo commit. Questo significa codice più pulito, meno errori e molto meno lavoro manuale. </a> Un esempio pratico</h2> Vogliamo che che ogni volta che qualcuno contribuisce al progetto, il codice venga testato automaticamente. Con Forgejo Runner, puoi impostare una regola che dice: "Quando ricevi un nuovo push, esegui i test". Se i test falliscono, riceverai una notifica. Se passano, tutto procede normalmente. </a> Forgejo Runner e Docker</h2> Una delle migliori pratiche è eseguire i compiti dentro container Docker. Questo è diventato, ormai, lo standard di fatto nel settore. Utilizzare Docker con Forgejo Runner offre numerosi vantaggi: isolamento completo tra i vari compiti (un test non interferisce con un altro), ambienti di esecuzione riproducibili e coerenti, e la certezza che il codice funzionerà allo stesso modo sia sulla tua macchina che sui server di produzione. In pratica, invece di eseguire i compiti direttamente sul sistema operativo host, Forgejo Runner li avvia all'interno di container Docker preconfigurati. Questo significa che puoi definire esattamente quali dipendenze, librerie e versioni delle applicazioni servono per i tuoi test o per la compilazione, senza doverti preoccupare di conflitti con altre configurazioni. </a> Pratica</h2> Premesso quanto detto sopra, eseguire il nostro workflow in un container docker ci permette di avere un alto livello di sicurezza, sopratutto in un server condiviso. Per rendere semplice l'esecuzione, ho pensato di realizzare un file docker compose (e un .env) con tutto il necessario: registrazione, aggiornamento automatico e avvio automatico. Trovate il codice di questo mini progetto qui (ovviemente sempre ospitato su forgejo): https://forgejo.it/magostinelli/forgejo-runner-docker </a> Configurazione</h3> Per prima cosa assicuratevi che la vostra istanza di forgejo abbia le action abilitate (altrimenti non vedrete la voce del menù). Per poter aggiungere un runner al vostro workflow, sarà necessario generare un token. Andate su Forgejo Admin Panel → Runner (o Runners) (in alternativa potete aggiungere il runner al singolo progetto git) Seguite le istruzioni presenti nel link sopra, compilando le varibili (file .env) con i vostri parametri, e lanciate (docker compose up) il vostro container. Se tutto ha funzionato, vedrete il runner attivo nella schermata web di forgejo. Adesso passiamo ad utilizzarlo. </a> Utilizzo</h3> Vedi documentazione al link: https://forgejo.org/docs/latest/user/actions/overview/ Crea il file forgejo/workflows/test.yml </a> Esempio di workflow</h4> forgejo/workflows/test.yml name: Test Workflow run-name: Eseguito da ${{ forgejo.actor }} on: [push] jobs: test-job: # Qui specifichi su quale runner deve girare il job # Deve corrispondere a una delle etichette in RUNNER_LABELS runs-on: docker steps: - name: Stampa un messaggio run: echo "Ciao mondo! Questo job sta girando sul mio runner Docker." - name: Mostra informazioni sul sistema run: | echo "Utente corrente: $(whoami)" echo "Directory corrente: $(pwd)" uname -a </code></pre> </a> Conclusione</h2> Forgejo Runner è essenzialmente un assistente che automatizza i compiti ripetitivi nel tuo flusso di lavoro di sviluppo. È perfetto se desideri risparmiare tempo, ridurre errori umani e mantenere la qualità del tuo codice consistente nel tempo. Se stai già usando Forgejo, integrarvi Forgejo Runner (preferibilmente con Docker) potrebbe aiutarti ad incrementare la produttività grazie alle automazioni. Mastodon: toot da command line Unknown — Sat, 01 Nov 2025 00:00:00 +0000 Non tutti sanno che... E' semplicissimo fare un post (toot) sul proprio profilo #mastodon con un semplice comando, ad esempio utilizzando #curl. Vediamo come fare. </a> Abilitazione e creazione token</h2> Accedere, con il vostro account, al l'istanza mastodon di riferimento.</li> Andare su Preferenze (menù a destra)</li> Andare su Sviluppo (menù a sinistra)</li> Fare click su Nuova applòicazione</li> Compilare tutti i campi e concedere almeno i permessi di scrittura post.</li> Salvare in un luogo sicuro (password manager) quanto generato.</li> </ol> </a> Comando curl di esempio</h2> curl -s -X POST https://mastodon.uno/api/v1/statuses \ -H "Authorization: Bearer TOKEN_DI_ACCESSO" \ -d "status=Ciao mondo" \ -d "visibility=public" \ </code></pre> </a> Semplice Script di invio</h3> A questo punto possiamo farci un semplice script che prende in input, come parametro, del testo e lo invia per noi. cat toot.sh #!/bin/bash # Verifica che sia stato passato almeno un argomento if [ -z "$1" ]; then echo "Errore: devi passare il testo del toot come parametro." echo "Uso: $0 \"Testo del toot\"" exit 1 fi # Salva il parametro in una variabile TOOT="$1" # Esegui la richiesta POST curl -s -X POST https://mastodon.uno/api/v1/statuses \ -H "Authorization: Bearer TOKEN_DI_ACCESSO" \ -d "status=$TOOT" \ -d "visibility=public" \ -H "Authorization: Bearer TOKEN_DI_ACCESSO" \ | jq '.uri' </code></pre> Ho inserito #jq in fondo con un filtro (che possiamo modificare a nostro piacimento), perché l'output in formato json è abbastanza prolisso </a> Perché?</h2> A parte che è bello fare il nerd è usare #mastodon da command line, ma la cosa può essere molto utile se la usiamo in abbinata ad altre azioni/comandi. Pensiamo ad esempio ad un integraszione con #forgejo, ad esempio potremmo fare un post (tramite #webook) al termine del nostro workflow. Un altro esempio è il collegare l'account ad un servizio di monitoraggio come #uptimekuma in questo modo si avrà una pagina che indica ai follower lo stato dei nostri servizi. Oppure usarlo al termine di un nostro script che preleva i prossimi appuntamenti da un caledario ics. Insomma, potete integrare l'invio di un toot alla fine di un vostro script custom, il limite a questo punto è solo la fantasia! E voi come lo usate? Forgejo con Docker: Git self-hosted senza fronzoli Unknown — Fri, 11 Jul 2025 00:00:00 +0000 Da tempo utilizzo Git per gestire i miei progetti personali, sia software che di configurazione. Per anni mi sono affidato al pc di qualcunaltro (es: Gitlab o GitHub), ma la dipendenza da un servizio centralizzato, per quanto comodo, inizia a starmi stretta. Così ho cercato una soluzione più allineata alla mia filosofia: Forgejo, un fork comunitario di Gitea, leggero e facilmente self-hostabile. </a> Perché Forgejo</h2> Forgejo nasce da una comunità che punta alla trasparenza e all’autonomia, senza il rischio che un progetto venga assorbito o piegato a logiche commerciali. La compatibilità con Gitea è totale, e i requisiti minimi lo rendono perfetto per VPS o server casalinghi. </a> Veniamo subito al dunque e facciamolo partire, cosi potremo provarlo con mano!</h2> </a> Setup con Docker</h2> Ci affidiamo a Docker Compose, cosi con un solo file di configurazione abbiamo tutto il necessario. </a> docker-compose.yaml</h3> services: forgejo: image: codeberg.org/forgejo/forgejo:latest container_name: forgejo restart: always environment: - USER_UID=1000 - USER_GID=1000 volumes: - ./data:/data - /etc/timezone:/etc/timezone:ro - /etc/localtime:/etc/localtime:ro - ./robots.txt:/data/gitea/public/robots.txt:ro expose: - "3000" networks: - forgejo_net networks: forgejo_net: driver: bridge </code></pre> </a> Reverse Proxy</h3> E' possibile usare il web server che preferiamo, come ad esempio traefik, caddy, apache o nginx, in questo articolo vedremo un esempio con quest'ultimo. Qui una configurazione base con https (via Let's Encrypt, gestito esternamente): /etc/nginx/sites-available/forgejo.conf server { listen 80; server_name git.miodominio.it; return 301 https://$host$request_uri; } server { listen 443 ssl; server_name git.miodominio.it; ssl_certificate /etc/letsencrypt/live/git.miodominio.it/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/git.miodominio.it/privkey.pem; location / { proxy_pass http://localhost:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } </code></pre> Dopo aver creato il file, attivare con: ln -s /etc/nginx/sites-available/forgejo.conf /etc/nginx/sites-enabled/ nginx -t && systemctl reload nginx </code></pre> </a> Backup automatico</h2> Il backup rappresenta un step fondamentale del nostro setup, conviene implementarne subito uno all'avvio del servizio, cosi non ce ne dimenticvheremo e terremo i nostri dati al sicuro. Ricordiamoci che qui salveremo il risultato di diverse ore di programmazione, studio e prove! I nostri dati si trovano nel volume data di cui sopra, quindi sarà sufficiente salvare il docker file e la directory data. Io consiglio di usare #borg ma potete usare il softwsre che preferite, trovo particolarmente utile aggiungere questa nuova directory alle procedure di salvataggio che sicuremante avrete già per tutto il resto. (se non le avete potete anche smettere di leggere questo blog, tornate quando ne avrete implementata una). </a> Configurazioni iniziali</h2> A questo punto, dopo l'installazione, non ci resta che accedere via web al nostro software e fare le prime configurazioni. È possibile creare utenti, organizzazioni, concedere permessi e creare tutti i repository che si desiderano. Ciascun progetto può essere impostato ad accesso privatp o pubblico. In questo modo sarà semplicissimo collaborare in più persone allo stesso progetto, tenendo traccia delle varie modifiche. Infine è anche possibile importare direttamente altri repository git. </a> Runner e Action</h2> Forgejo, essendo un fork di Gitea, supporta un sistema di CI/CD integrato chiamato Actions, simile a GitHub Actions, e permette di eseguire job di build o deploy tramite runner personalizzati. Io stesso ne faccio uso, è uno dei motivi per cui mi sto trovando benissimo con forgejo! Ho varie configurazione a seconda del progetto ospitato, ma essenzialmente queste si occupano di effettuare il "deploy" del codice, cioé copiano a destinazione (server di sviluppo o di produzione a seconda dei casi), il codice modificato, cosi che sia pronto all'uso. In questo modo, grazie alla history di git, sarà sempre possibile tornare indietro, nonché tenere traccia delle modifiche nel tempo. </a> Come funziona</h3> Le Actions sono definite da file YAML nei repository (.forgejo/workflows/), e possono contenere job con step eseguiti su runner registrati. I runner sono agent installati su macchine (stessa VPS o remote), che si collegano al server Forgejo e attendono job da eseguire. Una volta definita la condizione scatenante (es: commit su ramo main, rilascio di una nuova versione, ecc) partirà il worksflow che abbiamo definito, con la possibilità di verificarne lo stato di esecuzione in tempo reale. Infine è anche possibile andare a vedere i log delle esecuzione precedenti. All'interno di una action si possono usare #secret e #variabili, in modo da poter riusare il codice della action e allo stesso tempo mantenere al sicuro le credenziali. </a> Setup runner base</h3> Vediamo come creare un nuovo runner, passo passo: export RUNNER_VERSION=$(curl -X 'GET' https://data.forgejo.org/api/v1/repos/forgejo/runner/releases/latest | jq .name -r | cut -c 2-) wget -O forgejo-runner https://code.forgejo.org/forgejo/runner/releases/download/v${RUNNER_VERSION}/forgejo-runner-${RUNNER_VERSION}-linux-amd64 chmod +x forgejo-runner sudo mv forgejo-runner /usr/local/bin/forgejo-runner sudo useradd -m -s /bin/bash forgejo-runner sudo usermod -aG docker forgejo-runner </code></pre> Rechiamoci sull'interfaccia web di Forgejo: Forgejo > Repository > Settings > Actions > Runners > "Generate new token" sudo -i -u forgejo-runner forgejo-runner register </code></pre> </a> Avvio automatico del runner</h4> Io ho usato uno script systemd per l'avvio automatico, ve lo riporto di seguito sudo echo " [Unit] Description=Forgejo Act Runner After=network.target docker.service Requires=docker.service [Service] User=forgejo-runner Group=forgejo-runner ExecStart=/usr/local/bin/forgejo-runner daemon Restart=always WorkingDirectory=/home/forgejo-runner [Install] WantedBy=multi-user.target" > /etc/systemd/system/forgejo-runner.service sudo systemctl daemon-reload sudo systemctl enable forgejo-runner sudo systemctl start forgejo-runner systemctl status forgejo-runner </code></pre> </a> Vantaggi in breve</h2> Repository del proprio codice, diviso come si preferisce: singoli progetti, organizzazioni, ecc.</li> Possibilità di creare utenti per collaboratori/amici con controllo sugli accessi/permessi.</li> Automatizzo test, build, deploy senza dipendere da servizi esterni.</li> Nessuna dipendenza da fornitori terzi e nessun limite di spazio, esecuzioni, personalizzazioni.</li> Versionamento del codice, e nel caso di ci/cd garanzia di riproducibilità</li> Pocchissime risorse necessarie lato server</li> Vuoi mettere quanto è figo avere il proprio servizio di versionamento?</li> </ul> </a> Uso quotidiano</h2> Forgejo supporta #git via #ssh, Web UI e #webhooks. Ho configurato alcuni repository con CI locale usando le Actions e i runner integrati. L’interfaccia è leggera e pulita, senza funzionalità inutili. </a> Conclusioni</h2> Forgejo è una soluzione Git solida, coerente con un approccio decentralizzato. Semplice da gestire, veloce da installare, e adatta anche per chi – come me – preferisce sapere dove stanno i propri dati. Per ora lo utilizzo solo per progetti personali, ma potrei iniziare a usarlo anche per collaborazioni future. Non vi resta che provarlo, fatemi sapere le vostre impressioni con un commento nel #fediverso su questo articolo.

~/magostinelli - forgejo

Nuovo sito - Parte 2

Forgejo Runner

</span></a> Come funziona</h2> Quando effettui un push, apri una pull request, o altro ancora, Forgejo Runner può automaticamente:</p> Eseguire test del codice</li> Compilare il progetto</li> Distribuire l'applicazione</li> Generare documentazione</li>

Mastodon: toot da command line

Forgejo con Docker: Git self-hosted senza fronzoli