Publication et gestion des actions

Introduction

Après avoir créé une action, vous souhaiterez probablement publier d’autres fonctionnalités tout en utilisant les contributions de la communauté. Ce tutoriel décrit un exemple de processus que vous pouvez suivre pour publier et gérer des actions open source. L'exemple :

• Tire parti de GitHub Actions pour l’intégration continue, les mises à jour des dépendances, la gestion des mises en production et l’automatisation des tâches.
• Garantit la confiance grâce aux tests automatisés et aux badges de build.
• Indique comment l’action peut être utilisée, idéalement dans le cadre d’un workflow plus étendu.
• Signale le type de contributions de la communauté qui sont les bienvenues. (par exemple : problèmes, demandes de tirage (pull request) ou rapports sur les vulnérabilités)

Pour obtenir un exemple d’application de ce processus, consultez actions/javascript-action.

Développement et publication des actions

Dans cette section, nous allons aborder un exemple de processus de développement et de publication d’actions, et nous verrons comment utiliser GitHub Actions pour automatiser le processus.

À propos des actions JavaScript

Les actions JavaScript sont des dépôts Node.js contenant des métadonnées. Toutefois, les actions JavaScript ont des propriétés supplémentaires par rapport aux projets Node.js traditionnels :

• Les packages dépendants sont commités en même temps que le code, généralement dans un format compilé et minifié. Cela signifie que les builds automatisées et les contributions sécurisées de la communauté sont importantes.

• De nombreuses actions utilisent les API de GitHub et les API tierces. Nous encourageons donc à effectuer des tests robustes de bout en bout.

Configuration des workflows GitHub Actions

Pour prendre en charge le processus de développement dans la section suivante, ajoutez deux workflows GitHub Actions à votre dépôt :

1. Ajoutez un workflow qui se déclenche lorsqu’un commit est poussé (push) à une branche de fonctionnalité ou à main, ou lorsqu’une demande de tirage (pull request) est créée. Configurez le workflow pour exécuter vos tests unitaires et vos tests d’intégration. Pour obtenir un exemple, consultez ce workflow.
2. Ajoutez un workflow qui se déclenche lorsqu’une version est publiée ou modifiée. Configurez le workflow de sorte que les étiquettes sémantiques soient en place. Vous pouvez utiliser une action comme JasonEtco/build-and-tag-action pour compiler et regrouper le fichier JavaScript et les métadonnées, et pour pousser les étiquettes sémantiques des versions majeures, mineures et correctives. Pour plus d’informations sur les étiquettes sémantiques, consultez « À propos de la gestion sémantique de version ».

Exemple de processus de développement

Voici un exemple de processus que vous pouvez suivre pour exécuter automatiquement des tests, créer une version , puis publier votre action.

1. Effectuez le travail relatif aux fonctionnalités dans les branches de chaque flux GitHub. Pour plus d’informations, consultez « GitHub flow ».

   • Chaque fois qu’un commit est poussé vers la branche de fonctionnalité, votre workflow de test exécute automatiquement les tests.

2. Créez des demandes de tirage pour la branche main afin de lancer une discussion et une révision, et d’effectuer une fusion lorsque vous êtes prêt.

   • Lorsqu’une demande de tirage est effectuée à partir d’une branche ou d’une duplication (fork), votre workflow de test réexécute les tests, cette fois avec le commit de fusion.

   • Remarque : Pour des raisons de sécurité, les workflows déclenchés par pull_request à partir de duplications ont des autorisations GITHUB_TOKEN limitées et n’ont pas accès aux secrets. Si vos tests ou d’autres workflows déclenchés lors de la demande de tirage nécessitent un accès aux secrets, utilisez un autre événement comme un déclencheur manuel ou un pull_request_target. Pour plus d’informations, consultez « Événements qui déclenchent des flux de travail ».

3. Créez une version étiquetée sémantiquement. Pour plus d’informations, consultez « Gestion des mises en production dans un référentiel.

   • Lorsqu’une version est publiée ou modifiée, votre workflow de version s’occupe automatiquement de la compilation et de l’ajustement des étiquettes.

   • Nous vous recommandons de créer des versions à l’aide d’étiquettes versionnées sémantiquement (par exemple v1.1.3) et de maintenir à jour les étiquettes des versions majeures (v1) et mineures (v1.1) à l’aide du dernier commit approprié. Pour plus d’informations, consultez « À propos des actions personnalisées » et « À propos de la gestion sémantique de version ».

Résultats

Contrairement à d’autres stratégies automatisées de gestion des mises en production, ce processus choisit intentionnellement de ne pas commiter les dépendances dans la branche main, mais seulement les commits des versions étiquetées. Ainsi, vous encouragez les utilisateurs de votre action à référencer des étiquettes nommées ou des sha, et vous contribuez à garantir la sécurité des demandes de tirage tierces en effectuant la génération vous-même lors du processus de publication.

Avec l’utilisation des versions sémantiques, les utilisateurs de vos actions peuvent épingler leurs workflows à une version et savoir ainsi qu’ils continueront à recevoir les dernières fonctionnalités stables et non cassantes, selon leur niveau de confort.

Collaborer avec la communauté

GitHub Enterprise Server fournit des outils et des guides qui vous aideront à travailler avec la communauté open source. Voici quelques outils que nous vous recommandons de configurer pour une bonne communication bidirectionnelle. En envoyant les signaux suivants à la communauté, vous encouragez les autres à utiliser, modifier et contribuer à votre action :

• Gérez un fichier README avec un grand nombre d’exemples d’utilisation et de conseils. Pour plus d’informations, consultez « À propos des README ».
• Incluez un badge d’état de workflow dans votre fichier README. Pour plus d’informations, consultez « Adding a workflow status badge ». Consultez également shields.io pour en savoir plus sur les autres badges que vous pouvez ajouter.
• Maintenez à jour l’état des problèmes en utilisant des actions comme actions/stale.

Pour aller plus loin

Voici quelques exemples où des modèles similaires sont utilisés :

• github/super-linter
• octokit/request-action
• actions/javascript-action