Check if there is an upgrade available every now and then #208
Labels
No Label
abra
abra-gandi
awaiting-feedback
backups
bug
build
ci/cd
community organising
contributing
coopcloud.tech
democracy
design
documentation
duplicate
enhancement
finance
funding
good first issue
help wanted
installer
kadabra
performance
proposal
question
recipes.coopcloud.tech
security
test
wontfix
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/organising#208
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
we obviously don't want to do that every time you run abra, but we could run a check when you run commands that connect to the internet. To additionally minimise the internet footprint we can simply get a random number every time so that there's a 20% chance the code executes, and/or we could have a small file ~/.abra/.lastupdatecheck that would have the date and time of last check and if i.e. at least a day passed since then it's gonna check again. Simple and elegant, and if it can't check it can throw a DEBUG or INFO message. Additionally we can utilise concurrency to not slow things down: so a new thread would be spawned on startup that would run concurrent to the normal code and then right before abra exits it could print the last line like:
INFO: there is a new abra version available. To install it run abra upgrade
and then we can also have another file like ~/.abra/.newversion that will store this info and if this file exists abra will always show this information and won't even run the code to check for a new version.Ah great you brought this up!
I like this proposal for the CI UI/UX!
Some more points for consideration...
abra app ls -S
shows if there are updates available right now also but bear in mind, it checks the catalogue, not the upstream image hub! So there are two sources of upgrades here:Some prior art from Cloudron on upgrades in general which we discussed before:
Cloudron has a daemon running on the host which is polling every x minutes for upgrades and then sending an email that an upgrade can be done.
Cloudron does auto upgrades on minor and/or patch releases and sends a mail when they're done.
I wonder would having a small separate golang program which uses
abra
as a library and sits on the server and polls running applications. This might also feed into having our own monitoring also! Cloudron also mails if your app gets killed because of an OOM error, then you would get a mail? This might be a separate thing tho.In any case, any progress here would be great!
i was actually thinking about updates to abra itself, sorry forgot to put it in the issue 😆
making a daemon that automatically checks the upgrades for your apps is in my opinion way better than integrating this option into abra, as it will be a substantial amount of code that will introduce new bugs, and require maintaining. If it turns out to not be useful it's easier to just deprecate another project than to remove the code from the app itself. We could also use existing programs for that like grafana.
Sorry if this is incoherent my mind is all over the place 😆 let me know if you need any clarification
All good :) Made #236 for the general auto-update discussion for apps.
Ah, this ticket was originally about having
abra
tell users if there is a new version ofabra
itself available! It just got confusing in the discussion and went off-topic.abra
still can't do this 😄