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>
JSCS has merged with ESLint. This is the perfect excuse to move to
ESLint and unify both JSHint and JSCS hints under ESLint.
This PR also deprecates `gulp lint` in favour of `npm run lint`.
See: https://medium.com/@markelog/jscs-end-of-the-line-bc9bf0b3fdb2#.zbuwvxa5y
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>
* Document `can-ignore` module.require annotation
This annotation was introduced in: 1872d1f
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
* Trigger CI build
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 binary used when spawning the CLI in OS X during development is
`electron-prebuilt/disk/Electron.app/Contents/MacOS/Electron`.
To make sure we catch both `Electron` and `electron`, make the
executable name lowercase before comparing it.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
The CLI now attempts to detect whether it is being run as an argument to
a JavaScript runner (like node or electron), or as a final packaged
executable by applying some heuristics on the first argument.
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>
