chore(ci) : Deploy to staging through a PR label

[vperron]

Il est dommage d'entrer en compétition avec les autres dev à chaque push sur une PR.

Avec ce système, on peut choisir quand déployer, surtout quand certaines PR ne méritent pas forcément un deploy, et se mettre d'accord avec les dev pour ce faire.

De plus, passer en draft n'est pas forcément le meilleur système car on confond le principe d'un brouillon (à ne pas relire) et le fait de déployer ou non.

[vmttn]

bonne idée d'utiliser les labels!

par contre, en l'état là ça bloquerait les déploiements en prod car le workflow build_deploy est utlisé pour le staging et la prod

1. déplacer le if sur le job deploy
2. impossible prendre en compte la matrix dans le if au niveau d'un job (cf). Donc soit on duplique le job deploy en deploy_staging et deploy_prod, soit on met le if au niveau des steps (mais on serait forcé de dupliquer le if sur chaque step car un if sur un step ne skip que la step 🤪 )

[vperron]

Je suis moins fan, avec ma proposition tu peux décider que une PR a le "bâton" de déploiement et ne plus t'en occuper, par contre à chaque push ça rédéploiera ta PR comme attendu.
Avec ta solution on doit retourner dans le clickodrome pour chaque push.

[vmttn]

désolé j'ai édité entre temps mon commentaire ;)

[vperron]

OK vu seconde proposition.
Je pense que ce ne serait pas une mauvaise idée de dupliquer le job, car je suis toujours un peu en stress de voir ce job de deploy_prod tel une épée de Damoclès sur les PRs.

Ca serait limite plus clair d'avoir du coup le deploy_prod séparé (quitte à faire un include YAML pour etre DRY) mais qui ne se trigger que lorsque la PR est mergée, et le deploy_staging qui se fait sur label (ou via autorisation explicite, mais comme dit plus haut, je suis moins fan)

[vmttn]

ok pour dupliquer le job donc (dry ou non) et pour utiliser un label 👍

pour la prod, est-ce qu'on n'utiliserait pas la branche (protégée) release pour ne plus avoir à review et s'aligner le fonctionnement qu'on a avec l'api (contraint par scalingo) ?

[vperron]

Je pense qu'aujourd'hui, avec staging de plus en plus proche de la prod et réellement utilisé en recette, on devrait pouvoir se le permettre en effet.

Ca relance un peu le sujet d'avoir une unique datawarehouse, mais j'avoue ne pas être encore certain de la marche à suivre à ce sujet. Le sujet des profils DBT permet en effet d'avoir plusieurs "cibles" mais je ne vois pas en quoi cela nous affranchit d'avoir deux clusters postgres séparés.

Il me semble que dans l'immédiat (et dans le doute) avoir deux datawarehouses, meme proches dans le fonctionnement (on pourrait activer les mêmes DAGs en staging et prod ?) me semble le plus safe. Mais je prends toute autre idée avec plaisir !