Modify os download help to mention -dev suffix
#2084
Conversation
codewithcheese
force-pushed
the
codewithcheese/append-dev
branch
4 times, most recently
from
922dbc5 to
f852d92
Compare
lib/commands/os/download.ts
Outdated
| `; | ||
| public static examples = [ | ||
| '$ balena os download raspberrypi3 -o ../foo/bar/raspberry-pi.img', | ||
| '$ balena os download raspberrypi3 -o ../foo/bar/raspberry-pi.img --version 1.24.1', | ||
| '$ balena os download raspberrypi3 -o ../foo/bar/raspberry-pi.img --version 1.24.1-dev', |
There was a problem hiding this comment.
Placing this PR on hold for a moment as I am testing -dev vs. .dev. All the following seems to cause the CLI to download something, just not sure what it is downloading...
$ balena os download raspberrypi3 -o test.img --version 2.60.1+rev1-dev
$ balena os download raspberrypi3 -o test.img --version 2.60.1+rev1.dev
$ balena os download raspberrypi3 -o test.img --version 2.60.1+rev1-nodev
$ balena os download raspberrypi3 -o test.img --version 2.60.1+rev1-foo
$ balena os download raspberrypi3 -o test.img --version 2.60.1+rev1.prod
Adding a console.error for what --version menu produces, it produces .dev rather than -dev:
$ ./bin/balena-dev os download raspberrypi3 -o /dev/null --version menu
Getting device operating system for raspberrypi3
? Select the OS version: v2.60.1+rev1.dev
OSVersion=2.60.1+rev1.dev displayVersion= 2.60.1+rev1.dev
There was a problem hiding this comment.
The boot partition of the downloaded image file contains a os-release file with contents like:
VARIANT="Development"
VARIANT_ID="dev"
or:
VARIANT="Production"
VARIANT_ID="prod"
Checking it this way, I have confirmed that -dev downloads a production image, while .dev downloads a development image.
Given that we were ourselves about to advise users of an incorrect way of downloading development images, :-) it would be nice if the CLI had some validation of versions. I have also checked that the CLI downloads a production image if an inexistent revision is given:
$ balena os download raspberrypi3 -o test.img --version 2.60.1+rev9751
It only seems to error if the main version is incorrect:
$ balena os download raspberrypi3 -o test.img --version 2.60.9
No such version for the device type
There was a problem hiding this comment.
@pdcastro hmm wow nice catch. What do you recommend going forward? Should I update this PR to .dev and then create a separate issue for version validation?
There was a problem hiding this comment.
Should I update this PR to .dev and then create a separate issue for version validation?
That's the minimum to allow this PR to be merged. :-)
Also, just thought of a test I didn't make: could you confirm that both 2.60.1.dev and 2.60.1+rev1.dev download development images? I think I tested only the latter. (They'd be different image versions, but both should be dev images.) The former is the one that this PR includes in the examples section.
There was a problem hiding this comment.
and then create a separate issue for version validation?
I have opened this balena-sdk PR: balena-io/balena-sdk#1017
[...] could you confirm that both
2.60.1.devand2.60.1+rev1.devdownload development images?
I tried testing this, but actually I couldn't find any existing non-rev version (like 2.60.1.dev) to test with! To be on the safe side, I suggest amending the example in this PR to read 2.60.1+rev1.dev instead of 1.24.1-dev.
Then we can merge this CLI PR. There is no need to wait for balena-io/balena-sdk#1017, unless you want to. The thing is that the CLI is currently on SDK 15.6.0 while the latest SDK is 15.17.0, so we'd have to test the CLI in general with the SDK changes.
There was a problem hiding this comment.
@pdcastro thanks for following up on this. I have pushed an update.
Change-type: patch Signed-off-by: Thomas Manning <[email protected]>
codewithcheese
force-pushed
the
codewithcheese/append-dev
branch
from
f852d92 to
6ebbd15
Compare
|
@balena-ci rebase |
ghost
force-pushed
the
codewithcheese/append-dev
branch
from
6ebbd15 to
7da9a80
Compare
No description provided.