Intégration CI applicatif

Les équipes applicatives interagissent avec imglife via deux commandes :

imglife check — vérifier que leur image de base est à jour avant de construire.
imglife register — enregistrer le build dans le Package Registry après le push.

Aucune de ces commandes ne nécessite d’accès au imglife.yaml complet du projet base-images. Les projets applicatifs n’ont besoin que d’une configuration minimale pointant vers le Package Registry.

Configuration minimale pour les projets applicatifs

Créez imglife.apps.yaml dans le projet applicatif :

# imglife.apps.yaml — config projet applicatif
# Seule la section registry est nécessaire.

registry:
  url: https://gitlab.example.com
  project_id: 42 # ID du projet base-images (pour la dérivation auto dans check)

Cela donne à imglife accès au Package Registry du projet base-images pour récupérer la dernière version de base et les données EOL.

Pattern Dockerfile

ARG BASE_IMAGE
FROM ${BASE_IMAGE}

# ... vos couches applicatives ...

Passez BASE_IMAGE comme argument de build. Cela permet au CI de contrôler quelle version de l’image de base est utilisée et permet à imglife check de lire le label OCI :

docker build \
  --build-arg BASE_IMAGE=registry.example.com/bases/alpine:3.21.3-core1.0.0 \
  -t registry.example.com/apps/monservice:1.2.0 \
  .

imglife build injecte org.opencontainers.image.base.name comme label OCI, que imglife register utilise pour auto-détecter la base.

Exemple GitLab CI

# .gitlab-ci.yml — projet applicatif

variables:
  BASE_IMAGE: registry.example.com/bases/alpine:3.21.3-core1.0.0
  IMGLIFE_CONFIG: imglife.apps.yaml

stages:
  - check
  - build
  - register

# Vérifier que l'image de base est à jour
check-base:
  stage: check
  image: registry.gitlab.com/imglife-project/imglife:latest
  script:
    - |
      imglife check \
        --base "$BASE_IMAGE" \
        --strict
  rules:
    - if: $CI_COMMIT_TAG
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

# Construire l'image applicative
build:
  stage: build
  image: docker:26
  services:
    - docker:26-dind
  variables:
    DOCKER_TLS_CERTDIR: /certs
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
  script:
    - |
      docker build \
        --build-arg BASE_IMAGE="$BASE_IMAGE" \
        --build-arg GIT_REVISION="$CI_COMMIT_SHA" \
        -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_TAG" \
        .
      docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_TAG"
  rules:
    - if: $CI_COMMIT_TAG

# Enregistrer le build
register:
  stage: register
  image: registry.gitlab.com/imglife-project/imglife:latest
  script:
    - |
      imglife register \
        --image    "$CI_REGISTRY_IMAGE:$CI_COMMIT_TAG" \
        --base     "$BASE_IMAGE" \
        --revision "$CI_COMMIT_SHA" \
        --project  "$CI_PROJECT_PATH"
  rules:
    - if: $CI_COMMIT_TAG

Exemple Gitea Actions

on:
  push:
    tags: ["v*"]

env:
  BASE_IMAGE: gitea.example.com/myorg/bases/alpine:3.21.3-core1.0.0
  IMGLIFE_CONFIG: imglife.apps.yaml

jobs:
  check-base:
    runs-on: ubuntu-latest
    container:
      image: registry.gitlab.com/imglife-project/imglife:latest
    steps:
      - uses: actions/checkout@v4
      - run: imglife check --base "$BASE_IMAGE" --strict
        env:
          GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }}

  build-push:
    needs: check-base
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: gitea.example.com
          username: ${{ gitea.actor }}
          password: ${{ secrets.GITEA_TOKEN }}
      - run: |
          docker build \
            --build-arg BASE_IMAGE="$BASE_IMAGE" \
            -t gitea.example.com/myorg/apps/myservice:${{ gitea.ref_name }} \
            .
          docker push gitea.example.com/myorg/apps/myservice:${{ gitea.ref_name }}

  register:
    needs: build-push
    runs-on: ubuntu-latest
    container:
      image: registry.gitlab.com/imglife-project/imglife:latest
    steps:
      - uses: actions/checkout@v4
      - run: |
          imglife register \
            --image gitea.example.com/myorg/apps/myservice:${{ gitea.ref_name }} \
            --base  "$BASE_IMAGE" \
            --revision "${{ gitea.sha }}" \
            --project  "${{ gitea.repository }}"
        env:
          GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }}

Maintenir BASE_IMAGE à jour

Utiliser une variable fixe — définissez BASE_IMAGE comme variable CI. Mettez-la à jour quand une nouvelle image de base est publiée. Le job check-base détectera les valeurs obsolètes avant qu’elles ne soient livrées.
Automatiser les mises à jour — l’équipe base-images peut déclencher les pipelines applicatifs quand une nouvelle base est disponible, ou utiliser un bot de dépendances pour ouvrir des MR.
Échouer rapidement avec --strict — avec --strict, check-base échoue si la base est obsolète. Les équipes doivent mettre à jour BASE_IMAGE pour débloquer leur release.

Sans `--strict`

Si --strict est trop agressif au début, utilisez le mode par défaut (avertir, sans échouer) :

imglife check --base "$BASE_IMAGE"
# Sort toujours 0, mais journalise des avertissements pour les bases obsolètes/EOL

Cela donne aux équipes une visibilité sur l’état sans bloquer les releases.

Champs personnalisés dans les build records

Ajoutez n’importe quelle métadonnée utile au build record :

imglife register \
  --image    "$CI_REGISTRY_IMAGE:$CI_COMMIT_TAG" \
  --revision "$CI_COMMIT_SHA" \
  --project  "$CI_PROJECT_PATH" \
  --field    pipeline_url="$CI_PIPELINE_URL" \
  --field    deployer="$GITLAB_USER_LOGIN"

Les champs personnalisés apparaissent dans imglife app list --detailed et --output json.