Esiste già una discussione sul tema che ti interessa, o su un tema simile?
Cosa
Il processo di build in produzione fallisce frequentemente durante la generazione delle immagini Open Graph (OG) quando la cache di GitHub Actions non è disponibile. Il plugin gatsby-plugin-satorare va in errore su alcune immagini in modo apparentemente casuale, bloccando completamente il deploy.
Inoltre, la generazione delle immagini AVIF tramite Sharp sta diventando eccessivamente onerosa in termini di tempo e risorse computazionali.
Perché
gatsby-plugin-satorare:
- La repository del plugin è archiviata (non più mantenuta)
- Genera errori di tipo fetch failed su immagini (credo casuali) durante il build
- Non ha opzioni per configurare retry, timeout o concorrenza, non so se rispetta la concurrency sharp di gatsby del workflow
- Sembra il motivo che blocca l'intero deploy quando fallisce la build di deploy
Ottimizzazione Sharp/AVIF:
- La conversione AVIF delle numerose immagini richiede ormai troppo tempo e risorse CPU
- Aumenta significativamente i tempi di build (da ~5-10 min a 30+ min)
- Non sempre necessaria per il delivery effettivo?
Contesto
Errore tipico:
error Can't load image ***images/[...]: fetch failed
error "gatsby-plugin-satorare" threw an error while running the onPostBootstrap lifecycle:
Image size cannot be determined. Please provide the width and height of the image.
Si verifica principalmente quando la cache di GitHub Actions è assente o invalidata.
Altro
Alcune idee:
Opzione A: Migrare a plugin alternativo
Valutare migrazione a gatsby-plugin-component-to-image che sembra più mantenuto. Cambierebbe qualcosa?
Opzione B: pre-generazione con GitHub Action dedicata
Creare un'action separata che genera le OG image — e/o forse tutte le immagini ottimizzate non solo quelle og? — in un job dedicato e le committa nella repository (in public/static/ o folder dedicato). Rigenera quando necessario (pagine modificate, nuove pagine, immagini SEO aggiornate nei file YAML). Forse la logica di detection è difficile da fare. Così come quella del link da caricare nelle pagine...
Opzione C: Ottimizzare Sharp/AVIF
Disabilitare AVIF in produzione (mantenere solo WebP + fallback). Oppure generare AVIF solo per immagini hero/above-the-fold. Configurazione da rivedere in gatsby-config.js. Diminuendo tempo e risorse di build notevolmente potrebbe semplificare i processi anche per satorare?
In ogni caso da ristudiare a modo il meccanismo attuale per entrambe le cose prima di procedere.
cc @astagi
Esiste già una discussione sul tema che ti interessa, o su un tema simile?
Cosa
Il processo di build in produzione fallisce frequentemente durante la generazione delle immagini Open Graph (OG) quando la cache di GitHub Actions non è disponibile. Il plugin gatsby-plugin-satorare va in errore su alcune immagini in modo apparentemente casuale, bloccando completamente il deploy.
Inoltre, la generazione delle immagini AVIF tramite Sharp sta diventando eccessivamente onerosa in termini di tempo e risorse computazionali.
Perché
gatsby-plugin-satorare:
Ottimizzazione Sharp/AVIF:
Contesto
Errore tipico:
Si verifica principalmente quando la cache di GitHub Actions è assente o invalidata.
Altro
Alcune idee:
Opzione A: Migrare a plugin alternativo
Valutare migrazione a gatsby-plugin-component-to-image che sembra più mantenuto. Cambierebbe qualcosa?
Opzione B: pre-generazione con GitHub Action dedicata
Creare un'action separata che genera le OG image — e/o forse tutte le immagini ottimizzate non solo quelle og? — in un job dedicato e le committa nella repository (in public/static/ o folder dedicato). Rigenera quando necessario (pagine modificate, nuove pagine, immagini SEO aggiornate nei file YAML). Forse la logica di detection è difficile da fare. Così come quella del link da caricare nelle pagine...
Opzione C: Ottimizzare Sharp/AVIF
Disabilitare AVIF in produzione (mantenere solo WebP + fallback). Oppure generare AVIF solo per immagini hero/above-the-fold. Configurazione da rivedere in gatsby-config.js. Diminuendo tempo e risorse di build notevolmente potrebbe semplificare i processi anche per satorare?
In ogni caso da ristudiare a modo il meccanismo attuale per entrambe le cose prima di procedere.
cc @astagi