feat: add staged deployment update notifier - #272
Conversation
Up to standards ✅🟢 Issues
|
There was a problem hiding this comment.
Thanks for working on this!
I will properly test this soon, some thoughts/questions from me. I would appreciate if you generally explained your reasons for why you are doing certain things/what made you decide to implement things a certain way in the commit message instead of stating what you are doing because it would make reviewing and fixing it up later (when it inevitable breaks) easier
A general outline on how you intended this to work from a user perspective would also make it more clear what the intended behavior/what a bug is.
I'm curious how you tested this, I'd recommend building a sysext with sysextbuddy (see readme) and then moving that to /var/lib/extensions so it survives updates/reboots so you can properly dog food this. Documentation is kinda meh in general regarding this.
EDIT: also do sudo systemctl enable systemd-sysext.service
There was a problem hiding this comment.
It would be nice if we could get rid of this duplication with the user and system service units.
I think we might be able to use this neat systemd feature for that
man systemd.unit(5)
Unit names can be parameterized by a single argument called the "instance name". The unit
is then constructed based on a "template file" which serves as the definition of multiple
services or other units. A template unit must have a single "@" at the end of the unit name
prefix (right before the type suffix). The name of the full unit is formed by inserting the
instance name between "@" and the unit type suffix. In the unit file itself, the instance
parameter may be referred to using "%i" and other specifiers, see below.
See for an examplesystemd-zram-setup@.service systemd-zram-setup@zram0.service
There was a problem hiding this comment.
I will try testing and implementing it this way.
| case "${action}" in | ||
| enable|on) | ||
| systemctl --user enable --now "${user_path}" | ||
| sudo systemctl enable --now "${system_timer}" | ||
| sudo systemctl start "${system_service}" || true | ||
| echo "Aurora update notifications enabled." | ||
| ;; | ||
| disable|off) | ||
| systemctl --user disable --now "${user_path}" || true | ||
| sudo systemctl disable --now "${system_timer}" || true | ||
| rm -f "${XDG_STATE_HOME:-${HOME}/.local/state}/aurora/deployment-notifier/last-notified" | ||
| echo "Aurora update notifications disabled." | ||
| ;; | ||
| status) | ||
| echo "User notifier:" | ||
| systemctl --user --no-pager status "${user_path}" || true | ||
| echo | ||
| echo "System checker:" | ||
| systemctl --no-pager status "${system_timer}" || true | ||
| ;; | ||
| *) | ||
| echo "Usage: ujust aurora-update-notifier [enable|disable|status]" | ||
| exit 2 | ||
| ;; |
There was a problem hiding this comment.
We usually have one recipe entrypoint and then use gum to select actions like in this case disable|status and so on. I think this would be nice here as well.
There was a problem hiding this comment.
I will try implementing the entrypoint and selection via gum.
|
resolves: ublue-os/aurora#259 |
…nt-notifier.just Co-authored-by: renner <80410025+renner0e@users.noreply.github.com>
Thanks for the feedback and guidance.
Yeah I will keep commit changes clear from next time, this time I just copied the files overs from last pr as the structure and implementation was almost similar just pushed it as a single commit.
The general outline would be from a users perspective the notifier should just give a single notification after it checks that the system update is staged after checking if the file exists in /run (the system module checks if the update is staged via a successful finishing of uupd or time based intervals) and no more notification for the session.
For the testing I just made the modules and ran them in my aurora system and checked if they actually could push notifications and from my testing I found if first that notfier module was going in a loop after launching once as it was oneshot, later I added the
I will try packaging into a system extension and make sure that extension can survive updates. |
2 participants
Implements an deployment notification system to alert users when a system update is staged .