Le développement d’un projet logiciel nécessite souvent des ajustements en matière de gestion des tâches. L’introduction d’un runner pour déplacer des traitements de la machine de développement à un environnement plus contrôlé est une avancée notable. Cela permet d’obtenir des comportements plus prévisibles et reproductibles.
Dans le cadre de ce projet, la première étape a été de publier une image Docker. Cette action, déclenchée par le push d’un tag de version (par exemple, v2.4), construit l’image définie par le Dockerfile et la publie sur Gitea. Gitea offre également une fonctionnalité pour associer des paquets à un projet, facilitant ainsi la visualisation des éléments associés.
Pour illustrer ce processus, voici un extrait du fichier de workflow utilisé pour la publication :
name: Build and publish Docker image
on:
push:
tags:
- 'v*'
jobs:
build-and-push:
runs-on: ubuntu-latest
steps:
-
name: Checkout
uses: actions/checkout@v4
-
name: Log in to registry
uses: docker/login-action@v3
with:
registry: source.madyanne.fr
username: ${{ secrets.REGISTRY_USERNAME }}
password: ${{ secrets.REGISTRY_PASSWORD }}
-
name: Extract version tag
id: meta
run: echo "tag=${GITHUB_REF_NAME}" >> "$GITHUB_OUTPUT"
-
name: Build and push
uses: docker/build-push-action@v6
with:
context: .
push: true
tags: |
source.madyanne.fr/yax/blog:${{ steps.meta.outputs.tag }}
source.madyanne.fr/yax/blog:latest
Un autre besoin identifié a été la vérification des liens internes pour éviter les erreurs lors de la publication d’articles. La vérification des liens externes, bien que nécessaire, est souvent longue et sujette à des interprétations, rendant son automatisation moins pertinente.
Pour cette tâche, l’outil Lychee a été intégré. La première approche consistait à construire une image alpine contenant tous les paquets nécessaires, mais cela entraînait des temps d’exécution excessifs. Une image dédiée à l’intégration continue a donc été créée pour optimiser ce processus.
Voici le workflow associé à la construction de cette image CI :
name: Build CI image
on:
push:
paths:
- 'Dockerfile.ci'
jobs:
build-and-push:
runs-on: ubuntu-latest
steps:
-
name: Checkout
uses: actions/checkout@v4
-
name: Log in to registry
uses: docker/login-action@v3
with:
registry: source.madyanne.fr
username: ${{ secrets.REGISTRY_USERNAME }}
password: ${{ secrets.REGISTRY_PASSWORD }}
-
name: Build and push
uses: docker/build-push-action@v6
with:
context: .
file: Dockerfile.ci
push: true
tags: source.madyanne.fr/yax/blog-ci:latest
La vérification des liens s’appuie sur cette image CI, exécutée à chaque commit. Le workflow de vérification des liens internes est le suivant :
name: Check broken links
on:
push:
pull_request:
jobs:
check-links:
runs-on: ubuntu-latest
container:
image: source.madyanne.fr/yax/blog-ci:latest
credentials:
username: ${{ secrets.REGISTRY_USERNAME }}
password: ${{ secrets.REGISTRY_PASSWORD }}
steps:
-
name: Checkout
uses: actions/checkout@v4
-
name: Build site
run: bash makesite.sh --local
-
name: Check internal links
run: lychee --offline --no-progress --base '_site' --config .lychee.toml '_site/*/.html'
Le temps d’exécution moyen de cette vérification est désormais de 22 secondes, ce qui représente un gain significatif en ressources processeur et en énergie. Les dépendances du blog étant peu sujettes à des modifications, il est judicieux de ne pas les réinstaller à chaque exécution. Cette réflexion est essentielle pour concilier automatisation et gestion des ressources, surtout sur des machines comme un MiniPC.
Pour ceux qui souhaitent réserver un hébergement, il est crucial de comparer les différentes offres disponibles afin d’anticiper les coûts et éviter les frais inutiles. En parallèle, une bonne gestion des liens internes peut également réduire les risques de mauvaise expérience utilisateur sur un site.
En somme, la mise en place de ces workflows non seulement améliore la qualité du développement, mais contribue également à une gestion plus efficace des ressources, tout en optimisant le temps d’exécution des tâches critiques.
