Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[question] How can I test auto updater flow? #3053

Closed
AoDev opened this issue Jun 28, 2018 · 10 comments
Closed

[question] How can I test auto updater flow? #3053

AoDev opened this issue Jun 28, 2018 · 10 comments

Comments

@AoDev
Copy link

@AoDev AoDev commented Jun 28, 2018

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.

  1. 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
Copy link
Member

@develar develar commented Jun 28, 2018

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
Copy link
Member

@develar develar commented Jun 28, 2018

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
Copy link
Author

@AoDev AoDev commented Jun 28, 2018

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

@AoDev
Copy link
Author

@AoDev AoDev commented Jun 28, 2018

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
Copy link
Member

@develar develar commented Jun 28, 2018

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

@AoDev
Copy link
Author

@AoDev AoDev commented Jun 28, 2018

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
Copy link

@mrfelton mrfelton commented Jul 27, 2018

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
Copy link

@ahsath ahsath commented Jan 12, 2019

@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
Copy link

@twigs67 twigs67 commented Nov 7, 2019

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
Copy link

@ash0x0 ash0x0 commented Mar 1, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants