Test automatici che la costruzione dell'immagine docker porti a un container funzionante #304

Open
opened 2024-10-23 13:12:01 +00:00 by amreo · 2 comments
Collaborator

Per evitare che succeda di nuova qualcosa di simile a #302 sarebbe bello che CI controllasse che i container prodotti portano a una versione del sito probabilmente funzionante

Per evitare che succeda di nuova qualcosa di simile a https://git.libreschool.org/BgLUG/bglug.it/pulls/302 sarebbe bello che CI controllasse che i container prodotti portano a una versione del sito probabilmente funzionante
omarl added this to the Nuovo sito: CODICE HUGO project 2024-10-23 16:31:09 +00:00
Owner

Un po' di roba già c'è.

Considera che in realtà abbiamo 2 componenti:

  • il container docker
  • il sito hugo

Se si rompe il container, al momento non te ne accorgi in fase di build. O meglio, deve rompersi "strano" perchè se sbagli tanto la config di nginx, questa roba lo becca e non builda.

Dockerfile Line 15 in dd23a488b4
RUN nginx -t

Se si rompe hugo (tipo link a pagina inesistente, immagine mancante...), il CI muore male e te ne accorgi.

Un po' di roba già c'è. Considera che in realtà abbiamo 2 componenti: - il container docker - il sito hugo Se si rompe il container, al momento non te ne accorgi in fase di build. O meglio, deve rompersi "strano" perchè se sbagli tanto la config di nginx, questa roba lo becca e non builda. https://git.libreschool.org/BgLUG/bglug.it/src/commit/dd23a488b48cae21178feca1b00acb95e3fa319d/Dockerfile#L15 Se si rompe hugo (tipo link a pagina inesistente, immagine mancante...), il CI muore male e te ne accorgi.
Owner

Guardiamo quello che è successo:

63e785af7d definisce un tipo mime per il calendario.
In teoria.
In pratica scopa via tutti i tipi mime conosciuti da nginx tranne il calendario (non c'è molta documentazione a riguardo).
Risultato: ogni file (tranne i calendari) viene servito con content-type: application/octet-stream, cioè un download forzato.
Il test con curl funziona lo stesso, ti viene restituita la pagina che vuoi, quindi quando ho controllato che il resto andasse (ho fatto due curl a caso), tutto sembrava andare.
Ma nel browser no, ogni url finiva in un download.

Per fixare, ho aggiunto di caricare i tipi mime di default oltre a quello aggiuntivo: 1b64787dd5

Per beccare questa cosa devi fare un test che contolli gli header di ogni pagina generata. Mi sembra un pelo eccessivo.

Guardiamo quello che è successo: https://git.libreschool.org/BgLUG/bglug.it/commit/63e785af7d91bc432d5b8d996446395fbcbeab38 definisce un tipo mime per il calendario. In teoria. In pratica scopa via tutti i tipi mime conosciuti da nginx tranne il calendario (non c'è molta documentazione a riguardo). Risultato: ogni file (tranne i calendari) viene servito con `content-type: application/octet-stream`, cioè un download forzato. Il test con `curl` funziona lo stesso, ti viene restituita la pagina che vuoi, quindi quando ho controllato che il resto andasse (ho fatto due curl a caso), tutto sembrava andare. Ma nel browser no, ogni url finiva in un download. Per fixare, ho aggiunto di caricare i tipi mime di default oltre a quello aggiuntivo: https://git.libreschool.org/BgLUG/bglug.it/commit/1b64787dd52e1a2b704d273942d265a98678a0e7 Per beccare questa cosa devi fare un test che contolli gli header di ogni pagina generata. Mi sembra un pelo eccessivo.
Sign in to join this conversation.
No description provided.