Guide de contribution
Discussion
Si vous avez une question, si vous cherchez de l’aide interactive pour le dépannage ou si vous souhaitez discuter avec d’autres utilisateurs de Patroni, rejoignez-nous sur le canal #patroni dans le PostgreSQL Slack .
Signalement de bogues
Avant de signaler un bogue, assurez-vous de le reproduire avec la dernière version de Patroni ! Vérifiez également attentivement si le problème existe déjà dans notre Suivi des problèmes .
Exécution des tests
Conditions requises pour exécuter les tests behave :
- Les paquets PostgreSQL incluant les modules contrib doivent être installés.
- Les binaires PostgreSQL doivent être disponibles dans votre
PATH. Vous devrez peut-être les ajouter au chemin en utilisant quelque chose commePATH=/usr/lib/postgresql/11/bin:$PATH python -m behave. - Si vous souhaitez effectuer des tests avec des DCS externes (par exemple, etcd, Consul ou Zookeeper), vous devrez installer les paquets correspondants et faire fonctionner les services associés, qui doivent accepter les connexions non chiffrées/non protégées sur localhost et le port par défaut. Dans le cas d’etcd ou de Consul, le jeu de tests behave peut les démarrer si les binaires sont disponibles dans le
PATH.
Installer les dépendances :
Une fois toutes les dépendances installées, vous pouvez exécuter les différentes suites de tests :
Test avec tox
Pour exécuter les tests tox, il vous suffit d’installer une seule dépendance (en plus de Python).
Si vous souhaitez exécuter les tests behave basés sur Docker, vous devez également avoir installé Docker.
La configuration Tox dans tox.ini dispose d’« environnements » permettant d’exécuter les tâches suivantes :
- lint : analyse de code Python avec
flake8 - test : tests unitaires pour tous les interpréteurs Python disponibles avec
pytest, génération de rapports HTML si un TTY est détecté, sinon de rapports XML - dep : détection des conflits de dépendances de paquets à l’aide de
pipdeptree - type : vérification statique des types avec
pyright - black : formatage du code avec
black - docker-build : construction de l’image Docker utilisée pour l’environnement
behave - docker-cmd : exécution d’une commande arbitraire avec l’image précédente
- docker-behave-etcd : exécution de tox pour les tests behave avec l’image précédente
- py*behave : exécution de behave avec les interpréteurs Python disponibles (sans Docker, bien que ce soit ce qui est appelé à l’intérieur des conteneurs Docker)
- docs : génération de la documentation avec
sphinx
Exécution de tox
Pour exécuter la liste d’environnements par défaut (dep, lint, test et docs), exécutez simplement :
Les environnements test peuvent être exécutés avec l’étiquette test :
Les tests Docker behave peuvent être exécutés avec l’étiquette behave :
De même, docs porte l’étiquette docs.
Tous les autres environnements peuvent être exécutés avec leurs noms respectifs :
Il est également possible de sélectionner des listes d’environnement partielles à l’aide de factors. Par exemple, si vous souhaitez exécuter tous les environnements pour Python 3.10 :
Cela équivaut à exécuter tous les environnements listés ci-dessous :
Vous pouvez lister toutes les combinaisons d’environnements configurées avec tox (≥ v4) comme suit :
Les environnements test et docs tenteront d’ouvrir les fichiers de sortie HTML une fois la tâche terminée, si tox est exécuté depuis un terminal actif. Cette fonction est destinée à faciliter le travail du développeur exécutant cet environnement localement. Elle tentera d’exécuter open sur macOS et xdg-open sur Linux. Pour utiliser une commande différente, définissez la variable d’environnement OPEN_CMD avec le nom ou le chemin de la commande. Si cette étape échoue, cela n’empêchera pas l’exécution globale de la tâche. Pour désactiver cette fonctionnalité, définissez la variable d’environnement OPEN_CMD sur la commande no-op :.
Tests Behave
Les tests Behave avec -m behave construiront des images Docker basées sur les versions 12 à 18 de PG_MAJOR, puis exécuteront tous les tests Behave. Cette opération peut prendre beaucoup de temps ; vous voudrez donc peut-être limiter la portée à une version spécifique de PostgreSQL ou à un ensemble de fonctionnalités ou d’étapes spécifique.
Pour spécifier la version de postgres, indiquez le nom complet de l’environnement de build de l’image dépendante que vous souhaitez utiliser, suivi du nom de l’environnement behave. Par exemple, si vous souhaitez Postgres 14, utilisez :
Si, en revanche, vous souhaitez tester une fonctionnalité spécifique, vous pouvez passer des arguments positionnels à behave. Cela exécutera le scénario de test de la fonctionnalité watchdog de behave avec toutes les versions de Postgres.
Bien sûr, vous pouvez combiner les deux.
Contribution d’une demande de fusion
- Créez un fork du dépôt, développez et testez vos modifications de code.
- Répercutez les modifications dans la documentation utilisateur.
- Soumettez une demande de fusion avec une description claire de l’objectif des modifications. Liez une issue existante si nécessaire.
Vous recevrez un retour sur votre demande de fusion dès que possible.
Bon hacking avec Patroni ;-)