Pack.zip builder : plus d'excuses pour ne pas QA le front \o/

Yop !

TL;DR : http://zds.alex-d.fr/

Vous mettez la branche que vous voulez et hop, vous aurez le zip qui va bien à mettre dans le dossier /dist de votre projet.

Exemples :

• membre:branche
• membre/branche

Le premier format peut être copié/collé en haut d'une PR directement dans le champ.

La checkbox permet de forcer à rebuild le zip, autrement il viendra du cache s'il a déjà été construit. Autant que possible, évitez de rebuild ce qui l'a déjà été, sauf si vous constatez que ce que vous téléchargez ne colle pas à ce qui est attendu.

Le front étant chiant à installer, nous sommes peu d'actifs à avoir les outils nécessaires (3 à ce que j'ai pu voir). Pour faciliter la QA et peut-être même le dev de certains : reprendre du code front non mergé pendant son dev, ou que sais-je encore ? j'ai codé une petite page sur mon serveur qui construit le zip pour une page donnée.

J'ai mis un webhook sur mon repo, ce qui fait qu'à chaque PR que je ferais, la génération aura déjà été faite, ça ira donc super vite à se charger. En autre temps (pour un repo d'un contrib externe par exemple) le code fonctionnera, mais il va faire le build à la demande, donc ça peut être un peu long, notamment s'il y a du changement dans les dépendances npm.

Ca se peut que le build soit méga lent, genre 5 minutes, parce qu'il met à jour toutes les dépendances ou quoi, tout comme ça peut mettre 1 minute si les dépendances ont pas bougé (npm & gulp). Enfin voilà, si c'est pas DL depuis le cache, vous pouvez prendre un café

Il est possible que le truc crash, ça vous mettra un message austère, n'hésitez pas à me le dire, normalement j'ai mis des logs viteuf, mais c'est pas non plus le système de ouf.

La plupart des crash actuels sont dus à des branches trop vielles, des erreurs qui ont été corrigées depuis (même si je ne comprends pas trop pourquoi ça ne fonctionne pas). Par exemple, faire un build de la prod ne fonctionne pas, mais un build de dev fonctionne…

Il faut encore que je rajoute un lock, en cas de build simultanés (c'est le même repo git qui est manipulé derrière) mais là tout de suite, heure de dormir et pas urgent.

Sympa (j'avoue, j'ai pas encore testé, faisant partie des "3" qui ont les outils de front )

Ceci dit, pourquoi ne pas faire une PR pour éditer la doc ?

Alleluia \o/ Je vais enfin pouvoir build vos cochonneries !

Le front étant chiant à installer

Merci de le reconnaître

J’essaierai ca des que le besoin s'en fait sentir. Par contre si je veux récupérer le pack de la branche dev de ZdS je fais comment ? Comme ca ? zestedesavoir:dev

Pierre : pourquoi pas, mais ça reste un outil externe, pas vraiment officiel. Je préfère mettre un lien du pack dans chaque PR à la limite.

Eskimon : ouep, exactement. Et normalement il est déjà build donc ça va se DL instantanément.

Je sais que ça peut être utile, mais le but de la QA n'est pas justement de tester que le code fonctionne ailleurs que chez le dev lui même ?

Pas que je n'ai pas confiance aux outils d'Alex-D, mais si le pack est généré chez lui, ça ne veut pas dire que ça sera le cas chez tout le monde. Donc, je suis un peu mitigé, sur le principe.

C'est généré sur une debian qui est à peu de chose prêt comme celle de la prod. Je dev sur Windows et Travis fait aussi le build.

Je pense que c'est déjà pas mal comme tests de builds.

C'est bien pour ça que je dis que je suis mitigé (neutre en fait).

Problème

"GET /static/images/sprite@2x.png HTTP/1.1" 404

Y a un vrai soucis avec les droits et le sprite, c'est super chiant… je regarderais ça. Bon après, tu choppe le sprite de la prod et ça tourne, vu qu'on change quasi que le CSS ça n'a pas d'importance pour l'instant.

C'est bien ce que j'ai fais