[Feat] Update Companion from web UI

[zklosko]

Is this a feature relevant to companion itself, and not a specific module?

• I believe this to be a feature for companion, and is not specific to a module

Is there an existing issue for this?

• I have searched for similiar existing issues

Describe the feature

I think it would be helpful to be able to install Companion updates from within the web UI. This is more relevant for Linux users since Mac and Windows users have desktop GUIs.

Usecases

It would make it easier for Linux users to install updates and would allow Companion to function more as an "appliance" than a software package. I am familiar with the Raspberry Pi images, but Companion is under extremely active development and it's easier to upgrade in place rather than flash an SD card yet again when bugs get fixed.

This also removes the process of clicking the "new update available" banner, landing on Bitfocus's main website, clicking "download", logging in, clicking "download" again, and selecting your system architecture just to get the update file itself. The initial install process is okay but the update process, in my opinion, is way too long.

[Julusian]

For Linux, if you are using the headless install then it's a case of sshing into it (assuming that has been setup) and running the sudo companion-update command.
But yeah I can see the value in builtin updating.

Of course, some beta builds are broken and one or two releases over the last year have failed to launch on some platforms, so you do risk needing to do the manual install to recover that

For windows and macos, I think it is too dangerous to do from the webui. From the launcher window is more plausible though. My conerrn there is that it will almost certainly prompt for a password to be able to perform the install.

So then the question becomes, what wokrflow are we trying to solve here. And how much effort do we need to put into making sure the user can't brick their install and lock themselves out by accident with a failed update

[zklosko]

I would have this be for the stable branch only. If you're installing beta software, it's fair to require the user to have more knowledge.

Updating from the launcher on Win/Mac is a good compromise. I'd imagine most Linux users are running Companion on headless setups so building them a launcher wouldn't be helpful. I do appreciate the companion-update command, and I just built an Ansible playbook around it.

The workflow I would want for the user would be:

1. User is notified of update
2. User clicks on update notification, is presented with release notes (I can open a separate ticket for this; I think the UI needs it regardless of this proposed feature) and is asked to confirm
3. User is given prompt to download current config file, acknowledge the risk of not downloading the config
4. User acknowledges file has finished downloading to safe location, clicks button for upgrade to begin
5. Companion performs software update, requesting admin privileges as needed, and Companion process restarts
6. User is returned to Companion following successful install, given prompt to check their settings and restore if needed
7. If install is unsuccessful, web page/launcher displays install failed page with error given, suggestions for user, and links to docs and download

I don't think the user needs to be shown the release notes in step 6 since they've already seen and confirmed them in step 2.

I'm thinking of Raspberry Pi users as I suggest this. I've integrated Companion deeply into the church I work at, running both our production workloads and building a/v controls. This would allow for Companion to be installed onto a Pi as more of an appliance that a user without Linux knowledge could maintain and update. I'm thinking of building a few things that would make Companion on Pi more accessible to houses of worship, and having a built-in updater would make Companion a much bigger sell to the non-nerds out there.

[Julusian]

Updating from the launcher on Win/Mac is a good compromise. I'd imagine most Linux users are running Companion on headless setups so building them a launcher wouldn't be helpful.

I agree, but it means two different workflows that probably share very little.

User is returned to Companion following successful install, given prompt to check their settings and restore if needed

I dont think we should show a restore option here. Doing that suggests that it is expected that their config will need restoring. Any restore should be the same or potentially less complete than the built-in upgrade.
But prompting to check everything is reasonable.

---

For windows/macos:

User acknowledges file has finished downloading to safe location, clicks button for upgrade to begin

At some point here we would need to jump from being within the ui to be the launcher. Final confirmation of performing the update should be done in the launcher, to confirm that they have access to that ready for the admin privileges prompt.
Maybe we could try to detect they are accessing the ui over localhost and only allow these options within the ui then? Probably too many edge cases to consider (reverse proxies etc)

User acknowledges file has finished downloading to safe location, clicks button for upgrade to begin
Companion performs software update, requesting admin privileges as needed, and Companion process restarts

Tbh these would probably both be part of the electron-updater library, so whatever that usually does (which I think is pretty much that)

If install is unsuccessful, web page/launcher displays install failed page with error given, suggestions for user, and links to docs and download

This will be the hard part. Its unlikely to be the install failing, and more usually something wrong in the build causing it to not launch. And as we have quit companion (and everything we have any control over), how do we show anything to the user?

---

For headless linux:

This should probably be based entirely around that update script. Allowing companion to invoke that will be pretty trivial to do.

But as the update will stop companion, will that mean the running upgrade script will terminate itself too? Or do we need to spawn it in the background somehow. Showing any kind of progress would mean spawning a new app/server to do that.

Maybe this could be done almost entirely by updating that tooling to not replace companion everytime, but to keep the last few updates on disk.
Then when launching companion, it can pick the correct one to use (allowing it to recover from failed updates), and if companion is stuck in a launch crash loop, then it could fallback to the previous version. Some thought will need to go into how to detect these cases; downgrading too eagerly (during random crashes) will be confusing as it will load the older config too.

Alternatively, perhaps a new small tool should be made to be its own small webui, with the sole purpose of being a web view of that updater script.

It is worth noting, this accounts for less than 10% of users, so motivating implementing either of these linux flows is a little hard (even though I would make use of it myself)

[zklosko]

Thanks for your candor (and the 'Needs beer!' label)! There's a lot more edge cases than I thought.

For Mac/Win, they're using the electron app, so let's simplify to that for this discussion. Using electron's updater will make things a lot easier; I wouldn't expect the user to use the web gui for that. I don't think we need to check for proxies or being on localhost, but I would mandate having an admin password for Companion, similar to what Buttons is doing.

For Linux, I think companion-update is its own process, as it doesn't crash during updates. It wouldn't be too hard to make a really basic Single-Page-Application the updater could run. The user would be redirected to the SPA during the update and directed back following a successful update. It would have the power to provide the user with error messages or we could statically-generate an HTML page with error messages.

Or maybe we expand companion-update to a utilities daemon that could install, backup, rollback, restore, and restart/shutdown the computer (thinking of the appliance factor again).

I agree with what you said about the user experience. It would be easier on the user to force a one-time backup to the default directory (if the user has set up multiple, we'll have to figure something out) and then make it easier to restore the backup from the Companion UI. There shouldn't be a need to download anything unless transferring data between installs. I'd imagine that's a prerequisite to this issue.