imglife eol

Synopsis

imglife eol update [flags]
imglife eol notify [flags]

Récupère les données EOL depuis endoflife.date pour chaque produit référencé dans sync.entries[].lifecycle.product et écrit le résultat dans eol_data_file.

Flags

Flag	Défaut	Description
`--dry-run`	`false`	Récupérer et afficher les données sans écrire
`--prune`	`false`	Reconstruire le cache à partir des seuls cycles collectés, en purgeant le reste
`--data-file string`	`eol-data.yaml`	Chemin du fichier de sortie (surcharge `lifecycle.eol_data_file`)

Exemples

# Rafraîchir les données EOL
imglife eol update

# Dry-run : récupérer et afficher sans écrire
imglife eol update --dry-run

# Purger les cycles qui ne sont plus utilisés par aucune image
imglife eol update --prune

# Écrire vers un chemin personnalisé
imglife eol update --data-file /tmp/eol-cache.yaml

Quand exécuter cette commande

Exécutez imglife eol update périodiquement (par exemple chaque semaine) pour maintenir les dates EOL à jour. En CI, ajoutez-le comme job planifié :

# Job planifié GitLab CI
eol-update:
  stage: eol
  image: registry.gitlab.com/imglife-project/imglife:latest
  script:
    - imglife eol update
    - |
      if git diff --quiet eol-data.yaml; then
        echo "Données EOL inchangées"
      else
        git add eol-data.yaml
        git commit -m "chore(lifecycle): update EOL data"
        git push
      fi
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"

Configuration

L’ensemble des produits à récupérer est dérivé de sync.entries[].lifecycle.product dans votre imglife.yaml. Seuls les produits avec un bloc lifecycle: sont récupérés.

sync:
  entries:
    - source: docker.io/library/alpine
      lifecycle:
        product: alpine # ← sera récupéré
    - source: docker.io/library/golang
      lifecycle:
        product: go # ← sera récupéré
    - source: docker.io/library/nginx
      # pas de bloc lifecycle: — non récupéré

Cycles collectés

Les cycles proviennent de deux sources :

Tags miroirs — les tags présents dans le registry cible pour chaque entrée sync munie d’un bloc lifecycle:.
Build records applicatifs — l’image de base de chaque build record publié dans le Package Registry.

La seconde source est déterminante lorsqu’une application reste sur une ligne de version dont les tags miroirs ont déjà été purgés par keep_last : sans elle, la donnée EOL de ce cycle ne serait jamais récupérée et status afficherait ⚠️ N/A. Elle nécessite le token du Package Registry ; si le token est absent, un avertissement est loggé et seuls les cycles miroirs sont collectés.

Sémantique de fusion du cache

eol update fusionne les données fraîches dans le cache existant (fichier local ou Package Registry) : un cycle déjà connu est conservé même lorsqu’aucun tag miroir ne le référence plus. En cas de conflit, la donnée fraîche gagne.

--prune court-circuite la fusion et reconstruit le cache à partir des seuls cycles collectés — seul moyen de retirer un cycle devenu inutile.

Cycles absents à la lecture

status, check et eol notify résolvent un cycle absent du cache par repli sur les cycles voisins :

Cas	Résultat
Cycle plus récent que tout ce que connaît endoflife.date	Hérite du statut du cycle précédent si celui-ci est encore supporté
Cycle plus ancien que tous les cycles connus	`⚠️ outdated` — aucun statut n’est fabriqué
Produit inconnu	`⚠️ N/A` avec le motif dans l’infobulle

Cible de stockage

Par défaut, les données sont écrites dans un fichier local (cible git). Pour les environnements où le CI ne peut pas pousser vers git, basculez vers pkgregistry :

lifecycle:
  eol_target: pkgregistry

Le fichier est alors stocké dans le Package Registry et lu depuis là par imglife status et imglife check.

Codes de sortie

Code	Signification
`0`	Données récupérées et écrites avec succès
`1`	Erreur lors de la récupération ou l’écriture

Flux d’exécution

imglife eol notify

Évalue toutes les entrées lifecycle et envoie des alertes vers Slack ou des webhooks HTTP pour les images dont le statut est au moins égal au seuil configuré.

Flags

Flag	Défaut	Description
`--dry-run`	`false`	Afficher les alertes sans les envoyer
`--min-status string`	`warning`	Niveau minimal d’alerte : `warning`, `critical`, `eol` (surcharge config)

Exemples

# Envoyer des notifications avec la config par défaut
imglife eol notify

# Prévisualiser sans envoyer
imglife eol notify --dry-run

# Notifier uniquement pour les images critiques / EOL
imglife eol notify --min-status critical

Configuration

Les destinations sont configurées dans imglife.yaml sous lifecycle.notifications :

lifecycle:
  notifications:
    min_status: warning            # warning | critical | eol
    slack_webhook_url: "${SLACK_WEBHOOK_URL}"
    webhooks:
      - url: "${MY_WEBHOOK_URL}"
        headers:
          Authorization: "Bearer ${TOKEN}"

Payload Slack (Blocks API)

Chaque alerte base est rendue dans un bloc section mrkdwn avec ses images applicatives associées en deux groupes : Apps to update (un tag de base plus récent est disponible) et Apps on latest (déjà sur le dernier tag). Un divider sépare les alertes ; un bloc context clôture le message.

{
  "blocks": [
    {"type": "header", "text": {"type": "plain_text", "text": "🚨 imglife Lifecycle Alerts"}},
    {
      "type": "section",
      "text": {
        "type": "mrkdwn",
        "text": "🟡 *python/3.12* — WARNING · EOL: 2028-10-31\n*Apps to update:*\n  • reg/apps/myapp:1.0.0\n    `3.12.0-core1.0.0` → `3.12.5-core1.0.0`"
      }
    },
    {"type": "divider"},
    {
      "type": "section",
      "text": {
        "type": "mrkdwn",
        "text": "🔴 *alpine/3.17* — EOL exceeded · EOL: 2023-11-01\n*Apps on latest (no newer version available):*\n  • reg/apps/legacy:2.0.0  (base: `3.17.9-core1.0.0`)"
      }
    },
    {"type": "context", "elements": [{"type": "mrkdwn", "text": "Generated by *imglife* · 2026-04-22"}]}
  ]
}

Payload webhook générique

Le champ latest_base est renseigné uniquement pour les alertes applicatives (applicative_image non vide). Il contient le tag de base le plus récent disponible si une mise à jour existe, ou est absent si l’app est déjà sur le dernier tag.

{
  "alerts": [
    {
      "product": "python",
      "cycle": "3.12",
      "status": "WARNING",
      "eol_date": "2028-10-31",
      "applicative_image": "reg/apps/myapp:1.0.0",
      "base_image": "reg/base/python:3.12.0-core1.0.0",
      "latest_base": "3.12.5-core1.0.0"
    },
    {
      "product": "alpine",
      "cycle": "3.17",
      "status": "EOL",
      "eol_date": "2023-11-01",
      "applicative_image": "reg/apps/legacy:2.0.0",
      "base_image": "reg/base/alpine:3.17.9-core1.0.0"
    }
  ]
}

Sortie `--dry-run`

[dry-run] Would send 2 base alert(s) + 2 app alert(s) to 1 destination(s):
  python/3.12          WARNING  EOL: 2028-10-31
    → reg/apps/myapp:1.0.0 (update: 3.12.0-core1.0.0 → 3.12.5-core1.0.0)
  alpine/3.17          EOL      EOL: 2023-11-01
    → reg/apps/legacy:2.0.0 (on latest, no upgrade available)

Codes de sortie

Code	Signification
`0`	Succès (même si des alertes sont présentes)
`1`	Erreur (config invalide, échec d’envoi HTTP, etc.)

imglife eol

Synopsis

Flags

Exemples

Quand exécuter cette commande

Configuration

Cycles collectés

Sémantique de fusion du cache

Cycles absents à la lecture

Cible de stockage

Codes de sortie

Flux d’exécution

imglife eol notify

Flags

Exemples

Configuration

Payload Slack (Blocks API)

Payload webhook générique

Sortie --dry-run

Codes de sortie

Sortie `--dry-run`