Change manage daemon to allow retrying failed actions #2708
Conversation
|
The overall idea of retrying an application seems ok. I'll review the contents of this probably next weekend. Shellcheck is failing due to the automatic change of ubuntu-latest moving from 22.04 to 24.04. I have already reported QEMU errors in newer QEMU that is used in 24.04 a few months back with no fix. We need to downgrade that runner back to 22.04. |
|
Oh I almost forgot to mention, github actions ARM64 Linux runners are now free for public repos as of earlier this week. I need to do some refactoring to move our CI actions over from the QEMU based runners to the native ARM64 runners.
Actually this part is not the cause of the shellcheck errors. Shellcheck is running natively... not sure why it is hanging. But the change from 22.04 to 24.04 is causing shellcheck to fail so I will revert that action to 22.04. |
|
Can't reproduce the issue on local Ubuntu Noble 24.04 shellcheck. Seems to only occur on Github Actions Ubuntu Noble 24.04. I have reported the issue here: actions/runner#3667 |
|
Switching shellcheck from operating on all files at once to a single file at a time reduced github actions shellcheck runtime from ~3 minutes down to ~25 seconds while also eliminating the chance of hangs observed locally 1fa28fe |
This has bothered me ever since bookworm dropped. Now terminal appears after queueviewer window, thus, on top of it. No more half occluded terminal. This also prepares for a summary window from "Contributor update" to appear after the terminal closes.
|
New commits change from where the terminal is launched. Now it launches from manage daemon instead of from terminal_manage_multi. Old behavior: |
This is part of a larger improvement to the install/uninstall/update experience that will be ushered in with the "contributor update" #2652 PR. This PR should probably be merged first.
This adds a new Retry button as an alternative to "Send report". Hopefully users will see and use it in the event of internet issues, or when instructed to fix their system in some way, which should have these effects:
Asking for @theofficialgman to look over a couple specific changes which I think are fine, but could be problematic:
will_reinstallwhich now allows returning code 0 even if the app is uninstalled. I made this change so that updated apps, successfully uninstalling but failing to install, would actually be installed rather than refreshed if the user clicks Retry.I found one usage of will_reinstall which may have new bad behavior with this change, so I replaced it with directly checking an app's installation status. This fix itself may also cause further regressions. I'm not sure.
#manage can handle this action, but avoid spawning subprocess" comment)I vaguely remember trying to implement this once before, and there was some reason why running the "update" action was safer through a manage subprocess, but I cannot find that now nor do I see how this could cause issues.