Migration de la CI #1
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
On avait une CI sur GitHub. @mdk, tu as commencé à regarder si c'était facile de porter ça sur Gitea ?
Non je n'ai pas commencé à regarder.
Il existe une collection d'outils de CI utilisable par gitea ici :
=> https://gitea.com/gitea/awesome-gitea#user-content-devops
Je ne suis pas convaincu que ce soit bien : l'action Github lançait, entre autre, des
sphinx build
très consommateurs de resources (CPU et réseau) à chaque petite modification sur une PR.Je n'ai rien contre la CI, mais j'ai quelque chose contre l'utilisation déraisonnée des resources.
D'un côté, c'est vrai, d'un autre côté, il faut s'avouer qu'on est une goutte d'eau dans la mer à côté d'autres CI bien plus consommatrices.
Quoi qu'il en soit, ce serait bien d'avoir au moins pospell, sphinx-lint et powrap, qui sont rapides.
Un truc qui serait bien, ce serait d'avoir le sphinx-build qui tourne, mais seulement au moment de fusionner la PR (pour éviter les erreurs triviales qui cassent la prod, mais en compromis pour ne pas lancer trop de builds non plus).
Tout à fait d'accord, mais ça ne justifie pas une utilisation déraisonnée des resources.
@mdk on peut demander à sphinx de build juste des fichiers de doc qu'on lui passerait (ceux qui auraient changé par ex), et pas tout le projet ?
J'en doute, il ne pourrai pas repérer de liens cassés s'il n'a pas le reste du projet.
https://www.sphinx-doc.org/en/master/man/sphinx-build.html#description
“By default, everything that is outdated is built. Output only for selected files can be built by specifying individual filenames.”
on va sûrement pas retrouver un service de CI avec un free-tiers comme Github Actions. Entretemps, on risque de casser la doc python fr, non ?
https://woodpecker.afpy.org/AFPy/python-docs-fr/build/17/3
Il reste un peu de boulot :D
Attention je déplace la machine, il peut y avoir des surprises jusqu'à ~13h aujourd'hui.
Il y a du mieux à chaque build a priori :)
Merci @mdk !
Hey ça commence à marcher comme il faut, qui veut review #118 ?
Oui, s'il a son "cache" sous la main, d'un build précédent, sur la branche 3.11, c'est super spécifique comme condition. Et il n'y a pas de cache (du tout) dans Woodpecker CI ☹ (oui c'est moche pour la bande passante de PyPI).
Non non :
Quand on fait ça, il lit tous les fichiers .rst, mais n'écrit que certains fichiers .html. Ça ne rend pas le temps linéaire en fonction du nombre de documents, il y a quand même un temps fixé pour lire tous les documents, mais malgré tout, il y a un gain.
Oh intéressant, il faudra tester (mais dans une PR à part, j'aimerai déjà merger #118).
Pas sûr d'avoir envie d'aller plus loin dans la CI pour le moment : si on lance un build sphinx ça nécessite de cloner cpython à chaque fois, je trouve ça un peu bourrin.
Mais on a une CI qui marche \o/ je ferme l'issue.
C'est très très bien comme ça !
Merci
On pourrait faire un clone partiel. Mais la CI actuelle me va, on verra aussi à l'usage.