Le projet open source github-slug-action, créé initialement pour normaliser les noms de branches dans GitHub Actions, s'est imposé comme un outil incontournable de CI/CD avec plus de 11 700 utilisations actives. Cette GitHub Action transforme intelligemment des noms de branches complexes (comme feature/ma-Super_BRANCHE) en formats standardisés, facilitant ainsi les déploiements automatisés et la gestion des workflows CI/CD :
steps:
- name: Enhanced GitHub environment variables
uses: rlespinasse/github-slug-action@v5
- name: Print slug variables
run: |
echo "Repository: ${{ env.GITHUB_REPOSITORY_SLUG }}"
echo "Branch Point: ${{ env.GITHUB_REF_POINT }}"
echo "Branch Ref: ${{ env.GITHUB_REF_SLUG }}"
echo "SHA: ${{ env.GITHUB_SHA_SHORT }}"
shell: bash
Le début de l'aventure GitHub Action
Tout a commencé le 6 novembre 2019, quelques jours seulement avant la sortie officielle de GitHub Actions (13 novembre 2019). À cette époque, la communauté des développeurs découvrait le potentiel de cette nouvelle plateforme d'automatisation.
Suite au tweet d'un collègue chez SFEIR exprimant sa frustration face à l'absence d'une solution simple pour normaliser les noms de branches, j'ai relevé le défi de créer ma première GitHub Action open-source :
steps:
- name: Enhanced GitHub environment variables
uses: rlespinasse/github-slug-action@master
- name: Deployment of my project
run: ./deploy.sh --url-prefix "myproject-${GITHUB_REF_SLUG}"
shell: bash
L'évolution guidée par la communauté
En tant que mainteneur unique de github-slug-action, j'ai vu l'action évoluer à travers de nombreux cas d'utilisation innovants. Aujourd'hui, plus de 11 700 utilisateurs l'utilisent notamment pour :
- Déployer des environnements de prévisualisation uniques pour chaque branche de développement
- Générer automatiquement des noms de conteneurs Docker basés sur les branches
- Créer des URLs de staging dynamiques pour faciliter les revues de code
Cette confiance est partagée par un écosystème diversifié d'organisations :
- Des géants de la technologie comme Microsoft, AWS, et HuggingFace
- Des leaders du commerce international tels qu'ADEO/Leroy Merlin, Decathlon, Schneider Electric, et Tencent
- Des acteurs de l'éducation numérique comme Moodle
- Des innovateurs technologiques incluant Elastic (recherche), Kestra.io (orchestration de données), et Workadventure (événements virtuels)
- Des entreprises de télécommunications majeures comme Ericsson et Telefónica
- Des médias de référence dont The Guardian
- Des spécialistes du matériel informatique tels que QMK et Keychron (claviers)
- Des institutions gouvernementales, notamment le Ministère de la santé
Le premier Breaking Change
L'évolution du projet s'est poursuivie lorsqu'un développeur a soulevé une problématique intéressante via une issue GitHub. Sa requête concernait l'adaptation de l'action pour une utilisation dans un système de versioning automatique, suggérant un nouveau cas d'usage pertinent.
Cette demande a conduit à une réflexion sur la stratégie de normalisation des variables d'environnement. L'objectif était simple :
- Répondre au besoin de versioning automatique
- Conserver la compatibilité avec les utilisations existantes
La version 2.0.0, publiée en avril 2020, a apporté une solution pragmatique avec une double approche de normalisation, comme le montrent ces exemples :
### Dans le workflow de publication d'une release
steps:
- name: Enhanced GitHub environment variables
uses: rlespinasse/github-slug-action@2.0.0
- name: Versionning of my project
run: ./publish-release.sh --version "${GITHUB_REF_SLUG}"
shell: bash
### Dans le workflow de deploiement
steps:
- name: Enhanced GitHub environment variables
uses: rlespinasse/github-slug-action@2.0.0
- name: Deployment of my project
run: ./deploy.sh --url-prefix "myproject-${GITHUB_REF_SLUG_URL}-${GITHUB_SHA_SHORT}"
shell: bash
Cette évolution illustre la capacité du projet à s'adapter aux besoins des utilisateurs tout en maintenant sa stabilité.
Les contributions de la communauté
Les retours des utilisateurs ont naturellement fait évoluer le projet.
Les issues ont apporté des suggestions d'amélioration que je n'avais pas envisagées. Les pull-requests ont permis d'ajouter des fonctionnalités utiles, comme une meilleure gestion des caractères spéciaux ou des optimisations de performance.
Une collaboration entre collègues
L'action a trouvé son utilité auprès de mes collègues Sfeirians qui l'ont intégrée dans leurs projets clients. Antoine Méausoone, dont la demande initiale a inspiré ce projet, est passé de premier utilisateur à co-mainteneur. Sa contribution a été précieuse pour le projet.
Surfer sur les vagues du changement
L'évolution de GitHub Actions a marqué des tournants décisifs dans le développement de notre action. Chaque mise à jour majeure de la plateforme a été l'occasion de repenser et d'améliorer nos fonctionnalités.
La première transformation significative fut la migration de Docker vers Node. Initialement conçue comme une action Docker, github-slug-action a dû s'adapter pour répondre à la demande croissante de support multi-OS. Cette transition, bien que technique, a permis d'améliorer significativement les performances et la portabilité de l'action. La version 3 fut lancée en octobre 2020 :
run-on: macos-latest
steps:
- name: Enhanced GitHub environment variables
uses: rlespinasse/github-slug-action@v3
- name: Print slug variables
run: |
echo "Repository: ${{ env.GITHUB_REPOSITORY_SLUG }}"
echo "Branch: ${{ env.GITHUB_REF_SLUG }}"
echo "SHA: ${{ env.GITHUB_SHA_SHORT }}"
shell: bash
L'amélioration des actions composites a ouvert de nouvelles perspectives, donnant naissance à deux projets complémentaires :
Ces nouveaux projets ont permis de convertir github-slug-action en action composite pour sa version 4 en janvier 2022
steps:
- name: Enhanced GitHub environment variables
uses: rlespinasse/github-slug-action@v4
- name: Print slug variables
run: |
echo "Repository: ${{ env.GITHUB_REPOSITORY_SLUG }}"
echo "Branch Name: ${{ env.GITHUB_REF_NAME }}"
echo "Branch Ref: ${{ env.GITHUB_REF_SLUG }}"
echo "SHA: ${{ env.GITHUB_SHA_SHORT }}"
shell: bash
La gestion simultanée de GitHub.com et GitHub Enterprise a représenté un challenge particulier. Les deux environnements évoluant à des rythmes différents, nous avons dû mettre en place une stratégie de compatibilité robuste pour supporter les différentes versions en circulation.
Une CVE inattendue : leçon de sécurité open source
Un autre défi majeur est survenu avec la modification du système de publication des variables d'environnement par GitHub, suite à la découverte d'une faille de sécurité. Cette situation a nécessité une adaptation rapide pour maintenir la compatibilité tout en assurant la sécurité de nos utilisateurs.
Puis début 2023, j'ai reçu un message d'une équipe de chercheurs d'une université américaine qui avait découvert une vulnérabilité potentielle dans github-slug-action. Leur analyse avait révélé un risque sérieux : une possible injection de commandes lors de la génération des normalisations, une faille qui aurait pu être exploitée dans certains contextes spécifiques.
La gestion de cette situation a été grandement facilitée par l'approche professionnelle des chercheurs. Au lieu d'opter pour une divulgation publique immédiate, ils ont choisi la voie de la responsabilité en suivant le processus de divulgation de vulnérabilité établi. Les outils de signalement de vulnérabilité privée de GitHub nous ont permis de travailler sur cette situation sensible dans un cadre sécurisé.
Cette collaboration constructive a abouti à l'attribution officielle d'une CVE (CVE-2023-27581), marquant ainsi la reconnaissance et la résolution formelle de cette vulnérabilité.
Cette expérience a démontré que même un petit projet open source peut faire face à des enjeux de sécurité importants. Elle a souligné l'importance d'une maintenance régulière et attentive, ainsi que la valeur d'une communication transparente avec la communauté des utilisateurs.
Un cadeau d'anniversaire : La version 5
Pour marquer les cinq ans de l'action, nous avons résolu une incohérence majeure dans l'action concernant la coexistence de variables similaires. En septembre 2021, notre action commence à utiliser GITHUB_REF_NAME pour la normalisation des références Git, avant que GitHub n'introduise sa propre variable homonyme, quelques mois plus tard, mais avec une logique différente pour les pull requests.
Voici un tableau comparatif illustrant ces différences :
| Contexte | Variable GitHub native | Notre variable |
|---|---|---|
| Branch "main" | GITHUB_REF_NAME = "main" |
env.GITHUB_REF_NAME = "main" |
| Tag "v1.0.0" | GITHUB_REF_NAME = "v1.0.0" |
env.GITHUB_REF_NAME = "v1.0.0" |
| Pull Request #42 | GITHUB_REF_NAME = "42-merge" |
env.GITHUB_REF_NAME = "feature-ma-super_branche" |
Pour résoudre ce problème, la version 4 avait introduit un mécanisme de préfixe. La version 5 va plus loin en utilisant GITHUB_REF_POINT afin d'éliminer toute ambiguïté. La variable GITHUB_REF_NAME a dorénavant le comportement par défaut prévu par GitHub Action.
steps:
- name: Enhanced GitHub environment variables
uses: rlespinasse/github-slug-action@v5
shell: bash
- name: Print slug variables
run: |
echo "Repository: ${{ env.GITHUB_REPOSITORY_SLUG }}"
echo "Branch Point: ${{ env.GITHUB_REF_POINT }}" # feature-ma-super_branche
echo "Branch Name: ${{ env.GITHUB_REF_NAME }}" # 42-merge
echo "Branch Ref: ${{ env.GITHUB_REF_SLUG }}" # 42-merge
echo "SHA: ${{ env.GITHUB_SHA_SHORT }}"
Réflexions d'un mainteneur
La maintenance d'un projet open source est une expérience enrichissante qui mérite d'être partagée. Ces années de maintenance m'ont permis de tirer de nombreux enseignements, tant dans le rôle de créateur que dans celui de mainteneur.
En tant que créateur
L'aventure commence toujours par une étincelle créative. J'ai appris qu'une idée de projet peut surgir de n'importe où, et qu'il ne faut pas hésiter à la concrétiser, même si l'on pense être le seul utilisateur potentiel. La perfection n'est pas un prérequis : un projet évolue naturellement au fil du temps, s'enrichissant des retours et des besoins de la communauté. Même le choix du nom, qu'il soit purement descriptif ou plus créatif, fait partie de cette liberté créative qui caractérise les débuts d'un projet.
En tant que mainteneur
Le rôle de mainteneur m'a enseigné l'importance de savoir dire "non" avec diplomatie ou d'attendre le bon moment pour le faire. Cette capacité s'avère essentielle pour préserver la cohérence et la qualité du projet. J'ai également compris qu'il n'était ni réaliste ni nécessaire de maintenir toutes les versions indéfiniment. Parfois, la décision d'archiver un projet non maintenu s'impose comme la solution la plus responsable. La gestion du temps de réponse aux issues et pull-requests doit rester raisonnable, sans céder à la pression d'une réactivité excessive.
Une aventure continue
Cette expérience de maintenance représente un parcours d'apprentissage constant. Chaque interaction enrichit ma compréhension du développement open source. L'équilibre subtil entre l'écoute de la communauté, le maintien de la qualité du projet et une gestion saine de mon investissement personnel s'est révélé être la clé du succès. Ces réflexions continuent d'évoluer, car dans l'univers du développement, l'apprentissage ne s'arrête jamais. Je pourrais d'ailleurs, comme certains de mes collègues sfeirians, passer la certification sur les GitHub Actions, une étape qui viendrait naturellement consolider cette aventure.
Et maintenant ?
Après cinq années d'évolution, couronnées de 255 étoiles GitHub, github-slug-action continue de s'adapter aux besoins de la communauté. Mon engagement reste inébranlable : maintenir une action simple, efficace et sécurisée.
Les chiffres témoignent de la confiance de la communauté :
- Plus de 11 700 utilisateurs
- 255 étoiles GitHub
- Une adoption dans des projets de toutes tailles
- Une maintenance continue et réactive
Nos priorités pour l'avenir :
- Maintenir une veille proactive sur les évolutions de GitHub Actions
- Continuer l'amélioration des performances
- Renforcer la documentation et les exemples d'utilisation
- Répondre aux besoins émergents de la communauté
Vous souhaitez contribuer à github-slug-action ? Rejoignez notre communauté open source sur GitHub :
- 🌟 Donnez une étoile au projet
- 🐛 Signalez des bugs
- 💡 Proposez des améliorations
- 🤝 Soumettez des pull requests
- 🗣️ Partager des retours d'expérience
- 📖 Enrichir la documentation
Chaque interaction enrichit le projet et contribue à son évolution continue.
