MEP19: Integrazione continua #

Stato n.

Completato

Filiali e Pull request #

Estratto n.

matplotlib potrebbe trarre vantaggio da un'integrazione continua migliore e più affidabile, sia per i test che per la creazione di installatori e documentazione.

Descrizione dettagliata #

Stato dell'arte attuale #

Test

matplotlib attualmente utilizza Travis-CI per i test automatizzati. Mentre Travis-CI dovrebbe essere elogiato per quanto fa come servizio gratuito, ha una serie di carenze:

Spesso fallisce a causa di timeout di rete durante l'installazione delle dipendenze.
Spesso fallisce per ragioni inspiegabili.
i prodotti build o test possono essere salvati solo dalla build off dei rami sul repository principale, non dalle richieste pull, quindi è spesso difficile analizzare "post mortem" cosa è andato storto. Ciò è particolarmente frustrante quando il guasto non può essere successivamente riprodotto localmente.
Non è estremamente veloce. I requisiti di cpu e memoria di matplotlib per i test sono molto più alti rispetto al progetto Python medio.
Testa solo su Ubuntu Linux e abbiamo solo un controllo minimo sulle specifiche della piattaforma. Può essere aggiornato in qualsiasi momento al di fuori del nostro controllo, causando ritardi imprevisti in momenti che potrebbero non essere convenienti nel nostro programma di rilascio.

Tra i lati positivi, l'integrazione di Travis-CI con github, che testa automaticamente tutte le richieste pull in sospeso, è eccezionale.

Costruisce

Non esiste uno sforzo centralizzato per le build binarie automatizzate per matplotlib. Tuttavia, si stanno facendo le seguenti cose disparate [Se gli autori menzionati qui potessero fornire dettagli, sarebbe fantastico!]:

@sandrotosi: compila i pacchetti Debian
@takluyver: ha automatizzato le build di Ubuntu su Launchpad
@cgohlke: crea build di Windows (non so quanto sia automatizzato)
@r-owen: crea build OS-X (non so quanto sia automatizzato)

Documentazione

La documentazione di main è ora creata da travis e caricata su https://matplotlib.org/devdocs/index.html

@NelleV, credo, genera automaticamente i documenti e li pubblica sul web per tracciare i progressi di MEP10.

Peculiarità di matplotlib #

matplotlib ha requisiti complessi che rendono i test e la creazione più faticosi rispetto a molti altri progetti Python.

Il tempo della CPU per eseguire i test è piuttosto elevato. Ci mette oltre gli account gratuiti di molti servizi CI (ad esempio ShiningPanda)
Ha un gran numero di dipendenze e testare l'intera matrice di tutte le combinazioni non è pratico. Dobbiamo essere intelligenti su quale spazio testiamo e garantiamo di supportare.

Requisiti #

Questa sezione delinea i requisiti che vorremmo avere.

Testare tutte le richieste pull collegandosi all'API GitHub, come fa Travis-CI
Test su tutte le principali piattaforme: Linux, Mac OS-X, MS Windows (in quest'ordine di priorità, in base al sondaggio degli utenti)
Conserva gli ultimi n giorni di compilazione e test dei prodotti, per agevolare il debug post-mortem.
Build binarie notturne automatizzate, in modo che gli utenti possano testare il limite senza installare un ambiente di compilazione completo.
Benchmark automatico. Sarebbe bello avere una suite di benchmark standard (separata dai test) le cui prestazioni potrebbero essere monitorate nel tempo, in diversi backend e piattaforme. Sebbene questo sia separato dalla creazione e dal test, idealmente dovrebbe essere eseguito sulla stessa infrastruttura.
Creazione e pubblicazione notturna automatizzata della documentazione (o come parte del test, per garantire che i PR non introducano bug nella documentazione). (Questo non sostituirebbe la documentazione statica per i rilasci stabili come impostazione predefinita).
I sistemi di test dovrebbero essere gestibili da più sviluppatori, in modo che nessuna singola persona diventi un collo di bottiglia. (Il design di Travis-CI lo fa bene: archiviare la configurazione della build nel repository git, piuttosto che altrove, è un ottimo design.)
Semplifica il test di una matrice ampia ma sparsa di diverse versioni delle dipendenze di matplotlib. Il sondaggio sugli utenti di matplotlib fornisce alcuni buoni dati su dove concentrare i nostri sforzi: https://docs.google.com/spreadsheets/d/1jbK0J4cIkyBNncnS-gP7pINSliNy9lI-N4JHwxlNSXE/edit
Bello da avere: un design decentralizzato in modo che quelli con piattaforme più oscure possano pubblicare i risultati della build su un dashboard centrale.

Implementazione n.

Questa parte è ancora da scrivere.

Tuttavia, idealmente, l'implementazione sarebbe un servizio di terze parti, per evitare di aggiungere l'amministrazione del sistema al nostro tempo già allungato. Poiché disponiamo di alcuni fondi donati, questo servizio potrebbe essere a pagamento se offre significativi vantaggi in termini di risparmio di tempo rispetto alle offerte gratuite.

Compatibilità con le versioni precedenti #

La compatibilità con le versioni precedenti non è una preoccupazione importante per questo deputato. Sostituiremo gli strumenti e le procedure attuali con qualcosa di migliore e getteremo via il vecchio.

Alternative #

Note sull'Hangout #

Infrastruttura CI #

Ci piace Travis e probabilmente rimarrà comunque parte del nostro arsenale. I problemi di affidabilità vengono esaminati.
Abilita i caricamenti Amazon S3 dei prodotti di test su Travis. Questo aiuterà con l'autopsia dei fallimenti (@mdboom sta esaminando questo ora).
Vogliamo la copertura del Mac. La cosa migliore è probabilmente quella di spingere Travis ad abilitarlo per il nostro progetto pagandoli per un account Pro (poiché altrimenti non consentono test sia su Linux che su Mac).
Vogliamo la copertura di Windows. Shining Panda è un'opzione lì.
Indagare sulla ricerca o sulla creazione di uno strumento che raccolga e sintetizzi i risultati dei test da una serie di fonti e lo pubblichi su GitHub utilizzando l'API GitHub. Questo può essere di uso generale per la comunità di Scipy.
Sia per Windows che per Mac, dovremmo documentare (o meglio ancora, scriptare) il processo di configurazione della macchina per una build e come creare binari e programmi di installazione. Ciò potrebbe richiedere di ottenere informazioni da Russel Owen e Christoph Gohlke. Questo è un passaggio necessario per eseguire build automatizzate, ma sarebbe utile anche per una serie di altri motivi.

Il framework di test stesso #

Dovremmo studiare i modi per farlo impiegare meno tempo
- Eliminare i test ridondanti, se possibile
- I miglioramenti generali delle prestazioni di matplotlib aiuteranno
Dovremmo coprire più cose, in particolare più backend
Dovremmo avere più unit test, meno test di integrazione, se possibile