Support channels for Github provider

[MaKleSoft]

• Version: 19.6.3
• Target: win, mac

When using the github provider, electron builder always generates latest.yml and latest-mac.yml, even for alpha/beta releases.

I dug into the source code and the problem seems to be this part: https://github.com/electron-userland/electron-builder/blob/master/packages/electron-builder/src/publish/PublishManager.ts#L476

The channel is correctly extracted from the file name but not assigned to the options object for any provider other than generic. However, looking at the source code of electron-updater it looks like the Github provider should support channels as well?

[MaKleSoft]

Ok so it seems that as of now, GithubProvider is always looking for latest.yml regardless of the actual channel: https://github.com/electron-userland/electron-builder/blob/master/packages/electron-updater/src/GitHubProvider.ts#L62

Does this mean channels are simply not supported for the Github provider at this point? Is this an oversight or intentional? Seems like it would be trivial to implement this?

The whole channel implementation seems kind of broken imo. Why do we need separate channel files in the first place? Or why separate files for all platforms for that matter? Wouldn't it be easier to simply have one latest.yml and have all the information in there? Something like:

alpha:
  version: 2.0.0-alpha.1
  releaseDate: '2017-06-21T20:25:04.622Z'
  win:
    githubArtifactName: padlock-setup-2.0.0-alpha.1.exe
    path: Padlock Setup 2.0.0-alpha.1.exe
    sha512: ...
    sha2: ...
  mac:
    githubArtifactName: padlock-2.0.0-alpha.1-mac.zip
    path: Padlock-2.0.0-alpha.1-mac.zip
    sha512: ...
beta: ...
stable: ...

[MaKleSoft]

Another problem is that for the generic provider, information about previous releases is lost when latest.yml is updated which is a problem if you want to roll back a release for example. Imo it would be more appropriate to have a releases.yml, like so:

- version: 2.0.0-alpha.1
  releaseDate: ...
  win:
    githubArtifactName: padlock-setup-2.0.0-alpha.1.exe
    path: Padlock Setup 2.0.0-alpha.1.exe
    sha512: ...
    sha2: ...
  mac: ...
- version: 1.5.0
  releaseDate: ...
  win:
    githubArtifactName: padlock-setup-1.5.0.exe
    path: Padlock Setup 1.5.0.exe
    sha512: ...
    sha2: ...
  mac: ...

It is then trivial for the client to download the releases.yml file and figure out the latest appropriate version for a given channel. For managing the releases.yml file, I see two options:

1. Explicitly store the state in a releases.yml file that is commited to source control. This file is augmented on every release.
2. Generate the file from the git meta data. Storing artifact-related information like checksums and file names could be a challenge, but we might be able to use git-notes for that.

I like option 2, because we could use the same logic to extract all necessary release information directly from a github repo. That would mean that no latest.yml or releases.yml would be required for the Github provider at all!

[develar]

GitHub doesn't support channels because GitHub releases has concept prerelease. You can set allowPrerelease (https://github.com/electron-userland/electron-builder/wiki/Auto-Update#AppUpdater-allowPrerelease) and it will act as a beta channel.

We don't use monolithic releases file, because it simplifies building on different CI and machines.

[develar]

that is commited to source control. This file is augmented on every release.

You should build on CI servers because of security reasons. And CI server cannot commit files.

[develar]

Github doesn't report checksums for files, so, explicit meta info file is required.

[MaKleSoft]

GitHub doesn't support channels because GitHub releases has concept prerelease. You can set allowPrerelease (https://github.com/electron-userland/electron-builder/wiki/Auto-Update#AppUpdater-allowPrerelease) and it will act as a beta channel.

But I think we can agree that github prereleases don't offer all the functionality that channels do? What if I want to have an alpha channel in addition to a beta channel? Is there any reason we can't enable proper channel support for github as well? Seems like it would require changing only a couple of lines of code...

You should build on CI servers because of security reasons.

Can you elaborate on that? Not sure how building on a CI server is more secure that building locally.

Github doesn't report checksums for files, so, explicit meta info file is required.

Like I said, git notes could be used for that.

We don't use monolithic releases file, because it simplifies building on different CI and machines.

Ok, lets forget about a 'monolithic' releases file, although I do think it would be the cleaner solution.

Can we at least add proper channel support for the github provider, please? I'd be happy to tackle it myself if you're willing to accept a PR for this.

[develar]

Seems like it would require changing only a couple of lines of code...

In general, yes, can be supported. Do you mean that you release alpha version release on Github?

Not sure how building on a CI server is more secure that building locally.

VM is clean and guaranteed to be not infected. No side effects because of local machine configuration.

I'd be happy to tackle it myself if you're willing to accept a PR for this.

👍 PR will be accepted (that's why this issue was not closed).

[develar]

Moved to backlog to keep issue list clear.

[MaKleSoft]

@develar Got it. Might be a little while before I can tackle this.