lifecycle
The lifecycle section controls how imglife fetches and stores EOL data.
Structure
Section titled “Structure”lifecycle: eol_provider: endoflife # endoflife | local eol_target: git # git | pkgregistry eol_data_file: eol-data.yamlFields
Section titled “Fields”| Field | Type | Required | Default | Description |
|---|---|---|---|---|
eol_provider | string | no | endoflife | Data source: endoflife (fetch from endoflife.date) or local (read from file only) |
eol_target | string | no | git | Where to write the updated cache: git (local file) or pkgregistry |
eol_data_file | string | no | eol-data.yaml | Path to the local EOL cache file |
Providers
Section titled “Providers”endoflife (default)
Section titled “endoflife (default)”Fetches data from endoflife.date for each product referenced in sync.entries[].lifecycle.product. The results are cached in eol_data_file.
Run imglife eol update to refresh the cache.
Reads EOL data exclusively from eol_data_file. No network requests are made. Useful for:
- Air-gapped environments
- Custom runtimes not available on endoflife.date
- Testing
Storage targets
Section titled “Storage targets”git (default)
Section titled “git (default)”Writes the updated eol-data.yaml to the local filesystem. In CI, commit the file to your repository after running imglife eol update:
imglife eol updategit add eol-data.yamlgit commit -m "chore: update EOL data"git pushpkgregistry
Section titled “pkgregistry”Uploads the eol-data.yaml file to the configured Package Registry. Useful when the CI runner cannot push to git.
EOL data file format
Section titled “EOL data file format”The file follows the endoflife.date API structure:
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"The cycle key must match what imglife derives using the track field in sync.entries[].lifecycle.
Alert threshold
Section titled “Alert threshold”The alert threshold for EOL warnings is controlled by an environment variable, not the config file:
export IMGLIFE_ALERT_CRITICAL_DAYS=30 # warn when EOL is within 30 daysNotifications
Section titled “Notifications”Configure active notifications sent by imglife eol notify. Supports Slack Incoming Webhooks and generic HTTP webhooks.
lifecycle: notifications: min_status: warning # warning | critical | eol (default: warning) slack_webhook_url: "${SLACK_WEBHOOK_URL}" webhooks: - url: "${MY_WEBHOOK_URL}" headers: Authorization: "Bearer ${TOKEN}" X-Custom-Header: "imglife"Fields
Section titled “Fields”| Field | Type | Required | Default | Description |
|---|---|---|---|---|
notifications.min_status | string | no | warning | Minimum alert level: warning, critical, or eol |
notifications.slack_webhook_url | string | no | — | Slack Incoming Webhook URL. Supports ${VAR} expansion. |
notifications.webhooks[].url | string | yes (per entry) | — | HTTP endpoint for the JSON POST. Supports ${VAR} expansion. |
notifications.webhooks[].headers | map[string]string | no | — | Optional HTTP headers (e.g. Authorization). Values support ${VAR}. |
All string values support ${VAR} environment variable expansion — the substitution is applied before YAML parsing, so secrets never need to be hard-coded in the file.
See imglife eol notify for payload details and examples.