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 · 7 comments

Comments

Projects
None yet
3 participants
@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

This comment has been minimized.

Member

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

This comment has been minimized.

Member

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 :)

@develar develar added the question label Jun 28, 2018

@AoDev

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Member

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

This comment has been minimized.

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

This comment has been minimized.

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment