feat: implement autoupdates for pacman

[xyloflake]

Introducing autoupdate support for pacman!

I have updated docs & tests plus ran all tests.

I have also pushed an update to the pnpm lockfile which was auto-generated during pnpm update

[changeset-bot]

🦋 Changeset detected

Latest commit: b69f7f0

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 9 packages

Name	Type
app-builder-lib	Patch
electron-updater	Minor
dmg-builder	Patch
electron-builder-squirrel-windows	Patch
electron-builder	Patch
electron-forge-maker-appimage	Patch
electron-forge-maker-nsis-web	Patch
electron-forge-maker-nsis	Patch
electron-forge-maker-snap	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[netlify]

✅ Deploy Preview for car-park-attendant-cleat-11576 ready!

Name	Link
🔨 Latest commit	b69f7f0
🔍 Latest deploy log	https://app.netlify.com/sites/car-park-attendant-cleat-11576/deploys/66fd63efd52e890008f11eea
😎 Deploy Preview	https://deploy-preview-8394--car-park-attendant-cleat-11576.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[xyloflake]

@mmaietta @beyondkmp Is this normal?

I only added minor bumps for app-builder-lib and electron-updater as is evident by e0f41a8

[xyloflake]

As has been discussed in #8370, here's my PR @mmaietta!

[mmaietta]

Nice work @xyloflake! I'm going to work on getting a new release set up on my electron-builder-test repo so that we can have the test pacman download test pass

[xyloflake]

Nice work @xyloflake! I'm going to work on getting a new release set up on my electron-builder-test repo so that we can have the test pacman download test pass

Yay! Thank you!

As I can see, the tests fails at the Pacman test. I can't seem to figure out what went wrong.

Edit: Figured it out. It fetches the executables from your electron-builder-test repo and it can't verify on pacman because the executable for pacman was never built. I've made a PR to make your work easier. You just need to run a github action for the release now :)

[xyloflake]

@mmaietta should this PR result in major or minor version bump? I think minor as according to semver the minor in MAJOR.MINOR.PATCH must be incremented when a new feature is implemented?

[xyloflake]

@mmaietta Hi, I wanted to give you an update on the asynchronous install PR—it's about 70% complete, and I'm in the phase of making and testing changes. I've realized that this PR will require another modification once the asynchronous PR is ready because the doInstall functions need to be asynchronous.

The challenge is that I'm working on both PRs simultaneously. To avoid conflicts, one of these PRs will need to be merged after the other. Should I commit the necessary changes for doInstall in this PR or the other one?

[mmaietta]

It should be a minor bump. I'll take a look into why the Changelog CI action is showing up as a major bump. Nothing immediately stands out to me though

Regarding the rollout of this autoupdate feature. I think you'll need to do 2 releases, one with the initial pacman release with electron-updater pacman support integrated, then another release to actually trigger the pacman autoupdate feature.

Re: the doInstall logic needing to be async. Sounds like we need the async PR merged first (which I need to take a deeper review of), then we can circle back to this PR so you can merge in the latest master from that point?

[xyloflake]

It should be a minor bump. I'll take a look into why the Changelog CI action is showing up as a major bump. Nothing immediately stands out to me though

Got it! Thanks.

Regarding the rollout of this autoupdate feature. I think you'll need to do 2 releases, one with the initial pacman release with electron-updater pacman support integrated, then another release to actually trigger the pacman autoupdate feature.

That is absolutely correct, you need to make a release for 1.0.4 with initial Pacman support and then 1.0.5 for testing the update.

Re: the doInstall logic needing to be async. Sounds like we need the async PR merged first (which I need to take a deeper review of), then we can circle back to this PR so you can merge in the latest master from that point?

Seems like the most appropriate thing to do! I'm completely okay with that :)

[xyloflake]

@mmaietta can we merge this instead? And change it for pacman in the other PR.

[mmaietta]

@xyloflake how can I test this locally on a linux VM? Preferably via Parallels Desktop. I trust your testing, but I feel I should still give it a look once-over

[xyloflake]

@xyloflake how can I test this locally on a linux VM? Preferably via Parallels Desktop. I trust your testing, but I feel I should still give it a look once-over

You need some arch linux or derivative linux distro to support pacman. Otherwise there's no other way. If you want, I can give you remote access to my arch machine but we'd need to be in a call then because testing it is complicated. However I 100% do guarantee that this is not flawed and has been appropriately tested.

If you do want to use a linux VM, you need the arch VM

[xyloflake]

@mmaietta Alright I'll write up the instructions for once you get an arch VM up and running. Please use pnpm as patches are easier to configure. And most importantly, find out a way to display your version in the electron app before doing all of this as to confirm that update was indeed successful.

1. Create a sample electron app with electron builder support
2. Patch/Use yalc to link this PR's electron-updater and app-builder-lib for usage in the electron app
3. For patching you may use pnpm patch app-builder-lib and similarly for electron-updater
4. Configure feedurl provider to be generic and url being http://127.0.0.1:8080.
5. pnpm i -g http-server
6. http-server -p 8080 - of course you can change the port according to your preference but if you do, change it in 4th step as well
7. Build one version as pnpm build --linux pacman - I'm assuming you've set up the build script.
8. After completion, install first version with pacman -U yourapp.pacman
9. Then build another version after changing version in package.json
10. Open the first app after completion and relaunch if already running
11. You will receive a notification saying that update is ready and will be installed once you quit
12. Quit the application
13. Enter password (you need to have a desktop environment setup btw)
14. Relaunch the app and check version

[xyloflake]

@xyloflake how can I test this locally on a linux VM? Preferably via Parallels Desktop. I trust your testing, but I feel I should still give it a look once-over

Sorry I do not know how Parallel Desktop works and I haven't personally used it. But you'd need to setup an arch vm somehow to test this. And let me warn you before you try: installing arch is one of the most complicated things to do. One wrong command like using archinstall instead of the documented commands might break your system and drive. It's overwhelmingly frustrating and time consuming. It took me about 1.5 hours to get arch up and running.

If you have the time, patience and can afford breaking your system, I'll be happy to help. Otherwise this can go through an alpha version and once it's considered stable, we can make it beta.

[xyloflake]

I can upload a video proof of updation taking place if you want as well. My colleague @gamersi has also tested it on 2 different devices.

[gamersi]

@xyloflake how can I test this locally on a linux VM? Preferably via Parallels Desktop. I trust your testing, but I feel I should still give it a look once-over

Sorry I do not know how Parallel Desktop works and I haven't personally used it. But you'd need to setup an arch vm somehow to test this. And let me warn you before you try: installing arch is one of the most complicated things to do. One wrong command like using archinstall instead of the documented commands might break your system and drive. It's overwhelmingly frustrating and time consuming. It took me about 1.5 hours to get arch up and running.

If you have the time, patience and can afford breaking your system, I'll be happy to help. Otherwise this can go through an alpha version and once it's considered stable, we can make it beta.

On a VM you can just use archinstall, works 9/10 times as there is just one disk. Where archinstall is really bad is with custom disk configurations which you don't have on a VM.

[Bug-Reaper]

Happy to test w/Arch on real hardware if needed (been daily-driving arch since 2012).

[gamersi]

@mmaietta

I have done the full update process locally.

Here is a screenrecording and the log file:

main.log
Screencast From 2024-10-01 21-08-48.webm

[mmaietta]

Looking good! Two remaining questions. Is the "Application not responding" popup expected though (i.e. do you manually have to close the app or is it automatic as expected)? And does the app properly relaunch after update if isForceRunAfter: true?

[xyloflake]

Looking good!

Thank you!

Two remaining questions. Is the "Application not responding" popup expected though (i.e. do you manually have to close the app or is it automatic as expected)?

My extensive tests done with my team showed that manually closing the app in the best case would fail the update or in the worst case corrupt the existing application. The app should let be on its own and let it close by itself otherwise unknown consequences happen and there's a perfect 100% chance that the update won't complete.

And does the app properly relaunch after update if isForceRunAfter: true?

Yes, obviously it does. If you want, we can run that as well but I don't think it's necessary to retest (again). Is there anything that tells you something might create a problem for isForceRunAfter?

[mmaietta]

My extensive tests done with my team showed that manually closing the app in the best case would fail the update or in the worst case corrupt the existing application. The app should let be on its own and let it close by itself otherwise unknown consequences happen and there's a perfect 100% chance that the update won't complete.

I suppose that'd be the same case then as with rpm and deb updaters if the update process is interrupted, and potentially the mac updater as well (not sure how electron's autoupdater internally handles updating app resources). I don't recall those apps throwing a popup of the app not responding though.

Is there anything that tells you something might create a problem for isForceRunAfter?

Just wanted to make sure the relaunch sequence works as expected as I'm completely unfamiliar with pacman.

I think the final steps here are just to rebase/merge in latest master and then we're probably good to go.
@beyondkmp let me know if you have any feedback/comments on this PR 👀

[xyloflake]

I suppose that'd be the same case then as with rpm and deb updaters if the update process is interrupted, and potentially the mac updater as well (not sure how electron's autoupdater internally handles updating app resources). I don't recall those apps throwing a popup of the app not responding though.

Oh yea we tested for other platforms as well. The corruption happens with rpm packages as far as we know. Pacman's installation system doesn't corrupt the binaries but for sure does not install if force quitted midway. Also we've got all platforms to throw the not responding popup. As for deb, it sometimes corrupts or just doesn't install based on the installation progress. Maybe running in an isolated shell outside of the app's process would not corrupt it.

Is there anything that tells you something might create a problem for isForceRunAfter?

Just wanted to make sure the relaunch sequence works as expected as I'm completely unfamiliar with pacman.

I think the final steps here are just to rebase/merge in latest master and then we're probably good to go.

I think github has an option to "rebase and merge to master" which I quite frequently use. Can you enable that and perhaps rebase while merging to master?

[xyloflake]

@mmaietta I think I've rebased, can you check?

[mmaietta]

I think I've rebased, can you check?

Looks like no, let me see if I can tackle pulling in latest master

Maybe running in an isolated shell outside of the app's process would not corrupt it.

We're investigating having it as an async process in a detached shell, however, it breaks NSIS updaters currently. It's a future project but I have bigger fish to fry atm 😅

[xyloflake]

We're investigating having it as an async process in a detached shell, however, it breaks NSIS updaters currently. It's a future project but I have bigger fish to fry atm 😅

I think you're talking about me lol. I'm the one who opened that draft PR and reported NSIS isn't working.

[xyloflake]

@mmaietta are you talking about #8405? In that case, that'd be me 😄

[mmaietta]

Haha yep, that's you. My bad 😅

@beyondkmp any feedback on this PR? Otherwise, I think it may be good to merge. (Still trying to figure out how to get a minor semver bump without it being a major semver update per the changesets CI - right now I've set it to patch for app-builder-lib, but ideally this should be a minor bump)

[xyloflake]

Haha yep, that's you. My bad 😅

No problem 😄

I'll be working on it after my exams, which are keeping me busy atm but thank you for the acknowledgement.

[xyloflake]

@mmaietta can we merge then?