lifecycle

La section lifecycle contrôle comment imglife récupère et stocke les données EOL.

Structure

lifecycle:
  eol_provider: endoflife # endoflife | local
  eol_target: git # git | pkgregistry
  eol_data_file: eol-data.yaml

Champs

Champ	Type	Requis	Défaut	Description
eol_provider	string	non	endoflife	Source de données : endoflife (depuis endoflife.date) ou local (lecture fichier uniquement)
eol_target	string	non	git	Où écrire le cache mis à jour : git (fichier local) ou pkgregistry
eol_data_file	string	non	eol-data.yaml	Chemin vers le fichier de cache EOL local

Providers

endoflife (défaut)

Récupère les données depuis endoflife.date pour chaque produit référencé dans sync.entries[].lifecycle.product, ainsi que pour les cycles utilisés par les build records applicatifs publiés dans le Package Registry. Les résultats sont mis en cache dans eol_data_file.

Exécutez imglife eol update pour rafraîchir le cache. Les données fraîches sont fusionnées dans le cache existant : un cycle reste connu même après la purge de ses tags miroirs par keep_last ; --prune reconstruit le cache à partir des seuls cycles collectés.

local

Lit les données EOL exclusivement depuis eol_data_file. Aucune requête réseau n’est effectuée. Utile pour :

• Environnements air-gappés
• Runtimes personnalisés non disponibles sur endoflife.date
• Tests

Cibles de stockage

git (défaut)

Écrit le fichier eol-data.yaml mis à jour dans le système de fichiers local. En CI, commitez le fichier dans votre dépôt après imglife eol update :

imglife eol update
git add eol-data.yaml
git commit -m "chore: update EOL data"
git push

pkgregistry

Uploade le fichier eol-data.yaml vers le Package Registry configuré. Utile quand le runner CI ne peut pas pousser vers git.

Format du fichier de données EOL

Le fichier suit la structure de l’API endoflife.date :

alpine:
  - cycle: "3.21"
    eol: "2026-11-01"
    latest: "3.21.3"
    latestReleaseDate: "2024-11-07"
  - cycle: "3.20"
    eol: "2026-04-01"
    latest: "3.20.6"
    latestReleaseDate: "2024-11-07"
golang:
  - cycle: "1.22"
    eol: "2026-02-01"
    latest: "1.22.12"
  - cycle: "1.21"
    eol: "2025-08-06"
    latest: "1.21.13"

La clé cycle doit correspondre à ce qu’imglife dérive via le champ track dans sync.entries[].lifecycle.

Seuil d’alerte

Le seuil d’alerte pour les avertissements EOL est contrôlé par une variable d’environnement, pas par le fichier de config :

export IMGLIFE_ALERT_CRITICAL_DAYS=30  # alerter quand l'EOL est dans 30 jours

Notifications

Configure les notifications actives envoyées par imglife eol notify. Supporte Slack Incoming Webhooks et des webhooks HTTP génériques.

lifecycle:
  notifications:
    min_status: warning            # warning | critical | eol (défaut : warning)
    slack_webhook_url: "${SLACK_WEBHOOK_URL}"
    webhooks:
      - url: "${MY_WEBHOOK_URL}"
        headers:
          Authorization: "Bearer ${TOKEN}"
          X-Custom-Header: "imglife"

Champs

Champ	Type	Requis	Défaut	Description
notifications.min_status	string	non	warning	Niveau minimal d’alerte : warning, critical ou eol
notifications.slack_webhook_url	string	non	—	URL Slack Incoming Webhook. Supporte ${VAR}.
notifications.webhooks[].url	string	oui (par entrée)	—	Endpoint HTTP pour le POST JSON. Supporte ${VAR}.
notifications.webhooks[].headers	map[string]string	non	—	Headers HTTP optionnels (ex. Authorization). Les valeurs supportent ${VAR}.

Toutes les valeurs de type string supportent l’expansion ${VAR} — la substitution est appliquée avant le parsing YAML, les secrets n’ont donc jamais besoin d’être codés en dur dans le fichier.

Voir imglife eol notify pour les détails des payloads et les exemples.