Skip to content

Building and Releasing using Channels #1182

Closed
qcif/data-curator
#563
@consense

Description

@consense
  • Version: 11.2.4
  • Building on: win64

  • Target: win32/64

  • Aim: Allow users to receive alpha, beta or release builds via autoupdate. The type of channel would be set at runtime (depending on user-settings returned from a remote REST api). Generic server-side provider prefered. User set to channel alpha would receive alpha, beta and release updates, beta users beta and release, release users only release.

  • Problem: The process to accomplish the above may already be possible, but some information is spread across different ticket comments and at least for me not comprehensively understandable. In particular I am unsure whether my understanding describes the recommended workflow of electron-builder, seeing the project is (loving it) going through a lot of iterations in the last months. If you allow me to summarize my understanding of the necessary steps and accompanying questions:

  1. Build

    1. new version is pushed with app/package.json containing a version such as 0.12.1-alpha.1

    2. CI server could (in some external script) parse the version (e.g. 0.12.1-alpha.1) from app/package.json and execute the electron-builder build cli with channel-injecting parameter --em.build.publish.channel=alpha . This would result in alpha.yml file being created alongside of AppName 0.12.1-alpha.1.exe on the CI server.
      Question: Is electron-builder itself capable of recognizing from app/package.json that the version contains an alpha/beta prerelease tag and determine the correct publish.channel parameter itself without relying on a custom script for this?

    3. CI server uploads the yml and exe file to generic http host (e.g. using s3-deploy npm package)

    4. So S3 contains eventually a growing number of distribution versions (exe) and 3 yml files (alpha.yml, beta.yml and release.yml)

  2. Auto-update

    1. Electron app initializes autoupdater passing in the desired release channel at runtime. e.g. autoUpdater.setFeedURL({url: 'https://mys3bucketurl.com', channel: 'alpha'});

    2. Autoupdater fetches the yml corresponding to channel property passed into setFeedUrl from the generic http server.
      Autoupdater then checks, whether the version from the downloaded yml file is greater than the installed version (using semver.gt as in

      if (!isVersionGreaterThan(latestVersion, currentVersion)) {
      )
      Question: semver.gt prevents prerelease upgrades e.g. from 0.12.1-alpha.1 to 0.12.3-beta.1 (see https://github.com/npm/node-semver#prerelease-tags ). While the reasoning from semver guidelines regarding handling of prerelease tags makes sense for NPM, in this case autoupdater has no way of knowing that version 0.12.2 (which would be a valid update) exists.
      Also semver.gt will never allow jumping from a release version (e.g. 0.12.2) to a prerelease version (e.g. 0.12.3-alpha.1) which makes the whole channel concept pointless.
      Is this already solved or am I maybe making stuff more complicated than it needs to be? Or would I need to write a lambda function myself which performs this kind of semver.satisfies check and streams the exe file through from s3?

    3. Update is downloaded and event update-downloaded is being raised

edit: removed reference to cloudfront as it wasnt contributing to the core question

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions