[question] How can I test auto updater flow?

[AoDev]

Version

• "electron": "2.0.3"
• "electron-builder": "20.15.3"

Target

• OSX
• Windows

This is a question I posted on Stackoverflow.
Not receiving answers I wanted to "proxy" it here, I hope it's fine, let me know.

The goal is to understand and extend the docs section auto-update debugging. I am copying the question here but feel free to answer it on Stackoverflow.

"Note that in order to develop/test UI/UX of updating without packaging the application you need to have a file named dev-app-update.yml in the root of your project, which matches your publish setting from electron-builder config (but in YAML format)"

So I actually have two questions:

1. How do I actually test the auto-update flow?

Do I need to actually publish a new version to trigger an update locally? Seems pretty unclear, it would be like developing against the production server.

2. Is it possible to have a fallback for unsigned code?

I don't have yet any certificate for code signing. So the OS/app will block the auto-update. But, I'd still want to tell the user that an update is available so they can go and download the app manually. Can I do that? (going back to point 1, I'd like to be able to test this flow)

[develar]

dev-app-update.yml approach is not recommended. Simply pack your as for production. If you want to speedup, use -c.compression=store To avoid using your production server, you can use Minio

1. Create dir minio-data in your home dir.
2. Create nested dir minio-data/test-update (test-update here will be a bucket).
3. Run minio: minio server ~minio-data/
4. Add a Read policy on the minio in order for it to be accessible.
5. Grab AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY env vars from output from step 5 (minio will create keys for you on first run and will print it each time on run).

and pass these options to override publish config:

--config.publish.provider=s3
--config.publish.endpoint=http://YOUR_IP:9000
--config.publish.bucket=test-update

Set env as you want — or pass as part of run command (on Windows use set command to set env), or https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-credentials.html I prefer to use IntelliJ IDEA (WebStorm) and simply configure run configuration.

Replace YOUR_IP to one of the IPs that minio suggests as Endpoint (see output of minio server command). Do not use localhost or 127.0.0.1 if you are going to use Parallels Desktop or other VM — e.g. private external IP will allow you to build app on macOS and test on Windows.

Keep in mind that on each build channel file (latest.yml) will be updated It means that if you test upgrade and build lower version (1.0) every time but higher version (1.1) only once, you must backup channel file after build of higher version and copy every time after build of lower version otherwise, obviously, you will get "no update available".

@AoDev If you can transform my comment to doc, it will be great :)

[develar]

Is it possible to have a fallback for unsigned code?

Do not worry about it. You test not electron-updater, but your app. If updater is able to perform last final step, it means that your code is correct.

I'd still want to tell the user that an update is available so they can go and download the app manually.

Well, simply disable auto download and do whatever you want :)

[AoDev]

@develar Thanks for your explanations. When I manage to make this work I'll make something for the docs.

[AoDev]

Following your instructions with Minio,
It throws an error when trying to upload:

Error #1 --------------------------------------------------------------------------------
InvalidHeader: Header host contains invalid value
    at V4.<anonymous> (/.../node_modules/aws-sdk/lib/signers/v4.js:143:32)

[develar]

It means that you probably didn't set AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY env variables correctly.

[AoDev]

Actually, it was the endpoint that had a space (http: //192.168.0.101:9000) but your comment lead me to find it :) Thanks.

[mrfelton]

It should be noted here that you must add a Read policy on the minio in order for it to be accessible from electron. Without it you will get Access Denied errors.

See #2233 (comment)

[ahsath]

@AoDev

I don't have yet any certificate for code signing. So the OS/app will block the auto-update.

Do I need to sign my app or the OS/app will block the update? for 3 days I've been trying to get it work on a private github repo following the instructions and it just doesn't work, is because of this? I don't have any certificate building for windows 10.

[twigs67]

Ya, I spent all day yesterday just creating builds to test the electron-progressbar with the auto-update, which... was awful. Has anyone figured out a better way to test the auto-updater?

[ash0x0]

For anyone looking at this, just my two cents here. Tried Minio and the other suggested options like dev yaml and it's like develar says, auto update is not meant to be tested locally. The behavior is far off from what you get in production.
If your only concern is UI/UX then the dev yaml would be the way to go. The best way I found to test the whole thing though is using a release variant such as vx.x.x-development and publishing to the same pipeline as other production releases. This is really the best way to do it, SD speaking, because you always want to test production behavior.
I haven't found any downsides to this except having to do more downloads and having to uninstall more frequently. Github actions make it a breeze and so long as I'm on the same channel as the variant I'm testing I don't even have to worry about downloading and installing, it's done automatically as soon as the build is done.