{"meta":{"title":"Gestion des actions personnalisées","intro":"Découvrez comment créer et gérer vos propres actions et personnaliser les actions partagées par la GitHub communauté.","product":"GitHub Actions","breadcrumbs":[{"href":"/fr/enterprise-cloud@latest/actions","title":"GitHub Actions"},{"href":"/fr/enterprise-cloud@latest/actions/how-tos","title":"Guides pratiques"},{"href":"/fr/enterprise-cloud@latest/actions/how-tos/create-and-publish-actions","title":"Créer et publier des actions"},{"href":"/fr/enterprise-cloud@latest/actions/how-tos/create-and-publish-actions/manage-custom-actions","title":"Gérer les actions personnalisées"}],"documentType":"article"},"body":"# Gestion des actions personnalisées\n\nDécouvrez comment créer et gérer vos propres actions et personnaliser les actions partagées par la GitHub communauté.\n\n## Choisir un emplacement pour votre action\n\nSi vous développez une action pour que d’autres personnes l’utilisent, nous vous recommandons de stocker l’action dans son propre dépôt au lieu de la regrouper avec d’autres codes d’application. Ceci vous permet de versionner, d’effectuer le suivi et de publier l’action comme vous le feriez pour n’importe quel autre logiciel.\n\nLe stockage d’une action dans son propre dépôt facilite la découverte de l’action par la GitHub communauté, réduit l’étendue de la base de code pour les développeurs qui corrigent les problèmes et étend l’action, et dissocie le contrôle de version de l’action de l’autre code d’application.\n\nPour partager des actions dans votre entreprise sans publier publiquement les actions, vous pouvez stocker les actions dans un référentiel interne, puis configurer le référentiel pour autoriser l’accès aux flux de travail dans d’autres référentiels appartenant à GitHub Actions la même organisation ou par n’importe quelle organisation de l’entreprise. Pour plus d’informations, consultez « [Partage d’actions et de workflows au sein de votre entreprise](/fr/enterprise-cloud@latest/actions/how-tos/reuse-automations/share-with-your-enterprise) ».\n\nSi vous créez une action que vous n’envisagez pas de mettre à la disposition d’autres personnes, vous  pouvez stocker les fichiers de l’action dans n’importe quel emplacement de votre dépôt. Si vous prévoyez de combiner le code des actions, des workflows et de l’application dans un même dépôt, nous vous recommandons de stocker les actions dans le référentiel `.github`. Par exemple : `.github/actions/action-a` et `.github/actions/action-b`.\n\n## Assurer la compatibilité avec les autres plateformes\n\nDe nombreuses personnes accèdent GitHub à un domaine autre que GitHub.com, tel qu’un GHE.com domaine personnalisé pour GitHub Enterprise Server.\n\nPour vous assurer que votre action est compatible avec d’autres plateformes, n’utilisez aucune référence codée en dur aux URL d’API telles que `https://api.github.com`. Au lieu de cela, vous pouvez :\n\n* Utiliser des variables d’environnement (consultez [Références des variables](/fr/enterprise-cloud@latest/actions/reference/workflows-and-actions/variables#default-environment-variables)) :\n\n  * Pour l’API REST, utilisez la variable d’environnement `GITHUB_API_URL`.\n  * Pour GraphQL, utilisez la variable d’environnement `GITHUB_GRAPHQL_URL`.\n\n* Utilisez un kit de ressources tel que [`@actions/github`](https://github.com/actions/toolkit/tree/main/packages/github), qui peut définir automatiquement les URL correctes.\n\n## Utilisation de la gestion des versions pour les actions\n\nSi vous développez une action pour que d’autres personnes l’utilisent, nous vous recommandons d’utiliser la gestion des mises en production afin de contrôler la façon dont vous distribuez les mises à jour. Les utilisateurs peuvent s’attendre à ce que la version corrective d’une action inclue les correctifs critiques et les correctifs de sécurité nécessaires, tout en restant compatibles avec leurs workflows existants. Il est conseillé de publier une nouvelle version majeure chaque fois que vos modifications affectent la compatibilité.\n\nDans cette approche de gestion des mises en production, les utilisateurs ne doivent pas référencer la branche par défaut d’une action, car celle-ci est susceptible de contenir le code le plus récent et donc, d’être instable. Vous pouvez plutôt recommander à vos utilisateurs de spécifier une version majeure lorsqu’ils utilisent votre action, et les diriger vers une version plus spécifique uniquement s’ils rencontrent des problèmes.\n\nPour utiliser une version d’action spécifique, les utilisateurs peuvent configurer leur GitHub Actions flux de travail pour cibler une balise, une sha de validation ou une branche nommée pour une version.\n\n### Utilisation d’étiquettes pour la gestion des mises en production\n\n> \\[!NOTE] Si vous avez activé les versions immuables pour aider à prévenir les attaques de la chaîne d'approvisionnement et les modifications accidentelles de vos versions, consultez plutôt [Utilisation de versions immuables et de balises pour gérer les versions des actions](/fr/enterprise-cloud@latest/actions/how-tos/create-and-publish-actions/using-immutable-releases-and-tags-to-manage-your-actions-releases).\n\nNous vous recommandons d’utiliser des étiquettes pour la gestion des mises en production des actions. Cette approche permet aux utilisateurs de facilement distinguer les versions majeures des versions mineures.\n\n1. Développez et validez une version sur une branche de version (par exemple, `release/v1`).\n2. Créez une version avec une balise de version en utilisant la gestion sémantique de version (par exemple, `v1.0.1`). Pour plus d’informations, consultez « [Gestion des versions dans un référentiel](/fr/enterprise-cloud@latest/repositories/releasing-projects-on-github/managing-releases-in-a-repository) ».\n3. Déplacez la balise de version majeure (par exemple `v1`) pour qu’elle indique la référence Git de la publication actuelle. Pour plus d’informations, consultez [Bases de Git - balisage](https://git-scm.com/book/en/v2/Git-Basics-Tagging).\n4. Introduisez une nouvelle balise de version majeure (par exemple, `v2`) pour les modifications qui perturberont les workflows existants, telles que la modification des entrées d’une action.\n\n#### Syntaxe dédiée au référencement des balises\n\nCet exemple indique comment un utilisateur peut référencer une étiquette de version principale :\n\n```yaml\nsteps:\n    - uses: actions/javascript-action@v1\n```\n\nCet exemple montre comment un utilisateur peut référencer une étiquette de version corrective :\n\n```yaml\nsteps:\n    - uses: actions/javascript-action@v1.0.1\n```\n\n### Utilisation de branches pour la gestion des mises en production\n\nSi vous préférez utiliser des noms de branche pour la gestion des mises en production, cet exemple montre comment référencer une branche nommée :\n\n```yaml\nsteps:\n    - uses: actions/javascript-action@v1-beta\n```\n\n### Utilisation du SHA d’un commit pour la gestion des mises en production\n\nChaque commit Git reçoit une valeur de SHA calculée, qui est unique et non modifiable. Les utilisateurs de votre action peuvent préférer s’appuyer sur la valeur SHA d’un commit, car cette approche peut être plus fiable que la spécification d’une étiquette, qui peut être supprimée ou déplacée. Toutefois, cela signifie que les utilisateurs ne recevront pas les prochaines mises à jour de l’action. Vous devez utiliser la valeur SHA complète d’un commit et non une valeur abrégée.\n\n```yaml\nsteps:\n    - uses: actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f\n```\n\n## Création d’un fichier README pour votre action\n\nNous vous recommandons de créer un fichier README pour aider les utilisateurs à utiliser votre action. Vous pouvez inclure les informations suivantes dans votre `README.md` :\n\n* Une description détaillée de ce que fait l’action\n* Les arguments d’entrée et de sortie obligatoires\n* Les arguments d’entrée et de sortie facultatifs\n* Les secrets utilisés par l’action\n* Les variables d’environnement utilisées par l’action\n* Un exemple d’utilisation de votre action dans un workflow"}