Notification de build alpha sur les issues GitHub

[pylapp]

Contexte

Au jour d'aujourd'hui le code source est basé sur GitHub dans la mesure où OUDS est un projet qui se veut open source. Néanmoins, la chaîne de CI/CD se base sur une solution logicielle et des runners internes à l'entreprise pour deux raisons : d'une part conserver sur nos machines le certificat type iPhone Distribution et le mobile provisioning profile nécessaires au build de la version ; d'autre part l'anticipation d'un éventuel besoin futur de devoir compiler OUDS iOS avec des composants internes pour éviter de diffuser publiquement des ressources comme des fontes ou des images.

De fait, du fait de l'absence de fonctionnalité sur la solution logicielle interne actuelle d'avoir du mirroring avec ce dépôt GitHub, il n'y a pas de solution technique permettant de faire le lien entre les issues GitHub et les builds TestFlight sur la solution de CI-CD interne.

Le besoin

Avoir une fonctionnalité dans la chaîne de CI/CD pour notifier qui veut sur les issues GitHub de la mise à disposition d'un nouveau build TestFlight permettrait automatiquement de notifier les parties prenantes de l'existence de ce build.

Détails techniques

Dans la mesure où la solution logicielle interne de CI/CD utilise l'API REST de GitHub pour télécharger au format ZIP la version utile du code source de OUDS iOS, il n'y a pas d'historique Git. Ainsi, il n'est pas facilement possible et à moindre coût de définir entre deux itérations quelles issues GitHub sont concernées et embarquées dans ke build (avec une approche incrémentale de la chose). Ainsi, pour les builds PROD et BÊTA il faudrait :

• récupérer le CHANGELOG du commit à builder
• récupérer le CHANGELOG du dernier commit buildé, uploadé et taggé
• faire un diff de ces fichiers afin d'extraire les nouvelles lignes en supposant que la structure du fichier n'a pas changé
• en extraire les numéros des issues GitHub (supposant de fait que chaque nouvelle ligne du CHANGELOG référence correctement une issue GitHub au moins)
• une fois le build et l'upload faits, laisser un commentaire sur chacun des issues concernées (supposant qu'elles existent bien) avec les détails du build
• et ce, sans cloner le dépôt Git et en utilisant uniquement le ZIP téléchargé afin afin d'éviter d'avoir à cloner le dépôt à chaque exécution de job

De fait, cette carte ne devrait concerner que les builds ALPHA pour lesquels les numéros des issues sont référencés en tant que variables lors de l'exécution manuelle du pipeline.

La fonctionnalité devrait être implémentée de la façon suivante (implémentation naïve gros sabots) :

• récupérer dans la variable idoine les issues (split sur virgule et trim)
• faire le build et upload TestFlight
• une fois fait, si succès, forger un message notamment avec le type de build et le build number ainsi que la version de l'app
• pour chaque issue trouvée dans la variable, laisser un commentaire via l'API REST GitHub et dans le canal de chatops interne utilisé avec le hook, laisser un message pour toute issue référencée non trouvée

[pylapp]

Modèle de message : https://github.com/Orange-OpenSource/ouds-ios/issues/33#issuecomment-2266172366

[pylapp]

📣 New TestFlight ALPHA upload 🚀

• Display name: 'OUDS Showcase ALPHA (56)'
• Version:'0.1.0'
• Build number: '1722891683'
• Build tag: 'ced649b'
• Build type: 'ALPHA'
• Build details (GitHub):'56'

This is an automated message sent with Fastlane from our CI/CD pipepline