Les dépôts open source permettent une productivité considérable dans le développement de logiciels. La croissance de la base d’utilisateurs se traduit généralement par une croissance du nombre de contributeurs, qui à son tour se traduit par une meilleure solution apportant plus d’utilisateurs, etc. La maintenance de grands dépôts open source peut prendre du temps car vous passez de plus en plus de temps à revoir des contributions. Ne vous méprenez pas, ce temps passé à examiner les pull requests est généralement bien investi car il représente un facteur de gain: pour des minutes passées à revoir une pull request donnée, la base de code bénéficie d’heures d’efforts de développement investis par le contributeur.
Parce que les gens choisissent de consacrer leur temps à contribuer à votre projet, temps qu’ils pourraient utiliser d’un million d’autres façons, vous voulez vous assurer que leur pull request est examiné dès que possible, et leur faire savoir dès qu’un problème surgit. Une expérience de revue fluide garantit non seulement que la pull request finira par être intégrée, mais elle encourage également les contributeurs à soumettre plus de pull requests à l’avenir. Par la même occasion, vous devriez utiliser autant d’outils que possible pour éviter l’épuisement des responsables open source. Vous savez peut-être déjà que j’aime vraiment automatiser autant de travail trivial que possible afin de pouvoir passer mon temps sur des tâches à valeur ajoutée.
Un problème qu’une pull request peut rencontrer est un conflit d’intégration. Supposons qu’Alice et Bob aient tous deux des idées brillantes à ajouter à votre projet, à peu près au même moment. Ils ont tous deux dupliqué le dépôt et ont commencé à travailler. Alice a été plus rapide pour terminer sa pull request et l’a soumise en premier, rapidement suivie par Bob. Ils ont tous deux introduit des changements dans les fichiers qui sont en conflit les uns avec les autres (modifié les mêmes lignes). Vous commencez par examiner la pull request d’Alice, c’est parfait, et vous décidez de la fusionner tout de suite. Maintenant, votre attention est requise ailleurs et vous ne regardez pas celle de Bob.
Il est généralement admis que les contributeurs doivent soumettre des pull requests propres (pas de conflits, le code compile et passe les tests unitaires, atomique, la documentation mise à jour…) et ils doivent maintenir la pull request dans un état propre jusqu’à ce qu’elle soit fusionnée. La pull request de Bob affichera l’état suivant, exigeant que les conflits soient résolus avant de pouvoir être integrée dans la base de code.
Ce statut n’envoie aucune notification au contributeur et n’affiche rien sur aucune liste. Cela rend difficile pour vous, en tant que mainteneur, d’identifier en un coup d’œil quelles pull requests sont en conflit afin que vous puissiez vous concentrer sur la revue de celles qui sont prêtes. Cela peut également bloquer la pull request à moins que Bob ne vienne vérifier sa pull request et pourquoi elle n’a pas encore été fusionnée ou à moins que vous ne preniez le temps de laisser un commentaire demandant à Bob de résoudre les conflits.
Ce point de friction et de latence peut facilement être amélioré via l’automatisation à l’aide des actions GitHub. Ce flux de travail est actuellement utilisé par le dépôt de documentation Microsoft Graph et par certains dépôts Microsoft Graph SDK. Il se déclenche sur les mise à jour de la branche principale ainsi que sur les pull requests ciblant la branche principale et utilise l’action eps1lon/actions-label-merge-conflict pour:
- Identifier les pull requests qui sont désormais en conflit/ne sont plus en conflit en fonction de la dernière mise à jour.
- Ajouter/supprimer automatiquement des étiquettes en fonction de ces informations afin qu’il vous soit plus facile d’identifier en un coup d’œil les pull requests qui sont en conflit.
- Commenter automatiquement en fonction des informations afin que les contributeurs reçoivent une notification.
Vous pouvez voir que les pull requests en conflit sont beaucoup plus faciles à identifier (et même à filtrer) lorsque vous examinez toutes les pull requests sur le dépôt.
Voici un exemple de ce à quoi ressemble un message pour une pull request en conflit.
Enfin, voici l’exemple de workflow. Vous devez placer ce fichier sous /.github/workflows/unnom.yml dans votre dépôt et vous pouvez bien sûr le modifier à votre convenance.
Remarque: vous vous demandez peut-être pourquoi ce flux de travail se déclenche en mode push. C’est parce que le
GITHUB_TOKENpour les pull requests provenant de copies (forks) aura des autorisations en lecture seule, ce qui l’empêche d’étiqueter et/ou de commenter les problèmes. L’action examine toutes les pull requests ouvertes chaque fois qu’elle est déclenchée par push.
name: PullRequestConflicting
# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
push:
branches: [ master, dev ]
pull_request:
types: [synchronize]
branches: [ master, dev ]
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
# This workflow contains a single job called "build"
build:
# The type of runner that the job will run on
runs-on: ubuntu-latest
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
- name: check if prs are dirty
uses: eps1lon/actions-label-merge-conflict@releases/2.x
if: env.LABELING_TOKEN != '' && env.LABELING_TOKEN != null
id: check
with:
dirtyLabel: "conflicting"
repoToken: "${{ secrets.GITHUB_TOKEN }}"
continueOnMissingPermissions: true
commentOnDirty: 'This pull request has conflicting changes, the author must resolve the conflicts before this pull request can be merged.'
commentOnClean: 'Conflicts have been resolved. A maintainer will take a look shortly.'
env:
LABELING_TOKEN: ${{secrets.GITHUB_TOKEN }}