Electron-builder: [question] Is it possible to use custom url with S3 publish?

[mzmiric5]

We are using the electron-publisher-s3 with the electron-builder publish setting being set to our S3 bucket. This works great but it uses our S3 url to check for updates and download them. We keep a lot of our endpoints behind a CDN to enable caching and speed up download delivery to our users and we would like to use this for our updates as well.

Is it possible to configure the electron-builder publish settings to continue publishing to S3 but to use a custom base url instead of the S3 default one for both update checking and downloading?

[develar]

You can define multiple publish configs. First will be used by updater. So, define first as generic and specify your CDN url, and second your s3.

Publish is not performed for generic.

I will document it soon.

[mzmiric5]

Oh I wasn't sure if that would work, will try it out on our next update. Will this also make sure that the update url in the latest-mac.json also matches that of the generic publish setting or will it still keep the s3 path?

[mzmiric5]

@develar when I set generic as my first publish line, it causes my CI on travis to go into an infinite loop of publishing to null (the files actually upload, but the console log is just full of <FileName> to S3 after the first publishing to null output). Regardless, inspecting the files, I also find that the latest-mac.json still points the updater to the s3 path for the file download. This makes little sense as the update download then doesn't use the CDN at all.

Seems to be related to #1519

[mzmiric5]

Related to the above issue, it looks like in one of the latest updates, the builder has started using the ArtifactName property for mac zip files, but still uses the old default naming in the latest-mac.json, meaning that it points to a non existent file thus breaking auto update

[mzmiric5]

ok, so after further research into the matter, I discovered the loop that travis was getting into is caused by the new progress display of the upload for S3. Since the travis logs don't support cursor updates, it basically just keeps on spamming the output. Possibly check when on CI and disable this kind of output?

Regarding the wrong name being applied to the mac zip file by setting artifactName globally in the build properties but it using the old name in the latest-mac.json. I've solved this by just specifying the artifactName for specific targets like dmg and nsis. While this is a quick fix, the underlying issue is still there, where the produced artifact and the json url no longer match if a user customized artifactName for the zip build.

While experimenting with all this and trying to solve the problem, I've also ran into an issue where the latest.yml is no longer getting uploaded to s3. Both the nsis exe and the latest.yml file get generated, but only the exe gets published.

[mzmiric5]

looks like when I remove the generic provider, the latest.yml does end up getting uploaded to S3.

Seems like combining generic and s3 provider causes a lot of issues.