feat: [sc-117417] Add semver support and device-os-output variable

[laupow]

Story details: https://app.shortcut.com/particle/story/117417

Adds device-os-version output. When users pass a semver or latest as the device-os-version input, it may be useful to know which Device OS version the firmware was compiled against.

[wraithan]

Latest would be good to have, but I wanted latest LTS if it is available. What about enabling something like this tilde range syntax then we can just say ~2.2 which would say "give me the latest 2.x and at minimum 2.2"? This is more like what I'd expect from a version specifier.

[laupow]

@wraithan The PR now adds support for semver device-os-version inputs.

How do the usage docs look for your use-case? Tilde versions are supported but not documented.

compile-action/README.md

Lines 20 to 28 in 0f36975

	# Target Device OS firmware version
	# Allowed values:
	# latest: the most recent Device OS version for the platform
	# latest-lts: the most recent LTS Device OS version for the platform
	# <version>: a specific Device OS version, e.g. 2.3.1
	# ^<version>: a semver range, e.g. ^5.3.0
	# For production projects, you should pin to a specific Device OS semver range, e.g. ^4.0.0
	# Required: false
	device-os-version: 'latest-lts'

[wraithan]

@wraithan The PR now adds support for semver device-os-version inputs.

How do the usage docs look for your use-case? Tilde versions are supported but not documented.

Carrot ranges are good too, they're default in npm for a reason. Works for me, looks like the build fails when latest-lts can't find an LTS version, that works for me. Wonder if we should document that or if it would be too verbose/discourage use.

The note about production is also interesting, our users do not use our platform that way, they definitely hardcode a version and leave it forever in most cases, which they can do by omiting the carrot so it's fine. Upgrades within a major, especially if the device has kept up on OS versions will (on 2.x+) be combined OTA as well as having incremental. So in many cases can skip safe mode so it feels like it'd be fine to suggest using a semver range in production, but the more risk adverse or those burned by safe mode healer + bad connectivity in the past will almost certainly hardcode an OS version.

[wraithan]

I appreciate how well tested all this code is, I was able to scroll through the tests and see how things would react, very nice.