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[bot]]

🦋 Changeset detected

Latest commit: ae32d772253d8b8eea457ea7ea5b3e336fa9a6cb

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	Major
electron-updater	Minor
dmg-builder	Major
electron-builder-squirrel-windows	Major
electron-builder	Major
electron-forge-maker-appimage	Major
electron-forge-maker-nsis-web	Major
electron-forge-maker-nsis	Major
electron-forge-maker-snap	Major

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[bot]]

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

Name	Link
🔨 Latest commit	ae32d772253d8b8eea457ea7ea5b3e336fa9a6cb
🔍 Latest deploy log	https://app.netlify.com/sites/car-park-attendant-cleat-11576/deploys/6702ccb8aa396700086875e3
😎 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 e0f41a859f1df20c1ca8028a108b0329650234ed

[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).

[xyloflake]

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

@Bug-Reaper please follow the steps then and report if it autoupdates :)

[Bug-Reaper]

Hey @xyloflake just wanted to let you know I tentatively plan to test this either tmmo or Thurs!

CC: @mmaietta - I can screen-record this and/or assist w/your VM setup and potentially some type of automated VM/Docker setup for tests as needed just lmk 👍

[xyloflake]

Hey @xyloflake just wanted to let you know I tentatively plan to test this either tmmo or Thurs!

Super cool! Looking forward to it :)

[xyloflake]

@mmaietta have you tested it yet?

[mmaietta]

@xyloflake Haven't had time to set up my dev environment. Will be back from vacation on 8/3

[xyloflake]

Hi @mmaietta, back yet?

[mmaietta]

Will try to get this soon. Full transparency, currently working through a family issue with someone who is EOL

@Bug-Reaper were you able to test this on your end?

[mmaietta]

Update:

• I'm currently unable to set up ArchLinux in a Parallels VM. I've attempted to follow their tutorial, but it's not picking up any bootable image for some reason when setting up a new VM. Perhaps due to me using an M2 mac?

Developer's note: Instead of using yalc, I just use resync to force copy all additional assets over to my test project (assuming the projects in the same root dir (~/Development in my case). I've saved it as an alias in my zsh profile for easy access

alias resync="rsync -upaRv --include='*.js' --include='*.d.ts' --include='*.nsi' --include='*.json' --include='*/' --include='*.py*' --include='*.tiff' --exclude='*'  ~/Development/electron-builder/packages/./* node_modules/"

[xyloflake]

@mmaietta that's quite sad to hear. I hope you through it soon and best wishes from my end. All I can say that all life on earth has to come to an unfortunate end and it's pretty sad. I hope you find the strength and courage to get over it and remember that person with all the good memories. I am so so sorry.

[xyloflake]

Update:

• I'm currently unable to set up ArchLinux in a Parallels VM. I've attempted to follow their tutorial, but it's not picking up any bootable image for some reason when setting up a new VM. Perhaps due to me using an M2 mac?

Sorry, I don't really know about parallels vm so I'll request @gamersi to help you if possible.

Developer's note: Instead of using yalc, I just use resync to force copy all additional assets over to my test project (assuming the projects in the same root dir (~/Development in my case). I've saved it as an alias in my zsh profile for easy access

alias resync="rsync -upaRv --include='*.js' --include='*.d.ts' --include='*.nsi' --include='*.json' --include='*/' --include='*.py*' --include='*.tiff' --exclude='*'  ~/Development/electron-builder/packages/./* node_modules/"

I've never even heard of resync. What we do at muffon for consistency and development testing is that we do a simple pnpm patch and then copy the electron builder source build with the out folder contents and then finally we do pnpm patch-commit. Of course it is inefficient but it's the most stable among all because yalc sometimes skips changes and it's pretty hard to say if the version was changed or not without opening node modules.

[mmaietta]

copy the electron builder source build with the out folder contents

That's what rsync is performing to copy directly from electron-builder/packages into the local project's node_modules dir . I just shortcut the command to an alias in my zsh profile so that I can simply call resync in Terminal from my app project's directory. I found it more powerful than yalc for handling additional file types via --include. Helps streamline my work on my mac 🙂

[gamersi]

copy the electron builder source build with the out folder contents

That's what rsync is performing to copy directly from electron-builder/packages into the local project's node_modules dir . I just shortcut the command to an alias in my zsh profile so that I can simply call resync in Terminal from my app project's directory. I found it more powerful than yalc for handling additional file types via --include. Helps streamline my work on my mac 🙂

Why rsync and not cp? Isn’t rsync made for copying over network?

concering the VM - you are not gonna have much luck with virtualization - there is arch Linux arm but it only has 1 maintainer who is so overworked that he sometimes doesn’t have time to update to the latest kernel. You could use that but support is bad and versions are sometimes weeks to months behind. So I would recommend to emulate x86-64