MEP19 : Intégration Continue #

Statut #

Complété

Branches et demandes d'extraction #

Résumé #

matplotlib pourrait bénéficier d'une intégration continue meilleure et plus fiable, à la fois pour les tests et la construction des installateurs et de la documentation.

Descriptif détaillé #

État de l'art actuel #

Essai

matplotlib utilise actuellement Travis-CI pour les tests automatisés. Bien que Travis-CI doive être félicité pour tout ce qu'il fait en tant que service gratuit, il présente un certain nombre de lacunes :

  • Il échoue souvent en raison des délais d'attente du réseau lors de l'installation des dépendances.

  • Il échoue souvent pour des raisons inexplicables.

  • Les produits de construction ou de test ne peuvent être enregistrés qu'à partir de la construction de branches sur le référentiel principal, et non des demandes d'extraction, il est donc souvent difficile d'analyser "post mortem" ce qui n'a pas fonctionné. Ceci est particulièrement frustrant lorsque la panne ne peut pas être reproduite localement par la suite.

  • Ce n'est pas extrêmement rapide. Les besoins en processeur et en mémoire de matplotlib pour les tests sont beaucoup plus élevés que le projet Python moyen.

  • Il ne teste que sur Ubuntu Linux et nous n'avons qu'un contrôle minimal sur les spécificités de la plate-forme. Il peut être mis à niveau à tout moment hors de notre contrôle, ce qui entraîne des retards inattendus à des moments qui peuvent ne pas convenir à notre calendrier de publication.

Du côté positif, l'intégration de Travis-CI avec github - testant automatiquement toutes les demandes d'extraction en attente - est exceptionnelle.

Construit

Il n'y a pas d'effort centralisé pour les constructions binaires automatisées pour matplotlib. Cependant, les choses disparates suivantes sont en cours [Si les auteurs mentionnés ici pouvaient fournir des détails, ce serait formidable !] :

  • @sandrotosi : construit des packages Debian

  • @takluyver : a automatisé les versions d'Ubuntu sur Launchpad

  • @cgohlke : crée des builds Windows (je ne sais pas à quel point c'est automatisé)

  • @r-owen : crée des versions OS-X (je ne sais pas à quel point c'est automatisé)

Documentation

La documentation de main est maintenant construite par travis et téléchargée sur https://matplotlib.org/devdocs/index.html

@NelleV, je crois, génère automatiquement les documents et les publie sur le Web pour suivre les progrès du MEP10.

Particularités de matplotlib #

matplotlib a des exigences complexes qui rendent les tests et la construction plus exigeants que de nombreux autres projets Python.

  • Le temps CPU pour exécuter les tests est assez élevé. Cela nous place au-delà des comptes gratuits de nombreux services CI (par exemple ShiningPanda)

  • Il a un grand nombre de dépendances et tester la matrice complète de toutes les combinaisons n'est pas pratique. Nous devons être intelligents quant à l'espace que nous testons et garantissons de prendre en charge.

Exigences #

Cette section décrit les exigences que nous aimerions avoir.

  1. Tester toutes les demandes d'extraction en se connectant à l'API GitHub, comme le fait Travis-CI

  2. Tests sur toutes les principales plates-formes : Linux, Mac OS-X, MS Windows (dans cet ordre de priorité, basé sur une enquête auprès des utilisateurs)

  3. Conservez les n derniers jours de construction et de test des produits, pour faciliter le débogage post-mortem.

  4. Constructions binaires nocturnes automatisées, afin que les utilisateurs puissent tester la pointe de la technologie sans installer un environnement de compilation complet.

  5. Analyse comparative automatisée. Ce serait bien d'avoir une suite de benchmark standard (séparée des tests) dont les performances pourraient être suivies dans le temps, dans différents backends et plates-formes. Bien que cela soit distinct de la construction et des tests, idéalement, il fonctionnerait sur la même infrastructure.

  6. Création et publication automatisées nocturnes de la documentation (ou dans le cadre des tests, pour s'assurer que les PR n'introduisent pas de bogues dans la documentation). (Cela ne remplacerait pas la documentation statique pour les versions stables par défaut).

  7. Les systèmes de test doivent être gérables par plusieurs développeurs, afin qu'aucune personne ne devienne un goulot d'étranglement. (La conception de Travis-CI le fait bien - stocker la configuration de construction dans le référentiel git, plutôt qu'ailleurs, est une très bonne conception.)

  8. Facilitez le test d'une matrice volumineuse mais clairsemée de différentes versions des dépendances de matplotlib. L'enquête auprès des utilisateurs de matplotlib fournit de bonnes données sur les domaines sur lesquels concentrer nos efforts : https://docs.google.com/spreadsheets/d/1jbK0J4cIkyBNncnS-gP7pINSliNy9lI-N4JHwxlNSXE/edit

  9. C'est bien d'avoir : Une conception décentralisée pour que ceux qui ont des plates-formes plus obscures puissent publier les résultats de construction sur un tableau de bord central.

Mise en œuvre #

Cette partie est encore à écrire.

Cependant, idéalement, la mise en œuvre serait un service tiers, pour éviter d'ajouter l'administration système à notre temps déjà étiré. Comme nous avons des fonds donnés, ce service peut être payant s'il offre des avantages significatifs en termes de gain de temps par rapport aux offres gratuites.

Rétrocompatibilité #

La rétrocompatibilité n'est pas une préoccupation majeure pour ce député européen. Nous allons remplacer les outils et procédures actuels par quelque chose de mieux et jeter les anciens.

Alternatives #

Notes de conversation #

Infrastructure CI #

  • Nous aimons Travis et il restera probablement dans notre arsenal de toute façon. Les problèmes de fiabilité sont à l'étude.

  • Activez les chargements Amazon S3 des produits de test sur Travis. Cela aidera à post-mortem des échecs (@mdboom étudie cela maintenant).

  • Nous voulons une couverture Mac. Le mieux est probablement de pousser Travis à l'activer pour notre projet en les payant pour un compte Pro (puisqu'ils n'autorisent pas les tests sur Linux et Mac).

  • Nous voulons une couverture Windows. Shining Panda est une option là-bas.

  • Étudiez la recherche ou la création d'un outil qui collecterait et synthétiserait les résultats des tests à partir d'un certain nombre de sources et les publierait sur GitHub à l'aide de l'API GitHub. Cela peut être d'une utilité générale pour la communauté Scipy.

  • Pour Windows et Mac, nous devrions documenter (ou mieux encore, créer un script) le processus de configuration de la machine pour une construction, et comment construire des binaires et des programmes d'installation. Cela peut nécessiter d'obtenir des informations auprès de Russel Owen et Christoph Gohlke. Il s'agit d'une étape nécessaire pour effectuer des builds automatisés, mais elle serait également utile pour un certain nombre d'autres raisons.

Le framework de test lui-même #

  • Nous devrions rechercher des moyens de faire en sorte que cela prenne moins de temps

    • Élimination des tests redondants, si possible

    • Les améliorations générales des performances de matplotlib aideront

  • Nous devrions couvrir plus de choses, en particulier plus de backends

  • On devrait avoir plus de tests unitaires, moins de tests d'intégration, si possible