Cet article propose un workflow GitHub Actions idéal pour les applications Symfony. L'objectif principal est de garantir que le code et les dépendances livrés fonctionnent dans un environnement similaire à la production. Il met en avant un workflow de CI de base axé sur les tests, le linting, l'analyse statique et la sécurité des dépendances.
Le workflow présenté inclut des étapes essentielles pour une application Symfony typique. Il couvre la configuration de PHP, l'installation des dépendances via Composer avec mise en cache, la création et la migration de la base de données de test (PostgreSQL ou MySQL), ainsi que la validation de la cohérence du schéma de base de données avec le mapping Doctrine. Ce workflow est conçu pour s'exécuter lors des pull requests et des commits sur la branche principale, assurant une intégration continue fiable.
Le workflow CI utilise un environnement de test avec une version de PHP correspondant à celle de production, ainsi qu'un service de base de données (PostgreSQL ou MySQL) pour simuler un environnement réel. Il inclut également la gestion des étapes de validation de la base de données pour détecter et afficher les divergences entre le schéma attendu et celui généré par les migrations.
Résumé pour Shaarli:
Workflow GitHub Actions recommandé pour les applications Symfony, axé sur les tests, l'analyse et la validation dans un environnement proche de la production. Il automatise l'installation des dépendances, la gestion de la base de données de test et la vérification de la cohérence du schéma, assurant la fiabilité du code avant le déploiement.
L’article explique comment optimiser une chaîne d’intégration continue (CI) en mettant en cache l’état d’une base de données pour éviter de régénérer les données à chaque build. L’idée centrale est de remplacer le rechargement systématique des fixtures et migrations par un snapshot (instantané) de la base, reconstruit uniquement lorsque les fichiers sources (migrations, fixtures) changent. Cela réduit considérablement le temps de CI, passant de 50 secondes à quelques secondes pour la préparation de la base, tout en garantissant la cohérence des données.
L’auteur détaille une implémentation concrète sur un projet Symfony utilisant Castor pour l’automatisation et des runners GitHub Actions auto-hébergés. Le cache est partagé entre les jobs via des dossiers locaux, mais une solution équivalente est possible avec les caches natifs de GitHub. L’empreinte du snapshot est calculée à partir des fichiers déterminants (migrations, fixtures), permettant une invalidation automatique et fiable du cache.
Enfin, l’article souligne que cette méthode évite les écueils des dumps statiques (obsolescence ou régénération inutile), tout en restant compatible avec des architectures distribuées. L’approche est présentée comme une alternative efficace aux techniques classiques d’optimisation de CI, avec un gain de temps significatif pour les projets où les modifications des données sont rares.
Ce billet explique comment automatiser les releases logicielles en utilisant les Conventional Commits, SemVer, CHANGELOG et git-cliff via GitHub Actions. L’idée centrale repose sur l’analyse des messages de commit (formatés selon Conventional Commits) pour générer automatiquement une nouvelle version, un CHANGELOG et une release GitHub, sans intervention manuelle hormis la validation finale d’une PR.
L’auteur détaille la configuration de git-cliff (via un fichier cliff.toml) qui filtre les commits pertinents (feat, fix, etc.) et applique les règles de versionnage SemVer. Un postprocessing simplifié remplace les références de PR par des liens Markdown, évitant ainsi la gestion complexe de tokens GitHub. Le workflow CI/CD, déclenché à chaque push sur main, prépare une PR de release si nécessaire, réduisant l’intervention humaine à un simple merge.
L’approche est adaptée aux projets déployés avec un mainteneur unique, excluant les bibliothèques ou monorepos aux contraintes spécifiques. La solution mise en avant privilégie la simplicité, avec une configuration versionnée et des outils légers (binaire Rust ou image Docker), garantissant un comportement cohérent entre local et CI.
L’article explique comment améliorer la maintenance et la sécurité des workflows GitHub, un enjeu crucial pour les projets open source comme Castor. Il présente zizmor, un outil d’analyse statique qui détecte les vulnérabilités dans les fichiers de configuration CI, similaire à PHPStan pour le code. L’outil identifie des erreurs courantes comme des références non verrouillées à des actions ou des risques de fuite de credentials, et propose des correctifs automatiques.
Les exemples de rapports générés par zizmor illustrent des problèmes spécifiques, comme l’absence de hachage pour une action ou l’utilisation dangereuse de GITHUB_ENV. La commande zizmor . --fix=all permet de corriger automatiquement certaines erreurs, mais nécessite un token GitHub pour accéder aux hashes des commits associés aux tags.
Enfin, l’article mentionne que zizmor ne gère pas les mises à jour majeures des actions, nécessitant d’autres méthodes pour ces cas. L’outil s’intègre ainsi dans une démarche globale de sécurisation et de maintenance des pipelines CI/CD.
L’article explique comment automatiser l’application des guides de style de code en combinant l’outil « Continue.dev » avec des pipelines d’intégration continue comme GitHub Actions afin de réduire la charge des revues manuelles, en définissant des règles de style lisibles par machine, en intégrant des vérifications en temps réel dans l’éditeur et en ajoutant des contrôles dans la CI pour bloquer les pull requests non conformes, ce qui permet de cibler jusqu’à ~90 % des vérifications de style sans intervention humaine ; il détaille la configuration de Continue avec des règles personnalisées, l’architecture du workflow CI ainsi que des conseils pour affiner les règles et mesurer l’impact.
L’article explique comment externaliser le build d’une application Nuxt 4—devenu trop gourmand en ressources—vers GitHub Actions, puis déployer automatiquement sur Coolify. L’auteur, confronté à des serveurs Hetzner (4vCPU/8Go) saturés par les builds Nuxt 4, détaille la méthode : créer une nouvelle app Coolify en choisissant l’option « Docker Image », activer les APIs Coolify pour générer un token de déploiement, configurer les secrets GitHub (webhook et token Coolify), et ajouter un workflow GitHub Actions pour builder l’image Docker et déclencher le déploiement via un webhook. Une étape manuelle de login Docker sur le serveur Coolify est nécessaire pour autoriser l’accès au registry GitHub. Résultat : des builds plus légers, moins coûteux, et un déploiement fluide, le tout sans ajouter de serveur dédié.
L'article explique comment utiliser les fichiers .http pour tester des API et augmenter la couverture de code sans écrire de tests d'intégration complexes. Les fichiers .http sont des fichiers texte simples qui décrivent des requêtes HTTP et peuvent être exécutés directement depuis des IDE populaires comme IntelliJ, Visual Studio et VSCode, ou en ligne de commande.
L'auteur propose d'utiliser ces fichiers dans les pipelines CI/CD pour exécuter des tests d'API et collecter la couverture de code. Il mentionne l'outil httpyac pour exécuter les fichiers .http en ligne de commande et dotnet-coverage pour instrumenter les binaires et collecter la couverture de code sans framework de tests.
L'article fournit également des exemples de commandes pour exécuter ces outils et intégrer les tests dans des pipelines Azure DevOps et GitHub Actions
.
L'article encourage les lecteurs à se lancer dans la création de blogs. L'auteur, passionné par la consommation de contenu de blogs, constate une baisse du nombre de personnes se lançant dans l'écriture d'articles. Il propose un guide pour créer un blog sans dépenser d'argent pour l'hébergement.
Voici les étapes clés :
-
Inventaire des besoins :
- Un domaine (optionnel)
- Du contenu à stocker
- Un support pour modifier le site (sans HTML/CSS brut)
- Un hébergeur gratuit
-
Choix technologiques :
- Utilisation de Markdown pour écrire les articles
- Utilisation d'un générateur de site statique comme Hugo
- Hébergement gratuit via Cloudflare Pages
-
Étapes pratiques :
- Initialisation du site avec Hugo
- Installation d'un thème (ex. PaperMod)
- Configuration de Git pour sauvegarder le projet
- Mise en place d'un pipeline CI/CD pour déployer automatiquement le site sur Cloudflare Pages
L'auteur recommande Hugo pour sa simplicité et son efficacité, et fournit des instructions détaillées pour configurer l'hébergement et le déploiement automatique. Le but est de rendre la création de blogs accessible à tous, même aux débutants.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre (cf https://blog.ippon.fr/2020/10/23/decouvrez-dbt/ pour découvrir dbt)
Pour rappel, Cecil est un générateur de sites statiques écrit en PHP. L'auteur montre comment utiliser les github actions pour le déploiement.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre