{"meta":{"title":"Création et test de Python","intro":"Découvrez comment créer un flux de travail d’intégration continue (CI) pour générer et tester votre projet de Python.","product":"GitHub Actions","breadcrumbs":[{"href":"/fr/actions","title":"GitHub Actions"},{"href":"/fr/actions/tutorials","title":"Tutoriels"},{"href":"/fr/actions/tutorials/build-and-test-code","title":"Générer et tester du code"},{"href":"/fr/actions/tutorials/build-and-test-code/python","title":"Python"}],"documentType":"article"},"body":"# Création et test de Python\n\nDécouvrez comment créer un flux de travail d’intégration continue (CI) pour générer et tester votre projet de Python.\n\n## Introduction\n\nCe guide vous montre comment générer, tester et publier un package Python.\n\nLes exécuteurs hébergés dans GitHub ont un cache d’outils où sont préinstallés des logiciels, notamment Python et PyPy. Vous n’avez donc rien à installer ! Pour obtenir la liste complète des logiciels up-to-date et des versions préinstallées de Python et PyPy, consultez [Exécuteurs hébergés par GitHub](/fr/actions/using-github-hosted-runners/about-github-hosted-runners#supported-software).\n\n## Prérequis\n\nVous devez être familiarisé avec YAML et la syntaxe GitHub Actions. Pour plus d’informations, consultez « [Écriture de workflows](/fr/actions/learn-github-actions) ».\n\nNous vous recommandons d’avoir une compréhension de base des Python et pip. Pour plus d’informations, consultez l’article suivant :\n\n* [Débuter avec Python](https://www.python.org/about/gettingstarted/)\n* [Gestionnaire de paquets pip](https://pypi.org/project/pip/)\n\n## Utilisation d’un modèle de flux de travail Python\n\nPour démarrer rapidement, ajoutez un modèle de workflow au répertoire `.github/workflows` de votre référentiel.\n\nGitHub fournit un modèle de flux de travail pour Python qui doit fonctionner si votre référentiel contient déjà au moins un fichier `.py`. Les sections suivantes de ce guide donnent des exemples de la manière dont vous pouvez personnaliser ce modèle de workflow.\n\n1. Sur GitHub, accédez à la page principale du référentiel.\n\n2. Sous le nom de votre référentiel, cliquez sur ** Actions**.\n\n \n\n3. Si vous disposez déjà d’un workflow dans votre dépôt, cliquez sur **Nouveau workflow**.\n\n4. La page « Choisir un workflow » présente une sélection de modèles de workflow recommandés. Recherchez « application Python ».\n\n5. Dans le flux de travail « application Python », cliquez sur **Configure**.\n\n6. Modifiez le workflow en fonction des besoins. Par exemple, modifiez la version de Python.\n\n7. Cliquez sur **Commiter les changements**.\n\nLe fichier de workflow `python-app.yml` est ajouté au répertoire `.github/workflows` de votre dépôt.\n\n## Spécification d’une version Python\n\nPour utiliser une version préinstallée de Python ou PyPy sur un exécuteur GitHub hébergé, utilisez l’action `setup-python`. Cette action recherche une version spécifique de Python ou PyPy à partir du cache des outils sur chaque exécuteur et ajoute les fichiers binaires nécessaires à `PATH`, qui persiste pour le reste du travail. Si une version spécifique de Python n’est pas préinstallée dans le cache des outils, l’action `setup-python` télécharge et configure la version appropriée à partir du référentiel [`python-versions`](https://github.com/actions/python-versions).\n\nL’utilisation de l’action `setup-python` est la méthode recommandée d’utiliser Python avec GitHub Actions car elle garantit un comportement cohérent entre différents exécuteurs et différentes versions de Python. Si vous utilisez un exécuteur auto-hébergé, vous devez installer Python et l’ajouter à `PATH`. Pour plus d’informations, consultez l’action [`setup-python`](https://github.com/marketplace/actions/setup-python).\n\nLe tableau ci-dessous décrit les emplacements du cache d’outils pour chaque exécuteur hébergé dans GitHub.\n\n
\n\nSi vous utilisez un exécuteur auto-hébergé, vous pouvez configurer l’exécuteur afin qu’il utilise l’action `setup-python` pour gérer vos dépendances. Pour plus d’informations, consultez [Utilisation de setup-python avec un exécuteur auto-hébergé](https://github.com/actions/setup-python#using-setup-python-with-a-self-hosted-runner) dans le fichier README `setup-python`.\n\nGitHub prend en charge la syntaxe du versioning sémantique. Pour plus d’informations, consultez « [Utilisation du versioning sémantique](https://docs.npmjs.com/about-semantic-versioning#using-semantic-versioning-to-specify-update-types-your-package-can-accept) » et « [Spécification du versioning sémantique](https://semver.org/) ».\n\n### Utilisation de plusieurs versions Python\n\nL’exemple suivant utilise une matrice pour le travail afin de configurer plusieurs versions Python. Pour plus d’informations, consultez « [Exécution de variantes de tâches dans un workflow](/fr/actions/using-jobs/using-a-matrix-for-your-jobs) ».\n\n```yaml copy\nname: Python package\n\non: [push]\n\njobs:\n build:\n\n runs-on: ubuntu-latest\n strategy:\n matrix:\n python-version: [\"pypy3.10\", \"3.9\", \"3.10\", \"3.11\", \"3.12\", \"3.13\"]\n\n steps:\n - uses: actions/checkout@v6\n - name: Set up Python ${{ matrix.python-version }}\n uses: actions/setup-python@v5\n with:\n python-version: ${{ matrix.python-version }}\n # You can test your matrix by printing the current Python version\n - name: Display Python version\n run: python -c \"import sys; print(sys.version)\"\n```\n\n### Utilisation d’une version Python spécifique\n\nVous pouvez configurer une version spécifique de Python. Par exemple, 3.12. Vous pouvez également utiliser la syntaxe de versioning sémantique pour obtenir la dernière version mineure. Cet exemple utilise la dernière version mineure de Python 3.\n\n```yaml copy\nname: Python package\n\non: [push]\n\njobs:\n build:\n\n runs-on: ubuntu-latest\n\n steps:\n - uses: actions/checkout@v6\n - name: Set up Python\n # This is the version of the action for setting up Python, not the Python version.\n uses: actions/setup-python@v5\n with:\n # Semantic version range syntax or exact version of a Python version\n python-version: '3.x'\n # Optional - x64 or x86 architecture, defaults to x64\n architecture: 'x64'\n # You can test your matrix by printing the current Python version\n - name: Display Python version\n run: python -c \"import sys; print(sys.version)\"\n```\n\n### Exclusion d’une version\n\nSi vous spécifiez une version de Python qui n’est pas disponible, `setup-python` échoue avec une erreur telle que : `##[error]Version 3.7 with arch x64 not found`. Le message d’erreur mentionne les versions disponibles.\n\nVous pouvez également utiliser le mot clé `exclude` dans votre workflow s’il existe une configuration de Python que vous ne souhaitez pas exécuter. Pour plus d’informations, consultez « [Syntaxe de flux de travail pour GitHub Actions](/fr/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategy) ».\n\n```yaml copy\nname: Python package\n\non: [push]\n\njobs:\n build:\n\n runs-on: ${{ matrix.os }}\n strategy:\n matrix:\n os: [ubuntu-latest, macos-latest, windows-latest]\n python-version: [\"3.9\", \"3.11\", \"3.13\", \"pypy3.10\"]\n exclude:\n - os: macos-latest\n python-version: \"3.11\"\n - os: windows-latest\n python-version: \"3.11\"\n```\n\n### Utilisation de la version Python par défaut\n\nNous vous recommandons d’utiliser `setup-python` pour configurer la version de Python utilisée dans vos flux de travail, car elle permet de rendre vos dépendances explicites. Si vous n'utilisez pas `setup-python`, la version par défaut de Python définie dans `PATH` est utilisée dans un interpréteur de commandes lorsque vous appelez `python`. La version par défaut de Python varie entre les exécuteurs hébergés par GitHub, ce qui peut entraîner des modifications inattendues ou utiliser une version plus ancienne que prévu.\n\n| Exécuteur hébergé dans GitHub | Description |\n| ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Ubuntu | Les exécuteurs Ubuntu ont plusieurs versions du système Python installées sous `/usr/bin/python` et `/usr/bin/python3`. Les versions Python fournies avec Ubuntu sont en plus des versions que GitHub installe dans le cache des outils. |\n| Windows | À l’exclusion des versions d’Python qui se trouvent dans le cache des outils, Windows n’est pas fournie avec une version équivalente du Python système. Pour maintenir un comportement cohérent avec les autres exécuteurs et permettre à Python d’être utilisé immédiatement sans l’action `setup-python`, GitHub ajoute quelques versions à `PATH` à partir du cache d’outils. |\n| macOS | Les exécuteurs macOS ont plusieurs versions du système Python installées, en plus des versions qui font partie du cache des outils. Les versions Python système se trouvent dans le répertoire `/usr/local/Cellar/python/*`. |\n\n## Installer les dépendances\n\nLe gestionnaire de package pip est installé sur les exécuteurs hébergés dans GitHub. Vous pouvez utiliser pip pour installer des dépendances à partir du registre de package PyPI avant de générer et de tester votre code. Par exemple, le code YAML ci-dessous installe ou met à niveau le programme d’installation du package `pip`, ainsi que les packages `setuptools` et `wheel`.\n\nVous pouvez également mettre en cache vos dépendances pour accélérer vos exécutions de workflow. Pour plus d’informations, consultez « [Référence sur la mise en cache des dépendances](/fr/actions/using-workflows/caching-dependencies-to-speed-up-workflows) ».\n\n```yaml copy\nsteps:\n- uses: actions/checkout@v6\n- name: Set up Python\n uses: actions/setup-python@v5\n with:\n python-version: '3.x'\n- name: Install dependencies\n run: python -m pip install --upgrade pip setuptools wheel\n```\n\n### Fichier de spécifications\n\nAprès avoir mis à jour `pip`, Une étape suivante typique est l'installation des dépendances à partir de `requirements.txt`. Pour plus d’informations, consultez [pip](https://pip.pypa.io/en/stable/cli/pip_install/#example-requirements-file).\n\n```yaml copy\nsteps:\n- uses: actions/checkout@v6\n- name: Set up Python\n uses: actions/setup-python@v5\n with:\n python-version: '3.x'\n- name: Install dependencies\n run: |\n python -m pip install --upgrade pip\n pip install -r requirements.txt\n```\n\n### Mise en cache des dépendances\n\nVous pouvez mettre en cache et restaurer les dépendances à l’aide de l’[action `setup-python`](https://github.com/actions/setup-python).\n\nL’exemple suivant met en cache les dépendances pour pip.\n\n```yaml copy\nsteps:\n- uses: actions/checkout@v6\n- uses: actions/setup-python@v5\n with:\n python-version: '3.12'\n cache: 'pip'\n- run: pip install -r requirements.txt\n- run: pip test\n```\n\nPar défaut, l’action `setup-python` recherche le fichier de dépendances (`requirements.txt` pour pip, `Pipfile.lock` pour pipenv ou `poetry.lock` pour poetry) dans l’ensemble du dépôt. Pour plus d’informations, consultez [Mise en cache des dépendances de packages](https://github.com/actions/setup-python#caching-packages-dependencies) dans le fichier LISEZ-MOI de `setup-python`.\n\nSi vous avez une exigence particulière ou si vous avez besoin d’un contrôle plus précis pour la mise en cache, vous pouvez utiliser l’[action `cache`](https://github.com/marketplace/actions/cache). Pip met en cache les dépendances à différents emplacements, selon le système d’exploitation du système exécutant. Le chemin que vous devez mettre en cache peut différer de celui de l’exemple Ubuntu ci-dessus, selon le système d’exploitation que vous utilisez. Pour plus d’informations, consultez [Python exemples de mise en cache](https://github.com/actions/cache/blob/main/examples.md#python---pip) dans le référentiel d’actions `cache`.\n\n## Test de votre code\n\nVous pouvez utiliser les mêmes commandes que celles que vous utilisez localement pour générer et tester votre code.\n\n### Effectuer des tests avec pytest et pytest-cov\n\nCet exemple installe ou met à niveau `pytest` et `pytest-cov`. Les tests sont ensuite exécutés et une sortie est générée au format JUnit pendant que les résultats de couverture du code sont générés dans Cobertura. Pour plus d’informations, consultez [JUnit](https://junit.org/junit5/) et [Cobertura](https://cobertura.github.io/cobertura/).\n\n```yaml copy\nsteps:\n- uses: actions/checkout@v6\n- name: Set up Python\n uses: actions/setup-python@v5\n with:\n python-version: '3.x'\n- name: Install dependencies\n run: |\n python -m pip install --upgrade pip\n pip install -r requirements.txt\n- name: Test with pytest\n run: |\n pip install pytest pytest-cov\n pytest tests.py --doctest-modules --junitxml=junit/test-results.xml --cov=com --cov-report=xml --cov-report=html\n```\n\n### Utilisation de Ruff pour le linting et/ou la mise en forme du code\n\nL’exemple suivant installe ou met à niveau `ruff`, et l’utilise pour effectuer le linting de tous les fichiers. Pour plus d’informations, consultez [Ruff](https://docs.astral.sh/ruff).\n\n```yaml copy\nsteps:\n- uses: actions/checkout@v6\n- name: Set up Python\n uses: actions/setup-python@v5\n with:\n python-version: '3.x'\n- name: Install the code linting and formatting tool Ruff\n run: pipx install ruff\n- name: Lint code with Ruff\n run: ruff check --output-format=github --target-version=py39\n- name: Check code formatting with Ruff\n run: ruff format --diff --target-version=py39\n continue-on-error: true\n```\n\nL’étape de mise en forme est configurée avec `continue-on-error: true`. Cela empêche le workflow d’échouer si l’étape de mise en forme ne réussit pas. Une fois que vous avez résolu toutes les erreurs de mise en forme, vous pouvez supprimer cette option afin que le workflow intercepte de nouveaux problèmes.\n\n### Exécution de tests avec tox\n\nAvec GitHub Actions, vous pouvez exécuter des tests avec tox et répartir les tâches entre plusieurs travaux. Vous devez appeler tox à l'aide de l'option `-e py` pour choisir la version de Python dans votre `PATH`, au lieu de spécifier une version spécifique. Pour plus d’informations, consultez [tox](https://tox.readthedocs.io/en/latest/).\n\n```yaml copy\nname: Python package\n\non: [push]\n\njobs:\n build:\n\n runs-on: ubuntu-latest\n strategy:\n matrix:\n python: [\"3.9\", \"3.11\", \"3.13\"]\n\n steps:\n - uses: actions/checkout@v6\n - name: Setup Python\n uses: actions/setup-python@v5\n with:\n python-version: ${{ matrix.python }}\n - name: Install tox and any other packages\n run: pip install tox\n - name: Run tox\n # Run tox using the version of Python in `PATH`\n run: tox -e py\n```\n\n## Empaquetage des données de workflow en tant qu’artefacts\n\nVous pouvez charger des artefacts à afficher une fois un workflow terminé. Par exemple, vous devrez peut-être enregistrer des fichiers journaux, des vidages principaux, des résultats de test ou des captures d’écran. Pour plus d’informations, consultez « [Stocker et partager des données avec les artefacts de workflow](/fr/actions/using-workflows/storing-workflow-data-as-artifacts) ».\n\nL’exemple suivant montre comment utiliser l’action `upload-artifact` pour archiver les résultats des tests obtenus par l’exécution de `pytest`. Pour plus d’informations, consultez l’action [`upload-artifact`](https://github.com/actions/upload-artifact).\n\n```yaml copy\nname: Python package\n\non: [push]\n\njobs:\n build:\n\n runs-on: ubuntu-latest\n strategy:\n matrix:\n python-version: [\"3.9\", \"3.10\", \"3.11\", \"3.12\", \"3.13\"]\n\n steps:\n - uses: actions/checkout@v6\n - name: Setup Python # Set Python version\n uses: actions/setup-python@v5\n with:\n python-version: ${{ matrix.python-version }}\n # Install pip and pytest\n - name: Install dependencies\n run: |\n python -m pip install --upgrade pip\n pip install pytest\n - name: Test with pytest\n run: pytest tests.py --doctest-modules --junitxml=junit/test-results-${{ matrix.python-version }}.xml\n - name: Upload pytest test results\n uses: actions/upload-artifact@v4\n with:\n name: pytest-results-${{ matrix.python-version }}\n path: junit/test-results-${{ matrix.python-version }}.xml\n # Use always() to always run this step to publish test results when there are test failures\n if: ${{ always() }}\n```\n\n## Publication sur PyPI\n\nVous pouvez configurer votre flux de travail pour publier votre package de Python sur PyPI une fois que vos tests CI réussissent. Cette section montre comment utiliser GitHub Actions pour charger votre package sur PyPI chaque fois que vous publiez une version. Pour plus d’informations, consultez « [Gestion des versions dans un référentiel](/fr/repositories/releasing-projects-on-github/managing-releases-in-a-repository) ».\n\nL’exemple de flux de travail ci-dessous utilise l’[éditeur approuvé](https://docs.pypi.org/trusted-publishers/) pour s’authentifier auprès de PyPI, ce qui élimine la nécessité d’un jeton d’API configuré manuellement.\n\n```yaml copy\n# Ce workflow utilise des actions qui ne sont pas certifiées par GitHub.\n# Elles sont fournies par un tiers et régies par\n# des conditions d’utilisation du service, une politique de confidentialité et un support distincts.\n# documentation en ligne.\n\n# GitHub recommande d’épingler les actions à un SHA de commit.\n# Pour obtenir une version plus récente, vous devez mettre à jour le SHA.\n# Vous pouvez également référencer une balise ou une branche, mais l’action peut changer sans avertissement.\n\nname: Upload Python Package\n\non:\n release:\n types: [published]\n\npermissions:\n contents: read\n\njobs:\n release-build:\n runs-on: ubuntu-latest\n\n steps:\n - uses: actions/checkout@v6\n\n - uses: actions/setup-python@v5\n with:\n python-version: \"3.x\"\n\n - name: Build release distributions\n run: |\n # NOTE: put your own distribution build steps here.\n python -m pip install build\n python -m build\n\n - name: Upload distributions\n uses: actions/upload-artifact@v4\n with:\n name: release-dists\n path: dist/\n\n pypi-publish:\n runs-on: ubuntu-latest\n\n needs:\n - release-build\n\n permissions:\n # IMPORTANT: this permission is mandatory for trusted publishing\n id-token: write\n\n # Dedicated environments with protections for publishing are strongly recommended.\n environment:\n name: pypi\n # OPTIONAL: uncomment and update to include your PyPI project URL in the deployment status:\n # url: https://pypi.org/p/YOURPROJECT\n\n steps:\n - name: Retrieve release distributions\n uses: actions/download-artifact@v5\n with:\n name: release-dists\n path: dist/\n\n - name: Publish release distributions to PyPI\n uses: pypa/gh-action-pypi-publish@6f7e8d9c0b1a2c3d4e5f6a7b8c9d0e1f2a3b4c5d\n```\n\nPour plus d’informations sur ce workflow, y compris les paramètres PyPI nécessaires, consultez [Configuration d’OpenID Connect dans PyPl](/fr/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-pypi)."}