NervesHub has had a CLI for a long time. It is called nerves_hub_cli and for the longest time you’d add it as a dependency. But only once you found out it existed, which took me a minute…
A while back it was changed to be an escript that you could get separately from your mix project. That was a big improvement, thanks to @gus.
And thanks to various efforts by Gus and @joshknz we now have it wrapped up in a Burrito, vastly improved experience throughout the CLI and it can even be installed via Homebrew or curl.
brew install nerves-hub/tap/nh
or
curl --proto '=https' --tlsv1.2 -fsSL https://raw.githubusercontent.com/nerves-hub/nerves_hub_cli/master/install.sh | sh
You can then run this to set up your instance and then authenticate:
nh config set uri "https://manage.nervescloud.com/"
nh user auth
From there you can nh device list or nh device cert import until you are satisfied. Essentially it exposes all the typical clicking around you would do in the UI to set things up meaning NervesHub is really, really scriptable and friendly to automation.
We also have direct API integration of course. The Swagger UI is right here for NervesCloud (me and Josh’s hosted NervesHub service).
This has been available for a bit so I figured I’d give a brief update, especially since a lot of folks don’t even know there is a CLI
This is pretty nice. For some reason previously when I tried to install it using mix archives, the command never worked without specifying the full path to the escript.
As someone who just dived into this a few months ago, I expected that the CLI was doing only local stuff. It was pretty confusing at first to find out that it’s a mixed bag of both local commands and the ones that require an active connection to a instance of nerveshub_web. The way you set local state (like organization selection) in it it’s also a bit confusing and I would be in favor of explicit long commands honestly.
The mix of local and remote can definitely be a bit confusing. The fundamental design was established way back and we haven’t gone over that. Not sure when we will since it does work quite well. One big upside of the mixture is that creating a firmware signing key for an org will also put it on the NervesHub instance instead of being a separate step.
For the org and product stuff, you can just not set env vars or those values and explicitly run with --org and --product to whatever extent needed.
If it works in practice, then that is great. In my case most probably it was the learning curve, as there are a lot of things to unpack at once if you are just starting out, especially since I was also setting up nerveshub_web locally at the same time.