BigBoot/AutoKuma v1.0.0

Release v1.0.0

on GitHub

Changed

• ⚠️ BREAKING CHANGE ⚠️ AutoKuma now requires persistent storage:
  AutoKuma previously relied on using an Uptime Kuma label on monitors to store internal data, allowing it to operate statelessly without requiring storage.
  However, this approach had significant drawbacks: it always added a label to monitors managed by AutoKuma and only worked for monitors, not for other entities like notification providers, docker hosts, labels, etc.
  Starting with this version, AutoKuma will instead track its monitors using a database that needs to be stored in a persistent location.
  For a Docker Compose setup, you can use a named volume. Please refer to the example docker-compose.yml for guidance.

To prevent data loss, AutoKuma will refuse to run if it detects any old monitors with an AutoKuma label. After adding a persistent storage location, AutoKuma will need to be started once with the environment variable AUTOKUMA__MIGRATE=true set to take over any existing monitors. This environment variable can be removed afterward.

• Access to environment variables in templates restricted to variables starting with AUTOKUMA__ENV__, see #97
• Changed Monitor::proxy_id to Option, parsing now supports both numbers and strings, see #95
• File source now skips hidden files
• File source now skips unsupported file types, see #127

Added

• All CLI commands now support reading multiple files/ids/slugs at once, as well as parsing arrays of objects where applicable, #74
• Access to system_info in templates, see [#2]
• Ability to generate TOTP tokens from a TOTP secret
• Support for creating Tags from Labels, see #40
• File source now supports multiple entities per file, the ids will be named <file_stem>[<index>] accordingly, see #86
• Kubernetes integration, see #58
• File source can now follow symlinks (configurable, disabled by default)
• Add --mfa-secret to kuma CLI
• Add authentication using a jwt token:
• AutoKuma will store a jwt token after the initial login and use this for subsequent logins, alternatively a token can be supplied manually in the config
• Kuma CLI now has a login command which allows manually obtaining a jwt token
• Kuma CLI now has a --auth_token option to allow authenticating with a jwt token
• Kuma CLI now has a --store-auth option which will store the token after a succesfull login (e.g. using kuma login --store-auth [username])
• Added grace period before removing entities when the definitions vanish (e.g. when updating a container)

Fixed

• File source now skips unsupported files rather then interrupting the whole sync, see #89
• File source now supports nested folders, the ids will be in the format <folder>/<filename> without the file extension, see #28
• Add missing retry_interval alias, see #96
• Fix wrong path for websocket url, see #123