Maximize Page
Tech & DevOps HubEspace Tech & DevOps: Explorez le monde du Dev, du Cloud et des outils DevOps à travers nos articles et discussions Explore the world of development, the cloud and DevOps tools

Ressources communes entre Github actions et Gitlab

Date de l'article:07-08-2026
CI/CD Github-Actions Gitlab
Ressources communes entre Github actions et Gitlab pour l'application Flashcards, contenant: Les scripts partagés et leurs utilités - les scripts de secours ainsi que les scripts gérant le digest de l'image Docker
INFO PROJET
App " Flashcards" - readme CI
Docker Image Hub
Qualité/couverture : sonarCloud project SonarQube Cloud
Follow-up
Répartition des responsabilités entre les plateformes
Mises à jour GitHub Actions
tableau-de-suivi-cicd
Mises à jour de l'application Flashcards
tableau-de-suivi-de-l-application-flashcards
Mises à jour Gitlab CI
tableau-de-suivi-cicd
Au sujet de (vulnérabilités) Trivy
Le fichier pom.xml peut être modifié dans les deux plateformes;
  1. Si celles-ci concernent les dépendances: voir comment fixer-les-vulnerabilites-trivy
  2. Si la vulnérabilité concerne l'image Docker, il faudra sans doute mettre à jour l'image distroless via le Dockerfile disponible dans Github.
Retrouvez l'historique de Trivy
ainsi qu'un cas traité (avec résolution): Trivy: Installation failed et vulnérabilité sur l'image Docker
Les mises à jours applicatives (vers Gitlab) sont régulièrement effectuées.
En général je retrouve les mêmes vulnérabilités dans les deux plateformes, à quelques heures d'intervalles. La mise à jour du digest résouds la plupart des vulnérabilités trouvées (image)
Les scripts partagés
Ils sont localisés à la racine du projet: 
FLASHCARDS/
├── ci-scripts/
│   ├── docker-build.sh                  
│   ├── sonar.sh                          
│   ├── test.sh         
├── Dockerfile
└── pom.xml
Dockerfile et digest sont mis à jour via Github
pom.xml (voir Trivy)
Les scripts sont écrits en Powershell de manière à garder la compatibilité entre les plateformes.
Les scripts de secours
FLASHCARDS/
├── ci-scripts/
│   ├── install-trivy.sh
Peuvent être utilisés en dépannage en cas d'échec éventuel
La seule chose à modifier sera la version qui est figée dans le script: TRIVY_VERSION="0.72.0". Référez-vous aux logs pour la dernière version
D'autres scripts peuvent s'ajouter dans le dossier ci-scripts: Il n'est pas dit qu'ils seront partagés entre les plateformes
Les scripts Github
FLASHCARDS/
├── .github/workflows/pr-watch-distroless.yml
├── ci-scripts/
│   ├── .distroless-java17-debian13.digest
│   ├── check-docker-image-latest.sh      
│   ├── install-crane.sh                  
│   │                
│   └── docker_push.sh
Gérant le digest: Ces scripts sont utilisés par le pipeline de mise à jour du digest de l'image Docker; voir l'article: automatisation-complete-de-la-pr-watch-distroless
En résumé: Le pipeline "Distroless Watch" lance le script: check-docker-image-latest.sh, qui compare le fichier .distroless-java17-debian13.digest avec le dernier digest trouvé sur "gcr.io" pour l'image distroless/java17-debian13:nonroot
Le script docker_push lance la publication de l'image dans le registre Docker Hub (only main)
Les scripts Gitlab
FLASHCARDS/
├── ci-scripts/
│   ├── trivy-fs.sh
│   ├── trivy-image.sh
│   ├── gitlab_push.sh
Gitlab n'utilise pas actions comme Github pour le plugin Trivy. Les scripts trivy-* sont utilisés dans tous les environements (develop - staging - main)
Le script gitlab_push publie l'image Docker dans le registre Container de GitLab
Retrouvez le détails des scripts Gitlab: mutualiser-vos-scripts-entre-github-actions-et-gitlab-ci
Les scripts partagés
1. Le script de construction d'image jar
Modification
ci-scripts/docker-build.sh
Utilisé dans: main
cd-prod
Avant 
#!/bin/bash
set -euo pipefail

IMAGE_NAME=${1:-flashcards}
IMAGE_TAG=${2:-latest}

echo "== Building Docker image: ${IMAGE_NAME}:${IMAGE_TAG} =="
docker build -t ${IMAGE_NAME}:${IMAGE_TAG} .
Du Bash au Shell
Dans Gitlab, nous utilisons Alpine dans l'image Postgres (services: postgres:16.14-alpine3.23), ainsi que dans les containers nous devons donc convertir le code en shell plutot qu'en bash,
Les scripts seront ainsi compatibles sur les deux plateformes puisque Ubuntu, utilisé dans Github comprends le shell également
Après 
#!/bin/sh
set -eu

IMAGE_NAME=${1:-flashcards}
IMAGE_TAG=${2:-latest}
DOCKERFILE=${3:-Dockerfile}

echo "====================================="
echo "Building Docker image"
echo "Image      : ${IMAGE_NAME}:${IMAGE_TAG}"
echo "Dockerfile : ${DOCKERFILE}"
echo "====================================="

docker build \
  -f "${DOCKERFILE}" \
  -t "${IMAGE_NAME}:${IMAGE_TAG}" \
  .
echo "Docker image successfully built"
Appel Gitlab (with args): 
script:
  - chmod +x ci-scripts/docker-build.sh
  - ./ci-scripts/docker-build.sh flashcards prod
  - docker save flashcards:prod -o flashcards-prod.tar
IMAGE_NAME: flashcards
IMAGE_TAG: prod
Appel GitHub (with args): 
- name: Build Docker image
  run: |
    chmod +x ci-scripts/docker-build.sh
    ./ci-scripts/docker-build.sh "$IMAGE_NAME" "$IMAGE_TAG"
IMAGE_NAME: flashcards
"IMAGE_TAG=$(git rev-parse --short HEAD)" >> $GITHUB_ENV
2. Le script de tests
L'ancien script de build, qui exécutait la commande ./mvnw clean package -DskipTests, à été remplacé au profit de l'utilisation du script de "test", que l'on a élargi pour qu'il prenne en compte le profil et le rapport Jacoco.
remplacement
ci-scripts/build.sh → ci-scripts/test.sh
Utilisé dans: develop main
ci-develop ci-staging cd-prod
Avant 
#!/bin/bash
set -e
echo "=== Running tests ==="
./mvnw clean verify
Pourquoi pas en staging aussi dans Gitlab?
En staging, les tests sont exécutés séparement;
les tests UT utilise: - ./mvnw -B clean test
Tandis que les tests IT saute les UT et vérifie le seuil de couverture explicitement pour staging (min 70%). On n'exécute donc pas exactement la même commande
Après 
#!/bin/sh
set -eu

PROFILE=${1:-}

echo "=== Running Maven tests ==="

if [ -n "$PROFILE" ]; then
    exec ./mvnw -B clean verify jacoco:report -P"$PROFILE"
else
    exec ./mvnw -B clean verify jacoco:report
fi
Appel Gitlab:
develop (no args: 0% of coverage): 
script:
  - ./ci-scripts/test.sh
main (min 80% of coverage): 
script:
  - ./ci-scripts/test.sh coverage-main
Les profils sont définis dans le pom.xml
Appel GitHub (with args):
staging (min 70% of coverage): 
- name: Verify Coverage 70%
  run: |
    ./ci-scripts/test.sh coverage-staging
main (min 80% of coverage): 
- name: Run Tests + JaCoCo
  run: |
    ./ci-scripts/test.sh coverage-main
3. Ajout du script de publication SonarCloud
Ajout
ci-scripts/sonar.sh
Utilisé dans: main
cd-prod
#!/bin/sh
set -eu

./mvnw -B sonar:sonar \
 -Dsonar.host.url="$SONAR_HOST_URL" \
 -Dsonar.login="$SONAR_TOKEN" \
 -Dsonar.qualitygate.wait=true
On obtient exactement le même % de couverture dans GitHub et dans GitLab.
Dans le pom.xml:
<sonar.projectKey>PROJECT_KEY</sonar.projectKey> <sonar.organization>ORGANIZATION</sonar.organization> <sonar.projectName>PROJECT_NAME</sonar.projectName>
SONAR_HOST_URL - SONAR_TOKEN: variables / secrets
Dans les jobs, le script est appelé sans arguments
Naviguez entre les articlesBrowse through the articles
Tableau de suivi de l'application Flashcards Trivy: Installation failed et vulnérabilité sur l'image Docker
Laissez-moi un commentaire

En postant un commentaire anonyme, vous adhérez automatiquement aux conditions d'utilisation du site.