Version check in prometheus-exporter #139

Open
opened 2026-08-07 22:41:50 +02:00 by stb · 0 comments
Owner

In roles/unbound/tasks/prometheus-exporter.yml: how should we deal with the version check.

If we hardcode the version anyway, I think we should first check, if this version is already installed locally and only then hit the GitHub API. This avoids unnecessary steps and also avoids hitting the unreliable GitHub API for every run.
One could either use apt (via a command or facts maybe?) to check for the installed version and only get a new one, if they differ or just keep the latest dep as a sort of canary file or something and only get a new one, if it isn't as expected.
Something similar is done for the Forgejo Runner installation, see 5ecf70ade3/roles/forgejo_runner/tasks/main/01_install.yaml , tho this doesn't use apt, so can't really be adapted.

In roles/unbound/tasks/prometheus-exporter.yml: how should we deal with the version check. > If we hardcode the version anyway, I think we should first check, if this version is already installed locally and only then hit the GitHub API. This avoids unnecessary steps and also avoids hitting the unreliable GitHub API for every run. One could either use apt (via a command or facts maybe?) to check for the installed version and only get a new one, if they differ or just keep the latest dep as a sort of canary file or something and only get a new one, if it isn't as expected. Something similar is done for the Forgejo Runner installation, see 5ecf70ade3/roles/forgejo_runner/tasks/main/01_install.yaml , tho this doesn't use apt, so can't really be adapted.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
CCCHH/ansible-infra#139
No description provided.