Contribuer; faciliter; contribuer; donner (ce mot a plusieurs significations et la traduction spécifique doit être déterminée en fonction du contexte)

Merci de votre intérêt à contribuer à Starlette. Vous pouvez contribuer au projet de plusieurs façons:

• Essayez Starlette et signalez les erreurs/problèmes que vous avez trouvés
• Implémentation de nouvelles fonctionnalités
• Examiner les pull requests d'autrui
• Écrire un document
• Participer à la discussion

Signaler un bug ou un autre problème

Vous avez découvert quelque chose que Starlette est censé soutenir? vous êtes tombé sur un comportement inattendu?

Les contributions devraient généralement commencer par une discussion. les erreurs possibles peuvent être soulevées en tant que discussion sur les « problèmes potentiels » et les demandes de fonctionnalités peuvent être soulevées en tant que discussions sur les « idées ». nous pouvons alors déterminer si cette discussion doit être escaladée en « problèmes » ou si nous envisagerons une demande d'extraction.

Essayez d'être plus détaillé et, dans le cas d'un rapport de bogue, fournissez autant d'informations que possible, telles que:

• Plateforme OS
• Version de Python
• Dépendances et versions installées (python -m pip freeze)
• Fragment de code
• Erreur tracking backtrack

Vous devriez toujours essayer de réduire tout exemple à la situation la plus simple possible qui illustre le problème.

Développement; Développement

Pour commencer à développer Starlette, créez une branche sur GitHub pour le dépôt Starlette.

Puis utilisez la commande suivante pour cloner votre branche, en remplaçant YOUR-USERNAME par votre nom d'utilisateur GitHub:

$ Git clone https://github.com/YOUR-USERNAME/starlette

Vous pouvez maintenant installer le projet et ses dépendances en utilisant la commande suivante:

$ cd starlette
$ scripts/installation

Tests et vérification de code

Nous utilisons des scripts shell personnalisés pour automatiser les tests, la vérification du code et les flux de travail de création de documents.

Pour effectuer ces tests, utilisez:

$ scripts/test

Tous les autres paramètres seront passés à pytest. pour plus d'informations, consultez la documentation de pytest.

Par exemple, exécutez un script de test unique:

$ scripts/test tests/test_application.py

Pour exécuter le formatage automatique du code:

$ scripts/lint

Enfin, pour exécuter les vérifications de code séparément (elles fonctionnent également dans le cadre de scripts/test), exécuter:

$ scripts/vérification

Documentation; préparation de documents

La page de documentation se trouve sous le dossier docs/.

Pour exécuter un site de documentation localement (utile pour prévisualiser les modifications), utilisez:

$ scripts/docs

Résoudre les problèmes d'échec de build/intégration continue

Une fois que vous avez soumis votre pull request, la suite de tests s'exécutera automatiquement et les résultats seront affichés sur GitHub. Si la suite de tests échoue, vous devrez cliquer sur le lien « Détails » et essayer de comprendre pourquoi la suite de tests a échoué.

Voici quelques façons courantes dont une suite de tests peut échouer:

Check Job a échoué

Cet échec de travail signifie qu 'il y a soit un problème de formatage de code, soit un problème de commentaire de type. vous pouvez regarder la sortie de travail pour comprendre pourquoi elle a échoué, ou l'exécuter dans le shell:

$ scripts/vérification

Il peut être intéressant d'exécuter $ scripts/lint pour essayer de formater automatiquement le code et, si cela réussit, de valider les modifications.

Document Job a échoué

Cet échec de travail signifie que la construction du document a échoué. cela peut se produire pour diverses raisons, telles que Markdown invalide ou une configuration manquante dans mkdocs.yml.

Python 3.X Job a échoué

Cet échec de travail signifie que le test unitaire a échoué ou que tous les chemins de code ne sont pas couverts par le test unitaire.

Si le test échoue, vous verrez ce message sous le rapport de couverture:

=== 1 failed, 435 passed, 1 skipped, 1 xfailed in 11.09s ===

Si le test réussit, mais que la couverture n'atteint pas notre seuil actuel, vous verrez ce message sous le rapport de couverture:

FAIL Required test coverage of 100% not reached. Total coverage: 99.00%

Libération; Libération; Libération

Cette section est destinée aux mainteneurs de Starlette.

Avant de publier une nouvelle version, créez une pull request avec les informations suivantes:

• Une mise à jour du changelog:
  • Nous suivons le format du keepachangelog.
  • compare master avec la dernière version du tag et liste toutes les entrées qui intéressent nos utilisateurs:
    • Ce qui doit être consigné dans le journal des modifications: fonctionnalités ajoutées, modifiées, dépréciées ou supprimées et corrections de bogues.
    • Ce qui ne doit pas être consigné dans le journal des modifications: modifications de la documentation, des tests ou des outils.
    • Essayez de trier les entrées par ordre décroissant d'impact/importance.
    • Soyez concis et au point.»
• Une version boostée: voir __version__.py.

Voir par exemple #1600.

Une fois que les Release PR (PR) ont été fusionnés, créez un nouveau Release qui comprend:

Les versions balisées* telles que 0.13.3. * Publier le titre Version 0.13.3 * La description est copiée du journal des modifications.

Une fois créée, cette version est automatiquement téléchargée sur PyPI.

En cas de problème avec une tâche PyPI, vous pouvez utiliser le script scripts/publish pour publier une version.