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

Refactoring: mutualiser les scripts entre GitHub Actions et GitLab CI

Date de l'article:18-08-2026
CI/CD Github-Actions Gitlab refactoring
Évitons la duplication en créant des scripts génériques, partagés entre plateformes. Nous simplifions ainsi la maintenance des déploiements dans des environnements multi-forges.
Organisation des scripts CI:
Tous les scrips sont réunis dans le répertoire "ci-scripts"
FLASHCARDS
├── ci-scripts/  
│   ├── docker-build.sh      ← shared
│   ├── sonar.sh             ← shared
│   ├── test.sh              ← shared
│   ├── docker_push.sh       ← Github only
│   ├── gitlab_push.sh       ← Gitlab only
│   ├── trivy-fs.sh          ← Gitlab only
│   └── trivy-image.sh       ← Gitlab only
Contexte: Démarré avec la série GitHub, à la fin je n'avais plus que le script docker-build.sh d'utilisé. On va profiter que nous sommes dans la phase de "refactoring", pour remettre un peu d'ordre, voir ce que nous pouvons réutiliser/ajouter pour améliorer les pipelines.
La mise à jour du digest de l'image Docker repose exclusivement sur ces scripts: (GitHub) | voir le détail des scripts: automatisation-de-la-pr-watch-distroless
FLASHCARDS
├── ci-scripts/
│   ├── .distroless-java17-debian13.digest
│   ├── check-docker-image-latest.sh      
│   ├── install-crane.sh     

Les scripts de secours peuvent être utilisés en cas de casse
FLASHCARDS
├── ci-scripts/
│   ├── install-trivy.sh   # Fallback if trivy-action cannot be used
L'objectif est de conserver une seule implémentation pour toutes les opérations communes afin d'éviter la duplication et de simplifier la maintenance.
Dans cette page réservée à GitLab, nous ne mentionnerons que les scripts propres à GitLab. Pour voir le détail des scripts partagés et la manière dont ils sont appelés dans la CI/CD, cliquez sur le lien des Ressources partagées.

Gitlab only
Ces deux scripts "Trivy" sont exclusivement utilisés par Gitlab.
Nous avons également un script (de secours) d'installation manuelle pour Trivy; que nous conservons au cas où il y aurait encore des failles de sécurité.
Ajout
ci-scripts/trivy-fs.sh
Utilisé dans: develop staging main
#!/bin/sh
set -eu

EXIT_CODE="${1:-1}"

echo "=== TRIVY ==="
echo "Version: $(trivy version --format '{{.Version}}' 2>/dev/null || trivy version)"
echo "Cache: ${TRIVY_CACHE_DIR}"
echo "=== TRIVY FILESYSTEM SCAN ==="

trivy fs \
  --severity HIGH,CRITICAL \
  --format table \
  --scanners vuln,misconfig \
  --skip-dirs ".trivycache" \
  --skip-dirs "target" \
  --cache-dir "$TRIVY_CACHE_DIR" \
  --offline-scan \
  --exit-code "$EXIT_CODE" \
  --no-progress \
  .
# Executed inside the official Trivy Alpine image (no bash available)

develop & staging
script:
  - ./ci-scripts/trivy-fs.sh 0
exit-code: 0

main
script:
  - ./ci-scripts/trivy-fs.sh 1
exit-code: 1

Ajout
ci-scripts/trivy-image.sh
Utilisé dans: staging main
#!/bin/sh
set -eu

IMAGE=${1:?Image archive required}
EXIT_CODE=${2:-1}
IGNOREFILE=${3:-}

if [ -n "$IGNOREFILE" ]; then
    trivy image \
        --input "$IMAGE" \
        --severity HIGH,CRITICAL \
        --exit-code "$EXIT_CODE" \
        --ignore-unfixed \
        --ignorefile "$IGNOREFILE" \
        --timeout 10m \
        --cache-dir "$TRIVY_CACHE_DIR" \
        --format table \
        --no-progress
else
    trivy image \
        --input "$IMAGE" \
        --severity HIGH,CRITICAL \
        --exit-code "$EXIT_CODE" \
        --ignore-unfixed \
        --timeout 10m \
        --cache-dir "$TRIVY_CACHE_DIR" \
        --format table \
        --no-progress
fi
# Executed inside the official Trivy Alpine image (no bash available)

Le scan de l'image Docker n'est pas inclus dans la branche develop
staging (with args):
script:
  - chmod +x ci-scripts/trivy-image.sh
  - ./ci-scripts/trivy-image.sh flashcards-staging.tar 0 
"$IMAGE": flashcards-staging
exit-code 0

main (with args):
script:
  - chmod +x ci-scripts/trivy-image.sh
  - ./ci-scripts/trivy-image.sh flashcards-prod.tar 1 .trivyignore.yaml
"$IMAGE": flashcards-prod
exit-code 1
ignorefile: .trivyignore.yaml

Publication dans le registre Gitlab
Ajout
ci-scripts/gitlab_push.sh
Utilisé dans: main
#!/bin/sh
set -eu

IMAGE_NAME=${1:?Image name missing}
SOURCE_TAG=${2:?Source tag missing}
SHA_TAG=${3:?SHA tag missing}
RELEASE_TAG=${4:?Release tag missing}

TARGET_IMAGE="$CI_REGISTRY_IMAGE"

echo "====================================="
echo "Push Docker image to GitLab Registry"
echo "Target: ${TARGET_IMAGE}"
echo "====================================="

echo "$CI_REGISTRY_PASSWORD" | docker login "$CI_REGISTRY" \
  -u "$CI_REGISTRY_USER" \
  --password-stdin

docker tag "${IMAGE_NAME}:${SOURCE_TAG}" \
  "${TARGET_IMAGE}:sha-${SHA_TAG}"

docker tag "${IMAGE_NAME}:${SOURCE_TAG}" \
  "${TARGET_IMAGE}:${RELEASE_TAG}"

docker tag "${IMAGE_NAME}:${SOURCE_TAG}" \
  "${TARGET_IMAGE}:latest"

docker push "${TARGET_IMAGE}:sha-${SHA_TAG}"
docker push "${TARGET_IMAGE}:${RELEASE_TAG}"
docker push "${TARGET_IMAGE}:latest"

echo "Docker image successfully pushed to GitLab Registry"

main (with args):
prod-publish:
  stage: publish
  needs:
    - job: prod-docker-build
      artifacts: true
    - prod-smoke
    - prod-trivy-image
  extends:
    - .docker
    - .push_rules
  script:
    - docker load -i flashcards-prod.tar
    - chmod +x ci-scripts/gitlab_push.sh
    - |
      ./ci-scripts/gitlab_push.sh \
        flashcards \
        prod \
        "$CI_COMMIT_SHORT_SHA" \
        "$CI_COMMIT_TAG"
IMAGE_NAME = flashcards-prod
SOURCE_TAG=
SHA_TAG= RELEASE_TAG= TARGET_IMAGE=
Suivant le(s) dévelopement ou mise à jour, ces scripts sont sujets à modifications. Le repository restant la seule source de vérité
Dans l'article suivant, nous verrons les différences fondamentales ainsi que les bénéfices des deux plateformes, suivi d'une analyse comparative axée sur les tâches quotidiennes d'un ingénieur DevOps

Laissez-moi un commentaire

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