Un tableau de bord est comme un jeune enfant, fragile et en demande d’attention. Alors que pour la plupart des gens le tableau de bord n’apporte pas autant de valeur ajoutée qu’une nouvelle application dans la bibliothèque (comme un joli installateur de bibliothèque, plus d’info dans un prochain post), pour les développeurs c’est la clef du succès.

La plupart des développeurs ont des préférences pour certains systèmes d’exploitation ou outils de développement. En ce qui me concerne, je fais la majorité de mes développements sur Mac. Toutefois, vous devez savoir que le code est testé sous plusieurs systèmes d’exploitation, compilateurs, options, etc. Si votre tableau de bord est à jour et bien entretenu, la plupart du temps ça vous évitera d’avoir à tester votre code pour chaque configuration. Il faut donc mettre en place plusieurs choses pour que le tableau de bord soit utilisable au maximum de ses capacités et soit votre filet de sécurité.

• Tous les systèmes d’exploitation, compilateurs et options pris en charge doivent apparaître comme une compilation indépendante dans le tableau de bord (dans notre cas, nous voulons avoir autant de compilations qu’il en existe dans la cascade officielle).
• Le code doit être testé autant que possible sur chaque plateforme, vous devez donc avoir de la visibilité sur la couverture du code pour chaque plateforme (plus dans un prochain post).  Enlever un test défaillant pour faire en sorte que tout soit au vert sur votre tableau de bord, et ainsi cacher une erreur, n’est pas une bonne chose.
• Le tableau de bord doit toujours rester au vert (donc sans aucune erreur lors des tests), ainsi, quand une nouvelle erreur se produit vous la remarquez immédiatement et elle ne se confond pas avec un test défaillant antérieur.

De ce fait, hier, j’ai passé un peu de temps à tester mes scripts sur Linux. Comme prévu; ça a fonctionné presque tel quel, mais les premiers résultats ont montré 9 tests qui ont échoué ! C’est somme toute beaucoup. Alors j’ai fait un double contrôle sur la cascade officielle, et pour ce qui concerne la compilation Linux, tout était au vert, donc il y a quelque chose que je devais mal faire. Ou peut être pas finalement ?

En regardant la cascade, il y avait 47 rapports de compilation. La matrice de base pour calculer les différentes types de compilation utilise les paramètres suivants :

• système d’exploitation : Windows, Mac, iOS, Linux, Android,
• architecture : 32 / 64 bits
• BUILD_TYPE : Debug / Release
• OPTIONS : Normal / Large-tests / GN / Simulator / (autres compilations exotiques)
•  Pour Android : try bots sur des matériels réels : Nexus 5, 7.2, 9

Je ne veux pas tout reproduire, enfin pas pour l’instant, mais j’aimerais commencer par couvrir tous les systèmes d’exploitation, leurs architectures, et les modes de compilation (Debug / Release). En consultant la compilation release linux 32, j’ai réalisé qu’elle exécutait moins de test que les versions Windows ou Mac. J’ai donc commencé par modifier mes scripts de test pour ne pas les inclure ceux qui manquent si la plateforme est Linux. Boum, il ne restait plus que deux erreurs.. La première erreur semble être liée à une mauvaise allocation mémoire. C’est là qu’on réalise que lancer la compilation et les tests sur la plus petite instance de Linux dans AWS etait une mauvaise idée. Cette erreur devrait disparaître lorsque j’hébergerai le bot de compilation de Linux sur une instance AWS plus grande. La seconde erreur est plus difficile à cerner et je ne peux pas la comprendre en utilisant seulement les logs. Lorsque j’aurais mis en place une instance Linux plus puissante pour la compilation, je déboguerais.

Les prochains posts porteront sur le packaging et l’ajout de calcul de couverture (pour les compilateurs gcc et clang) et la vérification des fuites mémoire (en utilisant valgrind). Restez connecté.