Compétences github-actions-templates
📦

github-actions-templates

Sûr

Créer des workflows CI/CD GitHub Actions

Également disponible depuis: wshobson

Les équipes ont du mal à créer des workflows GitHub Actions sécurisés et prêts pour la production à partir de zéro. Cette compétence fournit des modèles testés pour tester, construire et déployer des applications avec une gestion appropriée des secrets et des portes d'approbation.

Prend en charge: Claude Codex Code(CC)
🥉 75 Bronze
1

Télécharger le ZIP du skill

2

Importer dans Claude

Allez dans Paramètres → Capacités → Skills → Importer un skill

3

Activez et commencez à utiliser

Tester

Utilisation de "github-actions-templates". Créez un workflow de test pour un projet Python qui s'exécute sur Ubuntu et macOS avec Python 3.9 à 3.12

Résultat attendu:

Un fichier YAML de workflow complet avec une stratégie matricielle testant 8 combinaisons (2 OS x 4 versions Python), incluant la mise en cache des dépendances, l'exécution pytest, et le téléversement de couverture vers Codecov.

Utilisation de "github-actions-templates". Construisez et poussez une image Docker lorsqu'un nouveau tag de version est créé

Résultat attendu:

Un workflow qui se déclenche sur les tags de version sémantique, se connecte à GitHub Container Registry en utilisant GITHUB_TOKEN, construit l'image avec des tags versionnés, et pousse avec des métadonnées pour le suivi.

Audit de sécurité

Sûr
v1 • 2/25/2026

This skill is documentation-only containing GitHub Actions YAML workflow templates. All static analysis findings are false positives: the detected 'external_commands' are YAML run: syntax in markdown code blocks, 'network' references are URL configuration values, 'filesystem' patterns are reusable workflow references, and 'env_access' patterns are GitHub Actions secret syntax (${{ secrets.* }}). No executable code, no prompt injection attempts, and no security risks detected. The skill teaches legitimate DevOps practices including proper secret handling and secure workflow patterns.

1
Fichiers analysés
348
Lignes analysées
0
résultats
1
Total des audits
Aucun problème de sécurité trouvé
Audité par: claude

Score de qualité

38
Architecture
100
Maintenabilité
87
Contenu
50
Communauté
100
Sécurité
100
Conformité aux spécifications

Ce que vous pouvez construire

Configuration CI/CD pour startup

Établir rapidement des pipelines de test et de déploiement professionnels pour un nouveau projet logiciel sans expertise approfondie de GitHub Actions.

Standardisation des workflows en entreprise

Créer des modèles de workflows cohérents et sécurisés across plusieurs dépôts avec des templates de workflow réutilisables et des processus d'approbation.

Automatisation pour projets open source

Configurer des tests automatisés sur plusieurs systèmes d'exploitation et versions de runtime pour assurer une large compatibilité.

Essayez ces prompts

Workflow de test de base
Créez un workflow GitHub Actions qui exécute les tests à chaque pull request vers la branche main. Le projet utilise Node.js avec npm. Incluez la mise en cache des dépendances et téléversez les rapports de couverture de tests.
Build et déploiement Docker
Générez un workflow qui construit une image Docker sur push vers main, la taggue avec le SHA git et le tag de version, la pousse vers GitHub Container Registry, et déploie vers un environnement de staging. Incluez des permissions appropriées et la gestion des secrets.
Déploiement multi-environnements
Créez un workflow de déploiement avec des environnements staging et production séparés. Les déploiements en production doivent nécessiter une approbation manuelle. Incluez des notifications Slack pour le succès et l'échec du déploiement, et une capacité de rollback.
Pipeline de scanning de sécurité
Construisez un workflow de sécurité complet qui exécute Trivy pour le scanning de vulnérabilités, Snyk pour les vérifications de dépendances, et CodeQL pour l'analyse de code. Téléversez tous les résultats dans l'onglet Sécurité GitHub et échouez le workflow sur les vulnérabilités critiques.

Bonnes pratiques

  • Épinglez les versions d'actions à des versions majeures spécifiques (par ex. @v4) au lieu de @latest ou @main pour prévenir les changements cassants inattendus et les attaques de la chaîne d'approvisionnement
  • Utilisez GitHub Secrets pour toutes les valeurs sensibles incluant les clés API, tokens et identifiants - ne codez jamais en dur les secrets dans les fichiers de workflow
  • Implémentez les permissions minimales requises en utilisant le bloc permissions et utilisez les règles de protection d'environnement avec des réviseurs requis pour les déploiements en production

Éviter

  • Utiliser @latest ou des références de branche pour les actions tierces qui peuvent introduire des changements cassants ou des vulnérabilités de sécurité sans préavis
  • Stocker des identifiants ou tokens directement dans les fichiers de workflow ou le code du dépôt au lieu d'utiliser GitHub Secrets pour toutes les valeurs sensibles
  • Exécuter du code non fiable depuis des pull requests de forks avec des permissions en écriture qui pourraient exposer des secrets ou compromettre l'environnement CI

Foire aux questions

Comment configurer des secrets pour mes workflows GitHub Actions ?
Naviguez vers les paramètres de votre dépôt > Secrets and variables > Actions. Cliquez sur 'New repository secret' et ajoutez le nom et la valeur de votre secret. Référencez les secrets dans les workflows en utilisant la syntaxe ${{ secrets.SECRET_NAME }}.
Quelle est la différence entre jobs et steps dans GitHub Actions ?
Les jobs sont des unités de workflow de niveau supérieur qui s'exécutent sur des runners séparés et peuvent s'exécuter en parallèle. Les steps sont des commandes individuelles ou des actions au sein d'un job qui s'exécutent séquentiellement sur le même runner.
Comment puis-je exiger une approbation avant de déployer en production ?
Configurez un environnement protégé dans les paramètres du dépôt > Environments. Ajoutez des réviseurs requis à l'environnement de production. Référencez cet environnement dans votre workflow en utilisant la clé 'environment' pour appliquer les portes d'approbation.
Puis-je réutiliser des workflows across plusieurs dépôts ?
Oui. Créez des workflows réutilisables dans un dépôt central en utilisant le trigger workflow_call. D'autres dépôts peuvent appeler ces workflows en utilisant le mot-clé 'uses' avec le chemin du dépôt et le nom de fichier du workflow.
Comment mettre en cache les dépendances pour accélérer les workflows ?
Utilisez l'action actions/cache ou la mise en cache intégrée dans les actions de setup comme actions/setup-node avec l'input 'cache'. Spécifiez le hash du fichier de dépendances comme clé de cache pour invalider le cache quand les dépendances changent.
Que sont les runners auto-hébergés et quand dois-je les utiliser ?
Les runners auto-hébergés sont des machines que vous gérez qui exécutent des jobs de workflow. Utilisez-les pour des charges de travail sensibles nécessitant un accès au réseau interne, du matériel spécialisé, ou quand les limites des runners hébergés par GitHub sont insuffisantes.

Détails du développeur

Structure de fichiers

📄 SKILL.md