This commit implements our own version of the `is-elevated` module. The
reason behind this is that `is-elevated` relies on lots of unnecessary
modules, that eventually require `spawn-sync` and `try-thread-sleep`,
which conditionally require dependencies that are not even declared in
their `package.json`, causing issues when concatenating the Etcher CLI.
See: https://github.com/resin-io/etcher/pull/1235
See: https://github.com/resin-io/etcher/pull/1228
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
The current error handling logic is a mess. We have code that tries to
fetch information about errors in different places throughout the
application, and its incredibly hard to ensure certain types of error
get decent human friendly error messages.
This commit groups, improves, and tests all error related functions in
`lib/shared/errors.js`.
Here's a summary of the changes, in more detail:
- Move the `HUMAN_FRIENDLY` object to `shared/errors.js`
- Extend `HUMAN_FRIENDLY` with error descriptions
- Add `ENOMEM` to `shared/errors.js`
- Group CLI and `OSDialogService` mechanisms for getting an error title
and an error description
- Move error serialisation routines from `robot` to `shared/errors.js`
- Create and use `createError()` and `createUserError()` utility
functions
- Add user friendly descriptions to many errors
- Don't report user errors to TrackJS
Fixes: https://github.com/resin-io/etcher/issues/1098
Change-Type: minor
Changelog-Entry: Make errors more user friendly throughout the application.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
There are a lot of new rules since the last time I revised the ESLint
rules documentation.
I've updated the main `.eslintrc.yml` to include some newer additions,
plus I added another ESLint configuration file inside `tests`, so we can
add some stricted rules to the production code while relaxing them for
the test suite (due to the fact that Mocha is not very ES6 friendly and
Angular tests require a bit of dark magic to setup).
This is a summary of the most important changes:
- Disallow "magic numbers"
These should now be extracted to constants, which forces us to think of
a good name for them, and thus make the code more self-documenting (I
had to Google up the meaning of some existing magic numbers, so I guess
this will be great for readability purposes).
- Require consistent `return` statements
Some functions relied on JavaScript relaxed casting mechanism to work,
which now have explicit return values. This flag also helped me detect
some promises that were not being returned, and therefore risked not
being caught by the exception handlers in case of errors.
- Disallow redefining function arguments
Immutability makes functions easier to reason about.
- Enforce JavaScript string templates instead of string concatenation
We were heavily mixing boths across the codebase.
There are some extra rules that I tweaked, however most of codebase
changes in this commit are related to the rules mentioned above.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
The path `lib/cli/cli.js` is confusing. Rename to `options.js` which is
how we were already referencing the file in `lib/cli/etcher.js`.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
There are certain application messages that should be re-used between
the CLI and the GUI. In order to allow such re-usability, we extract out
the application messages used in JavaScript into
`lib/shared/messages.js` as a collection of Lodash `_.template`
templates.
Notice this file doesn't include application messages included in
Angular templates directly since it'd be hard to refactor all of them.
We plan to move to React soon, which will allow moving the remaining
messages very easily.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
- Inline dictionary of common error codes and friendly descriptions
We used to rely on `resin-cli-errors` for this, however the friendly
descriptions set there can be usually very Resin CLI specific, and thus
confusing to Etcher users.
The dictionary, along with other error related utilities live in
`lib/cli/errors.js`.
- Print error descriptions and codes if they are found
- Move `utils.printError()` to `errors.print()`
Change-Type: minor
Changelog-Entry: Improve Etcher CLI error messages.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
The `--robot` option of the CLI causes the program to output
machine-parseable strings, which can be easily consumed by the GUI to
update progress and other information.
The problem is that if the CLI fails to parse its command line arguments
when being called from the GUI for whatever reason, the `.fail()` Yargs
handler will be called, which doesn't output error information in the
usual "robot" format, causing the GUI to not understand the error
message.
Since the `.fail()` Yargs handler doesn't have access to the passed
options, we moved the "robot" functionality to an environment variable,
which we can easily check from there.
As a bonus, this PR refactors the whole robot logic into
`lib/shared/robot.js` and adds unit tests to it.
See: https://github.com/resin-io/etcher/issues/986
Change-Type: major
Changelog-Entry: Replace the `--robot` CLI option with an `ETCHER_CLI_ROBOT` environment variable.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
`SelectionStateModel`'s methods `isSystemDrive` and `isDriveLocked`
don't depend on application state. They have been extracted in a different
AngularJS service: `DriveConstraintsModel`. The new service's actual
implementation is in `lib/src`, in order to be reused by the CLI.
Miscellaneous changes:
- Rename `lib/src` to `lib/shared`
- Refactor `drive-constraints` to throw when image is undefined
The default behaviour was to pretend that we're all good if the if
the image is not specified. We're not using this "feature", and
it can be dangerous if we forget to pass in the image.
- Make `isSystemDrive` return `false` if `system` property is undefined
- Use `drive-constraints` in `store.js`
Change-Type: patch
The CLI requires elevation permissions to actually be able to write to
drives. For this reason, it makes sense that we introduce such a check
early on.
See: https://github.com/resin-io/etcher/issues/726
Change-Type: patch
Changelog-Entry: Check available permissions in the CLI early on.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This PR makes use of `node-ipc` to emit progress information from the
child CLI to the GUI process rather than the tailing approach we've
been doing until now.
This change was motivated by the following Electron fix which landed in
v1.4.4: https://github.com/electron/electron/pull/7578. Before such fix,
Electron would not output anything to stdout/stderr if the Electron
process was running with `ELECTRON_RUN_AS_NODE` under Windows, which
forced us to implement `--log` option in the Etcher CLI to output state
information to a file.
Since this issue is fixed, we can consume the Etcher CLI output from
within `child_process.spawn`, which opens more interesting possibilities
for sharing information between both processes.
This coindentally fixes a Windows issue where the tailing module would
receive malformed JSON, causing Etcher to crash at `JSON.parse`. The
reason of this problem was a bug in the tailing module we were using.
Fixes: https://github.com/resin-io/etcher/issues/642
Change-Type: patch
Changelog-Entry: Fix "Unexpected end of JSON" error in Windows.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
The Etcher CLI displays a nice `Checksum: $checksum` message upon
completion. Since the addition of bmap support, a checksum for an image
might not be calculated, causing the CLI to display `Checksum:
undefined`.
This PR takes care of this small UX issue by only showing the checksum
message if one indeed exists.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This new version stops sending a `passedValidation` boolean property
upon completion and still throws an `EVALIDATION` error when validation
fails.
Such small chance allows us to get rid of lot of complexity related to
handling the `passedValidation` value in the application state.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
In order to get the bmap file contents to the Etcher CLI, we were
handling extraction, writing to a temporary file, then reading again,
and all sorts of other mumbo-jumbo, without realising that
`etcher-image-stream` already has this information right where we need
it (in the CLI's writer module) and in the way we need it (as plain
text).
Re-using from there hugely simplifies things.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This PR integrates `.bmap` support recently added to
`etcher-image-write` into Etcher itself.
It does it in the following way:
- It adds a `--bmap` option to the Etcher CLI.
- It saves a potential `bmap` file contents to the
`SelectionStateModel`.
- In the GUI, at the time of writing, if there is a `bmap` file content
in `SelectionStateModel`, it gets written to a temporary file and such
path is passed as the `--bmap` option to the CLI.
Since validation checksums don't make sense anymore, the finish screen
doesn't show the checksum box in this case.
Change-Type: minor
Changelog-Entry: Add `.bmap` support.
Fixes: https://github.com/resin-io/etcher/issues/171
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
When using the `--robot` option, we write to `stdout`/`stderr` using
`WritableStream#write()`. This operation is asynchronous, however we're
not waiting for the data to be flushed before calling `process.exit()`
right after emitting the `done` event.
This causes a rance condition where sometimes `done` is never written to
the log file, and therefore the GUI remains waiting forever.
Change-Type: patch
Changelog-Entry: Fix application stuck at "Finishing".
See: https://github.com/resin-io/etcher/issues/613
See: https://github.com/resin-io/etcher/issues/609
See: https://github.com/resin-io/etcher/issues/573
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
We try our best to check that the images the user select are too big for
the selected drive as early as possible, but this probes to be
problematic with certain compressed formats, like bzip2, which doesn't
store any information about the uncompressed size, requiring a ~50s
intensive computation as a minimum to find it out.
For these kinds of formats, we don't perform an early check, but instead
gracefully handle the case where the drive doesn't have any more space.
This PR handles an `ENOSPC` error by displaying the alert orange ribbon,
and prompting the user to retry with a larger drive. This is a huge
improvement over the cryptic `EIO` error what was thrown before, and
over having Etcher freeze at a certain percentage point.
Change-Type: minor
Changelog-Entry: Display a nice alert ribbon if drive runs out of space.
See: https://github.com/resin-io/etcher/issues/571
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
The Etcher CLI doesn't care if the drive exists or not. The user will
eventually find out since the CLI will output an `ENOENT` when trying to
actually write data, however its nicer from a UX perspective to catch
this early on.
Change-Type: minor
Changelog-Entry: Validate the existence of the passed drive.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
ES6 fat arrows provide reasonable `this` behaviour, which protects us
from some subtle accidental bugs, and erradicates `const self = this`
from the codebase.
Far arrows were not applied in Mocha code and AngularJS
controllers/services constructors since these frameworks rely on
`.bind()` on those functions.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
The Etcher CLI `--robot` option outputs space separated lines including
useful information in a predefined order, for example:
```sh
progress write 50% 15s 65536
```
While this is very easy to parse, a stringified JSON line is much more
convenient since:
- We don't have to write any parsing logic.
- We don't have to guess the value types (string, number, boolean, etc).
- We don't have to hardcode property names.
- We don't have to extend the parsing code if we decide to send new
commands from the CLI, or make any change to the data we output.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
After this change, the CLI becomes the only entity actually performing
I/O with the devices, and the GUI is just a wrapper around it.
When you click "Flash", the GUI spawns the CLI with all the appropriate
options, including `--ipc`, which uses an IPC communication channel to
report status back to the parent process.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
Currently, the exit codes documented in the help section was not
honoured if the CLI was ran with the `--robot` option. In this case, the
CLI would exit with code 0 even if the validation failed.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
The purpose is that defined exit codes can be reused in the GUI, so they
are kept in sync more easily.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
This makes it a bit easier to determine if a `stdout` line is a progress
state or not, rather than checking for both `write` or `check`.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
This option makes the Etcher CLI outputs state information in a way that
can be easily parsed by a parent process spawning it.
The format of the state output is:
<type> <percentage>% <eta>s <speed>
This can be easily parsed as follows:
const output = line.split(' ');
const state = {
type: output[0],
percentage: parseInt(output[1], 10),
eta: parseInt(output[2], 10),
speed: parseInt(output[3], 10)
};
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
This PR integrates the Etcher CLI code-wise, but doesn't yet handles the
distribution part of the story.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
