Lo sporco lavoro del CI/CD e DevOps

Ora racconto una storia. Beh, la faccio breve, si è fatta una certa.

 

Da quando c’è bisogno di rilasciare il software in tempo reale sono stati scritti diversi software di supporto per fare lo sporco lavoro di: eseguire test, impacchettare, distribuire i pacchetti nei vari server di destinazioni.

Uno di questi è Jenkins, scritto in Groovy che è un linguaggio funzionale che compila per JVM.

A marzo dello scorso anno ho visto una presentazione di un tipo delle RedHat che usava appunto Jenkins e Gogs (repo a la github minimale). Ovviamente siccome dove lavoro siamo all’età della pietra per quanto riguarda il Continuous Integration e Delivery, ho deciso che dovevo implementare questo.

Così è da inizio gennaio che tra influenza e maldistomaco ho messo su Jenkins facendolo parlare con gogs (già in uso da quasi un mese) … cioè in realtà è gogs che manda un messaggio a Jenkins quando gli arriva un push.

Per rendere la cosa più stagna ho installato gogs e jenkins in propri dockers e lo ip è indicato staticamente e numericamente perché l’interfaccia bridge di default non prevede la risoluzione per nome (mentre definendo una rete specifica magicamente dovrebbero essere risolti gli indirizzi col nome o id dell’immagine, ma sono cose che correggerò in futuro, forse)

Bene o non bene, fino a quando lunedì decido che anche l’applicazione electron che sto scrivendo deve fare il build in automatico, e sta volta arrivano i guai.

1. Jenkins esegue il build in un docker che va a creare subito dopo aver scaricato il repo (e sì, basta passare /var/run/docker.sock come volume al docker dove gira Jenkins, e il client all’interno del docker Jenkins va a comunicare col demone docker dell’host: trovo che sia una figata).

2. Electron non gli sta mica bene che usi un docker minimale tipo alpine. Questo è semplice c’è da usare electronuserland/builder:wine

3. devo sbatterci un po’ perché in un primo momento provo ad usare babel 7.xx, che è in beta, e quindi modifico .babelrc, e poi altri file che fanno riferimento a babel, ma viene fuori che webpack di lavorare con babel 7 non ne vuole sapere quindi torno indietro a 6.23, che è comunque ok, ma come mi passa per la testa, eccetera. Poi npm install non funziona e lamenta qualcosa di incomprensibile (non trova il modulo file, flow-typed? ma che vai cercando??) e trovo https://github.com/react-boilerplate/react-boilerplate/issues/1278#issuecomment-281121561 “One of the things that can cause this bug is adding packages to the wrong dependency section. For instance yarn add gulp will add it to dependencies instead of devDependencies”
… e poi? poi c’è che vuole pubblicare chissadove il pacchetto debian, che non so neanche perché lo sto facendo. e devo aggiungere –publish never
E siamo a mercoledì. In realtà per via del fuso siamo a giovedì … fuso? sì.