chore(workflows) : Attempt at build_deploy only upon merge

gip-inclusion / data-inclusion

data·inclusion aggrège les données de l'insertion sociale et professionnelle

https://api.data.inclusion.beta.gouv.fr/api/v0/docs

MIT License

6 stars 1 forks source link

chore(workflows) : Attempt at build_deploy only upon merge #237

Closed vperron closed 4 months ago

vperron commented 4 months ago

Pour l'instant ça semble bien skip meme quand je ne suis pas en draft.

Est-ce que j'essaie le merge @vmttn ? Si ça te semble jouable ou correct ?

vmttn commented 4 months ago

Si je comprends bien ce que ça ferait :

ça désactive le totalement le workflow sur les PRs. On perd la possiblité de déployer en staging une PR.
ça contraint à créer systématiquement des PRs pour déployer un patch, les commits sans PRs sur main ne déclencheraient pas le workflow
en admettant que c'est bien ce qu'on veut, je crois qu'il manque closed dans les activity types cf

vmttn commented 4 months ago

j'ai l'impression que ce qu'on veut éviter, c'est l'exécution du job deploy dans une PR. Actuellement c'est acquis par le fait qu'on doit trigger manuellement sur gh les deploys en prod.

donc,

soit on garde le fonctionnement actuel
soit on veut se passer du trigger manuel, dans ce cas, la solution, qui permettrait également de garder les deploy en staging pour les PRs, serait d'ajouter d'une façon ou d'une autre une conditionnelle dans le job deploy. Je crois qu'on ne pas utiliser les parametres matrix dans un job.if (pour distinguer la prod du staging). Il faudrait voir si on peut faire cette conditionnelle dans un step.

vperron commented 4 months ago

En effet j'ai été bcp trop simpliste dans l'approche (mais oui en effet je ne considérais pas qu'on allait pousser sur main direct)

Tu as raison, on veut pouvoir garder la possibilité d'un deploy en staging.

Mon souci est que j'avais l'impression que avec le fonctionnement actuel, les PRs doivent etre en draft pour eviter de trigger un déploiement en prod, j'ai tort ?

Après ce n'est pas super gênant non plus, comme fonctionnement.

Sinon pour ta dernière remarque, je vois des exemples contenant des if sur les matrix: https://stackoverflow.com/questions/59230600/how-to-not-allow-some-matrices-together

j'essaie ou on s'en fiche ?

vmttn commented 4 months ago

non les PRs ne doivent pas être en draft pour éviter le déploiement en prod
les PRs peuvent être mises en draft pour éviter un déploiement en staging, à utiliser si on veut éviter d'appliquer des changements difficiles à rollback
pour les ifs avec les matrix : possible dans step.if mais pas dans job.if. Donc si tu veux skip un job, il faut mettre le même if dans chaque step du job.
bon je dirais pas qu'on s'en fiche, mais on peut temporiser