This allows the user to bypass the drive selection dialog.
This option can be used along with `--yes` to make the command
completely non-interactive. For example:
$ resin os initialize rpi.img 'raspberry-pi' --drive /dev/disk2 --yes
If the spinner message doesn't fit in your terminal, each spinner
position will be printed in different lines.
We mitigate this by dramatically shortenning the message.
Currently, the fact that `os initialize` requires elevated permissions
forced us to require calling commands that reuse it, such as `device
init` and `quickstart` with administrator permissions as well.
This ended up causing issues like saving images in the cache that belong
to root, or initializing git repositories that requires `sudo` to
commit.
The solution is to call `os initialize` as a child process preppending
`sudo` within `device init`.
Fixes: https://github.com/resin-io/resin-cli/issues/109
Currently, if `device init` was ran without an application argument, we
attempted to get the application name from the current directory, given
it was a git repository.
This approach led to confusions from time to time, so now we prompt the
user to select one of it's own applications from a dropdown instead of
checking the current directory in this edge case.
Fixes: https://github.com/resin-io/resin-cli/issues/197
This enforces all clients to use the Resin Settings Client version that
the SDK provides, reducing incompatibilities caused by different modules
requiring different Resin Settings Client versions.
Consider the following case:
The SDK is configured to point to staging, but the user passes a token
from production, or viceversa. Since the token is valid in a sense that
is valid JWT and contains real data, the CLI will report as a success.
The user will then get Unauthorized errors when using the API.
`update-notifier` persist its update check results in a file, which is
then read when running again the application.
If this file gets written when the application is being run as root, we
get ugly EPERM issues.
Since we're now forcing users to rely on `npm` directly for updates, we
can also get rid of plugin commands that attempt to
install/update/remove using npm programatically and require users to use
`npm` directly as well.
This commit removes the following commands:
- `plugins`
- `plugin install`
- `plugin update`
- `plugin remove`
Despite plugin related commands being removed, *the functionality that
scans for plugins and registers them remains intact*.
For this we use the `update-notifier` module with its default settings.
This module will print a nice banner prompting the user to run the
corresponding npm command to update.
We were currently building this path ourselves, hardcoding the place of
the resin local per user directory instead of relying on the foundations
that `resin-settings-client` give us.
There were two issues that prevented this command from working
correctly:
1- `Promise.delay()` is used, but `Promise` was not imported.
2- The following line had incorrect indentation (spaces instead of
tabs):
poll().nodeify(done)
Therefore CoffeeScript interpreted that the line had to be executed at
the end of the `poll()` function, causing `poll()` to never be called.
Since the public key string is long, it might wrap to lines below,
causing the table layout to break.
A quick solutio is to print the ssh key after the table.
Fixes:
- https://github.com/resin-io/resin-cli/issues/151
PubNub keeps the process alive after a history query for some reason, so
trying to print the logs history like:
$ resin logs <uuid>
Will result in the logs being printed correctly, but the process waiting
infinitely without ending.
The workaround consists in forcing `process.exit` to exit the process
with an error code zero.
Caveats:
- This workaround prevents this command to be used programatically.
Issue: https://github.com/resin-io/resin-cli/issues/14
Main changes:
- Use the `columnify` module to display the commands instead of using
manual parsing.
- Extract logic to create a string representation from an option
signature to Capitano, and reuse here.
See https://github.com/resin-io/capitano/pull/28
Some bugs were caught and fixes during the refactoring:
- In command help, if the command didn't exist, we reused default
Capitanos command not found function which uses `process.exit(1)`. This
was changed to pass a custom error to `done()`, so the command fails
correctly when using programatically.
- General help didn't call `done()` at all, thus causing problems if
using the command programatically someday.
- Add helpers.confirm() to abstract the process of asking for
confirmation.
- Add helpers.selectDeviceType() to abstract the form needed to ask for
device types.
The functions on this module are reused by app actions.
This functionality is outdated and not using anymore due to limitations
in the way it was addressed.
The module and dependencies are removed for now, and will be added back
in the future, once a better approach is planned.
We added this because we thought that knowledge of the supported device types, along with the configuration procedures was going to be encoded in the CLI.
With device specs, this is not longer the case.
