Skip to content

imglife status

imglife status [flags]

Generates a Markdown README summarising the state of all images across the three tiers: mirrors, base images, and applicative images.

Flag Default Description
--output string stdout Write the report to a file
Terminal window
# Print to stdout
imglife status
# Write to a file
imglife status --output README.md
# Commit the report to git (typical CI usage)
imglife status --output README.md
git add README.md
git commit -m "chore: update status report"
git push

The generated report includes:

  1. Table of contents
  2. Mirror images — all entries in sync.entries, grouped by target image. When several sync blocks point to the same target (e.g. a generic regex tracking the latest version alongside a fixed-tag block), their tags are merged, deduplicated, and sorted in descending version order (numeric compare, so 10 > 8). Each entry’s tags are resolved from the registry with its own anchored tag / tag_regex, normalised when os_normalize is set (3.12-bookworm3.12-debian12).
  3. Base images — all entries in build.images of type core or spe. Each block gets its own row: blocks sharing a folder but pinned to different version lines via mirror_tag / mirror_tag_regex show their own tag, build date, EOL cycle and link definition.
  4. Applicative images — all build records from the Package Registry
  5. Legend
  6. Custom blockstatus.client_zone content if configured
## Base images
| Image | Tag | Platforms | EOL | Status |
| ------ | --------------------------- | ------------- | ---------- | ------ |
| alpine | 3.21.3-core1.0.0 | amd64 · arm64 | 2026-11-01 | ✅ |
| golang | 1.22.3-alpine3.21-core1.0.0 | amd64 | 2026-02-01 | ⚠️ |
| ubuntu | 22.04-core1.0.0 | amd64 | ❌ EOL | ❌ |
## Applicative images
| Project | Image | Base | Built | Status |
| ---------------- | --------------- | ----------------------- | ---------- | ---------------- |
| myteam/myservice | myservice:1.2.0 | alpine:3.21.3-core1.0.0 | 2026-04-01 | ✅ up-to-date |
| myteam/api | api:2.0.0 | alpine:3.19.4-core1.0.0 | 2026-01-15 | ⚠️ base outdated |

Applicative image status follows a lifecycle-first rule:

  • Lifecycle OK✅ OK, with an <abbr> tooltip showing the latest available base tag when a newer one exists.
  • Lifecycle WARNING / CRITICAL / EOL → always ⚠️ outdated, even if the app is already on the most recent tag — the warning targets the mirror/base chain, not the applicative tag.
Symbol Meaning
✅ OK Lifecycle OK — hover for available update (tooltip)
⚠️ outdated Base lifecycle approaching EOL (WARNING / CRITICAL / EOL)
❌ EOL End of Life — no longer supported
⚠️ N/A No EOL data for this cycle — hover for the reason (tooltip)
Not applicable / information missing

A cycle absent from the EOL cache no longer falls back to a bare ⚠️ N/A: imglife first tries the neighboring cycles. A cycle newer than anything the provider knows inherits the previous cycle’s status when that cycle is still supported (the tooltip names it), and a cycle older than every known cycle is reported as ⚠️ outdated. ⚠️ N/A remains only when nothing can be inferred, and its tooltip states why. Run imglife eol update to fill the gap.

Above the Mirror images table, status emits GitHub-flavored alert blocks for tracked mirror images approaching or past EOL, grouped by severity: all WARNING images share a single > [!WARNING] block, and all CRITICAL and EOL images share a single > [!CAUTION] block. Healthy images produce no alert.

> [!WARNING]
> **`registry.example.com/mirrors/python:3.12-alpine`** (`python/3.12`): EOL approaching (01/10/28)
> **`registry.example.com/mirrors/node:18-alpine`** (`nodejs/18`): EOL approaching (30/04/28)
> [!CAUTION]
> **`registry.example.com/mirrors/debian:11`** (`debian/11`): EOL exceeded (30/06/26)

Add a status.client_zone block in imglife.yaml to append custom Markdown:

status:
client_zone: |
---
Pipeline runs daily at 06:00 UTC.
Contact #platform-images for questions.

See status configuration.

Code Meaning
0 Report generated successfully
1 Error generating the report