You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue arises from the recent problems caused by electron-builder updates and the fact that we are releasing 2 different apps in a single github release. When the app is built, an update file named latest.yml (for windows; for other platforms the name is added as a suffix). This causes 2 latest-linux.yml files to be generated, causing an error on the second edition build as the file already exists in the release.
Realistically, we are not really worrying about auto-update for Linux AppImage, so for now the solution is disabling the creation of this update file for the Linux platform (and Mac, since it doesn't even work there).
Right now the generation of artifacts depends on manual workflow execution via workflow_dispatch or, most commonly, a push event in the main branch. This build process depends on the configuration file notion-repackaged.sh and is used for both the vanilla and enhanced variants simultaneously. If you build, you build vanilla and enhanced, no matter what changes are or if only the enhanced variant should change.
The idea is to separate these so that they are different workflows, and you can release a new revision of the enhanced edition without releasing an unchanged vanilla edition. There should be 2 different github releases, one for the vanilla edition and the other for the enhanced edition.
Auto update, especially for Windows, seems to work out of the box. This should still work. The problem is that multiple releases is not going to work well for the auto updater. It is not capable of differentiating between github releases.
One solution for this is not relying on the github releases adapter and instead use the generic one. This would have to be implemented by an external application.
Note that electron-builder doesn't really support the scenario of multiple apps released in a single repo. Otherwise, we probably wouldn't have this issue. The feature of channels doesn't help with this problem either, it's really thought after the "stable", "beta" and "alpha" release paradigm and nothing else.
This issue arises from the recent problems caused by electron-builder updates and the fact that we are releasing 2 different apps in a single github release. When the app is built, an update file named
latest.yml
(for windows; for other platforms the name is added as a suffix). This causes 2latest-linux.yml
files to be generated, causing an error on the second edition build as the file already exists in the release.Realistically, we are not really worrying about auto-update for Linux AppImage, so for now the solution is disabling the creation of this update file for the Linux platform (and Mac, since it doesn't even work there).
Right now the generation of artifacts depends on manual workflow execution via
workflow_dispatch
or, most commonly, a push event in the main branch. This build process depends on the configuration file notion-repackaged.sh and is used for both the vanilla and enhanced variants simultaneously. If you build, you build vanilla and enhanced, no matter what changes are or if only the enhanced variant should change.The idea is to separate these so that they are different workflows, and you can release a new revision of the enhanced edition without releasing an unchanged vanilla edition. There should be 2 different github releases, one for the vanilla edition and the other for the enhanced edition.
Auto update, especially for Windows, seems to work out of the box. This should still work. The problem is that multiple releases is not going to work well for the auto updater. It is not capable of differentiating between github releases.
One solution for this is not relying on the github releases adapter and instead use the generic one. This would have to be implemented by an external application.
Note that electron-builder doesn't really support the scenario of multiple apps released in a single repo. Otherwise, we probably wouldn't have this issue. The feature of channels doesn't help with this problem either, it's really thought after the "stable", "beta" and "alpha" release paradigm and nothing else.
Relevant links:
The text was updated successfully, but these errors were encountered: