You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
En deuxième lecture, déployer sur des tags me semble plus pratique que sur commit. Commit nécessite d'anticiper ce qu'on veut déployer, alors que tag se fait a posteriori. Ca permet aussi de redeployer un commit plus facilement (ex rollback) en taggant à nouveau un commit précédent. Et c'est un indicateur plus net d'une action importante (ex plus simple de lister les tags que grep les commitmsg).
Le match regex fait sur le commit message pourrait être fait sur le nom du tag : deploy-[service]-[env]-[version], avec $version arbitraire (je penche pour $date dans un premier temps). Peut-être trouver un meilleur séparateur si $service peut contenir des tirets...
Donc plutôt tag -> trigger que commit -> trigger -> tag.
Points à couvrir :
Peut-on avoir du trigger-by-tag ? Ecosphères passe par des releases GitHub, donc un tag est systématiquement créé lorsque nous souhaitons déployer (c'est la ref qu'on passe à @jordanguedj pour le déploiement manuelle). Le workflow le plus simple (et ne nécessitant pas des allers-retours CLI/GitHub) est donc de trigger directement sur le tag créé à la release. Cf arguments pour trigger-by-tag.
Je commit-deploy "[demo:ecospheres:...]" sur la branche ecospheres-demo -> deploy sur l'env demo, normal.
Je merge la branche ecospheres-demo sur ecospheres-prod, ce qui inclut le commit-deploy "[demo:ecospheres:...]". Est-ce que le workflow va re-trigger sur la branche ecospheres-prod et donc déployer la branche prod sur l'env demo ?
The text was updated successfully, but these errors were encountered:
Suite de la discussion non-clôturée dans #406.
Points à couvrir :
The text was updated successfully, but these errors were encountered: