Closed benfrancis closed 2 years ago
One thing I don't know is whether gateways which are set to download pre-release updates will pull down pre-release OTA updates with a version number in this format, and how (or if) they will compare them against production versions.
Note that I've left the "pre-release" flag on GitHub releases created by the "release" workflow as an extra safety step, to make sure we don't accidentally push OTA updates out to gateways with an untested pre-release image just by using the wrong tag format.
One thing I don't know is whether gateways which are set to download pre-release updates will pull down pre-release OTA updates with a version number in this format, and how (or if) they will compare them against production versions.
The gateway will consider whatever comes first on the list https://github.com/WebThingsIO/gateway/blob/300bd36067b423abc63751dad1feed51d0e6738a/tools/check-for-update.js#L29 https://github.com/WebThingsIO/gateway/blob/300bd36067b423abc63751dad1feed51d0e6738a/tools/check-for-update.js#L38 and will compare it using the semver lib with the current release https://github.com/WebThingsIO/gateway/blob/300bd36067b423abc63751dad1feed51d0e6738a/tools/check-for-update.js#L47
Note that I've left the "pre-release" flag on GitHub releases created by the "release" workflow as an extra safety step, to make sure we don't accidentally push OTA updates out to gateways with an untested pre-release image just by using the wrong tag format.
Sounds like a good idea.
This is a proposed workflow for pre-release images, which fixes #2987.
To use this workflow you create a semver style tag with a suffix of
-alpha
or-beta
followed by a dot and then a number. E.g.1.0.1-alpha.1
or1.0.1-beta.2
.The only differences between this workflow and the "release" workflow are:
1.0.1
latest
tag to the pre-release image