Évite que la CI tourne sans PR

[Kout95]

Merci de contribuer à OpenFisca ! Effacez cette ligne ainsi que, pour chaque ligne ci-dessous, les cas ne correspondant pas à votre contribution :)

• Amélioration technique.
• Zones impactées : .github/workflows/workflow.yml.
• Détails :
  • Évite que la CI tourne sans PR

---

• Modifie le fonctionnement de la CI

---

Quelques conseils à prendre en compte :

• Jetez un coup d'œil au guide de contribution.
• Regardez s'il n'y a pas une proposition introduisant ces mêmes changements.
• Documentez votre contribution avec des références législatives.
• Mettez à jour ou ajoutez des tests correspondant à votre contribution.
• Augmentez le numéro de version dans setup.py.
• Mettez à jour le CHANGELOG.md.
• Assurez-vous de bien décrire votre contribution, comme indiqué ci-dessus

Et surtout, n'hésitez pas à demander de l'aide ! :)

[benoit-cty]

Bonjour,

Dans https://github.com/openfisca/openfisca-france/pull/1786/files#diff-34819666b47069e1b67298b87d6fbd56a1b8bde32f43b5e0bf13e44c74427a65R4, je propose:

  push:
  workflow_dispatch:
  pull_request:
    types: [opened, reopened]

=> Conserver les tests sur tous les push, et sur les PR seulement à l'ouverture.
alors que cette PR propose:

on:
  push:
    branches:
      - master
  pull_request:

=> Test uniquement sur les PR, et lors du push sur master. Donc les tests ne tournent pas tant qu'on n'ouvre pas de PR.

Je n'ai pas d'avis sur la question. La deuxième option est plus écologique car elle limite le nombre de CI. Personnellement je ne m'occupe pas des tests tant que je n'ai pas ouvert de PR.

[Kout95]

Bonjour,

Dans https://github.com/openfisca/openfisca-france/pull/1786/files#diff-34819666b47069e1b67298b87d6fbd56a1b8bde32f43b5e0bf13e44c74427a65R4, je propose:

  push:
  workflow_dispatch:
  pull_request:
    types: [opened, reopened]

=> Conserver les tests sur tous les push, et sur les PR seulement à l'ouverture. alors que cette PR propose:

on:
  push:
    branches:
      - master
  pull_request:

=> Test uniquement sur les PR, et lors du push sur master. Donc les tests ne tournent pas tant qu'on n'ouvre pas de PR.

Je n'ai pas d'avis sur la question. La deuxième option est plus écologique car elle limite le nombre de CI. Personnellement je ne m'occupe pas des tests tant que je n'ai pas ouvert de PR.

Bonjour Benoit !
Merci pour ta réponse.
En effet, les deux solutions sont envisageables et corrigent les problèmes de double validation.
Personnellement, j'utilise les vérifications de la CI uniquement à partir de la création de ma PR. Pour éviter de faire tourner la CI dans le vent, je pense que passer par une PR est une bonne pratique. Et dans le cas où l'on souhaite tester plus prématurément sans avoir terminé, le mode draft est présent pour cela :)

[Cugniere]

La branche est à mettre à jour, mais je pense que le fonctionnement apporté par la PR est le bon. La CI tourne en cas de PR (draft ou normale) et en cas de merge sur master (ce qui est une bonne pratique étant donné qu'on peut avoir un scénario où une branche pas à jour merge sur master peut entrainer l'échec d'un test)

[MattiSG]

Personnellement, j'apprécie avoir un retour de la CI lorsque je push. Je pense que cela peut réduire le bruit (et donc la perte de temps des reviewers) en évitant que des personnes n'ouvrent une PR et ne découvrent qu'à ce moment-là qu'elles ont des retours d'erreur automatique. Je trouverais regrettable que chaque PR commence par 2 jours de délai et 3 commits avant qu'elles ne soient réellement ouvertes pour revue.

Je pense notamment aux personnes ayant une connaissance technique limitée et qui débute, et pour qui il peut être plus simple de faire un push que d'exécuter les tests localement. Pour ma part, je m'en sers pour paralléliser l'exécution des tests et le développement lorsque j'ai atteint un point important où je crois mon code stabilisé.

Bien évidemment, pour un usage économe, cela suppose que les push ne soient pas faits à chaque commit.

[MattiSG]

😉

[Kout95]

Personnellement, j'apprécie avoir un retour de la CI lorsque je push. Je pense que cela peut réduire le bruit (et donc la perte de temps des reviewers) en évitant que des personnes n'ouvrent une PR et ne découvrent qu'à ce moment-là qu'elles ont des retours d'erreur automatique. Je trouverais regrettable que chaque PR commence par 2 jours de délai et 3 commits avant qu'elles ne soient réellement ouvertes pour revue.

Je pense notamment aux personnes ayant une connaissance technique limitée et qui débute, et pour qui il peut être plus simple de faire un push que d'exécuter les tests localement. Pour ma part, je m'en sers pour paralléliser l'exécution des tests et le développement lorsque j'ai atteint un point important où je crois mon code stabilisé.

Bien évidemment, pour un usage économe, cela suppose que les push ne soient pas faits à chaque commit.

Très bien ! Dans ce cas je ferme cette PR. Merci pour ton retour @MattiSG !