LxLeChat
Complete CI
J'ai mis en place une github actions, qui build la solution, et run les tests. Il faudra compléter a terme avec
- la maj du manifeste
- ajouter des machines pour runner les tests ( ubuntu & macos ) (pour l'instant impossible de dll pester ... )
- publication sur la gallery ... si je retrouve ma clé ... et quand la psgallery sera de nouveau up ... !
- la generation des docs ?
- maj du readme si possible ... !
J'ai mis en place une github actions, qui build la solution, et run les tests.
Ok, mais comment on build si on a pas accès à github ? Je peut aussi vouloir contrôler la chaîne avant de commiter. En recherchant 'simulate github action' on peut lire que le besoin existe. Je ne sais pas si on peut découpler ce build à l'aide de scripts.
ouais j y ai pensé, je vais compléter le script de build qui existe,. c'était surtout pour m'amuser un peu avec du yaml ... 😸
enfait le plus logique serait de lancer directement le script de build dans l'action github, mais la ça permet surtout de builder, si le build est passé de runner les tests
ajout de ubuntu à la matrice de tests, mais vu que le module est cassé ça ne fonctionne pas .. !
Ubuntu:
Discovering in /home/runner/work/FlowChartCore/FlowChartCore/Test/UseCases.Tests.ps1.
System.IO.FileNotFoundException: The specified module '/home/runner/work/FlowChartCore/FlowChartCore/Test\..\Src\bin\Debug\netcoreapp3.1\FlowchartCore.dll' was not loaded because no valid module file was found in any module directory.
On my Ubutun 18-04 (wsl) tests are working ... dont know why they are not working on the github ubuntu runner ...
A priori Ubuntu dans github actions est case sensitive... Du coup il va falloir reflechir à comment lancer les tests autrement... Je vais créer un répertoire CI, qui sera dédié uniquement au ... CI ! sinon je vais pas m en sortir de ce truc !
Get-Item -Patch .\src retourne une erreur, tandis que Get-Item -Path .\Src fonctionne ..
Il y a ce post sur le sujet, peut-être un pb de configuration ?
Get-Item -Patch .\srcretourne une erreur, tandis queGet-Item -Path .\Srcfonctionne ..
Powershell doit être insensible à la casse. C'est un gros soucis ce cas !
je suis exactement tombé sur ce post ! [edit] j'ai posé la question sur le discord PS et sur twitter on verra bien https://twitter.com/LxleChat/status/1327638476280524800?ref_src=twsrc%5Etfw
Bon bah va falloir faire du renommage..! Les fichiers et folders sont case sensitive sur linux... du coup tu peux avoir src et Src côte à côte
Bon bah va falloir faire du renommage..! Les fichiers et folders sont case sensitive sur linux... du coup tu peux avoir src et Src côte à côte
J'ai un doute :
Comportement dépendant du FS ?
Que Linux soit sensible à la casse c'est une chose et je suis tenté de dire que tant que l'on passe des commandes dans cet environnement on doit y prêter attention, mais dans un script Powershell ? quoique.
Si tu renommes, tu renommes tout en minuscule ? Curieux de voir ce cas :-)
Je suis plutôt partisan du 1 lettre de chaque mot en maj... mais ici je crois que je vais pas me prendre la tete et tout mettre en minuscule Du coup oui c le FS qui joue, et sur wsl le FS c celui de windows finalement...
je viens d'inclure la generation des docs avec platyps ... la tache fonctionne ... sauf qu'on ne retrouve pas les fichiers dans le répertoire module ^^ j'ai du rater un truc ! du coup ça doit etre pareil pour le build de la dll !!! quoi que ... du coup ça sera utilisé dans la phase de publish ... ARGLE je ne sais pas ce que je fais !
ARGLE je ne sais pas ce que je fais !
C'est un bon début ;-)
on ne retrouve pas les fichiers dans le répertoire module ^^
Dans mon ébauche de build je créé, à la racine du projet, un répertoire Release (exclu dans .gitignore) dans lequel je génère tous les fichiers de la livraison. C'est pour cette raison qu'un build hors 'github action' a son intérêt, on fait la même chose mais pas de la même manière.
sauf qu'on ne retrouve pas les fichiers dans le répertoire module
La plupart des build PS sont basés sur des recopies de fichier, reste à paramétrer le répertoire de livraison.
Du peu que je comprends, dans le CI, ceci :
$MdFiles.Foreach({ New-ExternalHelp -Path $PsItem.FullName -OutputPath $PSItem.DirectoryName })
cible, pour l'élément à générer, le même répertoire (l'extension diffère). Il n'y a pas de de notion de répertoire de livraison à partir duquel on publie le module.
sisi, enfait je copie les répertoire fr-FR et en-US dans le répertoire module juste avant. Et je lance la generation à partir de .\src\module
enfait c'est juste que je devrais relancer un commit derriere ... mais je vais tester tout ça sur un repo privé, ça polluera pas le repo "officiel"
bon je suis entrain de faire des tests sur un repo privé (copie de celui la enfait ..) mais en gros voila le déroulement lors d'un PR:
- un premier yaml qui déclenche une action, qui va build et faire les tests à l'ouverture d'un PR vers MASTER
- un deuxième yaml, à la fermeture du PR, qui va copier les fichiers dans le répertoire module, générer les fichiers d'aide
ensuite il faudra juste integrer la publication à la psgallery dans ce 2° yaml.
j'ai failli abandonné, mais finalement j'ai réussi .. ! Voila le processus quand un PR est déclénché:
- Workflow de build et tests (un peu comme celui qui était en place), simple, on build la solution et invoke pester
On a ensuite un 2° processus qui se déclenche lors que je merge le PR (ou manuellement):
- Workflow qui fonctionne uniquement sur la branche master: il build la solution, déplace les dll dans /src/module, déplace les répertoire en-US et fr-FR depuis Docs vers /src/module, et ensuite on génère l'aide à l'aide de platyPS.
Ca permet a quelqu'un qui veut juste bosser sur le c# et pas s'embeter à builder, genre moi ..., à pusher des choses en dev direct, si par exemple je suis sur que ça ne va pas breaker des tests par exemple. Et surtout on s'assure que la DOC est generé à chaque fois.
Je pousserai tout ça dans la soirée sur le repo, et ferai un tests ou 2. (je crois qu'il faut que j'intère un truc qui nettoie le répertoire module aussi, à vérifier)
boooooooooooooon ! voila c'est en place :)
y a encore un mini kwak ..
@LaurentDardenne il vaut mieux garder le répertoire FlowChartCore ?? moi ça me dérange pas faut juste que je change 2 chemin dans le second workflow !
Mais comme on peut le voir, le message "Auto Commit" ça veut dire que tout a été fait à la clôture du PR ! et ça c'est COOL ! il me manquait la notion d'artifact pour passer des données entre Jobs d'un même workflow .. !
@LaurentDardenne il vaut mieux garder le répertoire FlowChartCore ??
J'ai l'impression que tu as tout placé dans le repo alors que le résultat du build est transitoire. On construit le build dans la VM puis on le publie (en artifact et/ou sur une gallery) enfin tout les fichiers inutiles sont supprimés.
Je pense que tu le sais mais je ne sais pas trop si ici c'est le résultat du build ou autre chose...
Ah petard mais t as raison... gt tellement focus sur mon délire que j en ai oublié le principal... pffff :) Allez retour a la case départ !!!
du coup je suis lost! je ne sais plus ce qu'il faut faire ^^
DU coup j'ai commenté le workflow qui fait des actions à la cloture du PR (au moins j'aurai apris des trucs ... ) et il n'est lancable que manuellement.
Donc toi tu voyais le truc comment @LaurentDardenne avec le script de build ?? Je pense qu'il faut garder la partie test quand on ouvre un PR, au moins ça permet de controler que rien n'est cassé.
dans quel mesure interviendrait le CI ? publication automatique vers la gallery ?? voila, ton avis m'interesse beaucoup :)
je ne sais plus ce qu'il faut faire ^^
Du peu que j'ai eu le temps de lire du script de Workflow, seul les chemins cible sont à modifier. Par exemple $env:Temp au lieu de .\Src\xxx, à vérifier sous Linux. Tu n'as pas perdu ton temps, la mise au point avec ce genre d'outil lorsqu'on débute est laborieuse.
Donc toi tu voyais le truc comment @LaurentDardenne avec le script de build ??
Je n'ai pas pris le temps jusqu'ici de regarder GitHub Action, j'essaierais déjà un script de build en local quitte à le porter dans Github Action. Les deux font la même chose, hormis le déclenchement, mais pas de la même manière.
Je pense qu'il faut garder la partie test quand on ouvre un PR, au moins ça permet de contrôler que rien n'est cassé.
Disons que cela permet de vérifier que les étapes de la construction réussissent, le fonctionnel c'est autre chose :-)
publication automatique vers la gallery ??
Il faut déjà le déclencher sur un event particulier (création d'une release?) et gérer les numéros de version. Et sur ce point il faut, je pense, fixer les versions d'outils utilisés dans le build sinon on risque dans la VM de télécharger les dernières versions qui peuvent avoir des breaking changes ou des régressions.
dans quel mesure interviendrait le CI ? Dans l'intégration continue tu peux réaliser tout ou parties des étapes. De livrer en continu n'est peut être pas nécessaire ici.
Essaie déjà un script en local, tu y verras plus clair par la suite je pense. Je te joint l'ébauche de ce que j'ai déjà fait, mais il ne fonctionne pas encore. Ebauche build-FlowChartCore.zip
Il est inspiré de celui-ci