Use "Drive Mountpoint Contains Image" instead as the image may not be on
this drive but on a drive mounted in one of the mountpoins of this
drive.
We still don't want to allow flashing this drive in that situation.
Changelog-entry: Changed “Drive Contains Image” to “Drive Mountpoint Contains Image”
Change-type: patch
We add some preparatory changes including new utility functions, as well
as changes throughout the codebase that reflect the change from single
drives to a list of drives, given multi-writes is coming.
Change-Type: patch
Changelog-Entry: Various preparatory changes to account for
multi-writes.
This adds a display of the determined image size to the
drive label when the drive has been determined to be too small.
Change-Type: patch
Changelog-Entry: Display image size for comparison if drive is too small
We warn the user when they select a large drive to confirm they want to
flash in case the device is important.
Fixes: https://github.com/resin-io/etcher/issues/1916
Change-Type: patch
Changelog-Entry: Warn the user on selection of large drives.
Some devices don't have a size, like USB devices in the usbboot adaptor.
The `.isDriveLargeEnough()` correctly returns `false` in this case,
however we don't want to show the `TOO SMALL` badge for aesthetics
purposes.
So if a drive has a size that equals `null`, we don't allow such drive
to be selected, and we don't show a badge for it.
Signed-off-by: Juan Cruz Viotti <jv@jviotti.com>
This commit introduces a boolean `disabled` property rather than a
`pending` flag. Making this distinction clearer means that we can now
treat pending drives in different ways needed to improve the usbboot
experience.
Also, for usbboot, this commit removes the "pending" badge and uses a
more descriptive drive description instead.
Signed-off-by: Juan Cruz Viotti <jv@jviotti.com>
We recently added a "pending" flag to all drives that represents whether
the drive is ready for selection or not. This flag will be used by the
"usbboot" flashing adaptor, which will emit various "pending" USB
devices while it converts them to block devices that can actually be
flashed.
In terms of the GUI, the following visible changes were made:
- Drives with a `pending: true` property will be disabled in the drive
selector window
- Drives with a `pending: true` property have a "PENDING" red badge
See: https://github.com/resin-io/etcher/pull/1707
See: https://github.com/resin-io/etcher/pull/1686
Signed-off-by: Juan Cruz Viotti <jv@jviotti.com>
- Extend the `standard` ESLint configuration
- Remove ESLint rules that are defined in the `standard` configuration
- Get rid of semi-colons
See: https://github.com/resin-io/etcher/pull/1657
Signed-off-by: Juan Cruz Viotti <jv@jviotti.com>
This commit changes the whole codebase to adhere to all StandardJS
guidelines rules except semicolons, since the removal of semicolons
affect pretty much all lines, and the final diff is very hard to follow
(and to assess other more involved changes).
In a nutshell:
- When using `function`, we now require a space before the opening
parenthesis
- If a line with operators is broken into multiple lines, the operator
should now go after the line break
- Unnecessary padding lines are now forbidden
There were also some minor things that the `standard` CLI caught that I
updated here.
See: https://standardjs.com
Signed-off-by: Juan Cruz Viotti <jv@jviotti.com>
* Centralise drive error/warning messages with a function
`.getDriveImageCompatibilityStatuses` in `lib/shared/drive-constraints.js`
-- tests included
* Fix an error where several labels show at once
* Clarify the source drive label to 'Drive Contains Image'
* Remove label icons and make text bold to match Zeplin's design
Closes: https://github.com/resin-io/etcher/issues/1143
Closes: https://github.com/resin-io/etcher/issues/1144
`image-stream` returns image objects that look like this:
```js
{
stream: <readable stream>,
transform: <transform stream>,
size: {
original: <number>,
final: {
value: <number>,
estimation: <boolean>
}
},
...
}
```
While the GUI handles image objects that look like this:
```sh
{
path: <string>,
size: <number>,
...
}
```
It looks like we should share a common structure between both, so we can
use `image-stream` images in `drive-constraints`, for example.
Turns out that we actually transform `image-stream` image objects to GUI
image objects when the user selects an image using the image selector
dialog, which is another indicator that we should normalise this
situation.
As a solution, this commit does the following:
- Add `path` to `image-stream` image object
- Reuse `image-stream` image objects in the GUI, given they are a
superset of GUI image objects
See: https://github.com/resin-io/etcher/pull/1223#discussion_r108165110
Fixes: https://github.com/resin-io/etcher/issues/1232
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
Currently Etcher will allow you to flash an image to the same drive that
contains the image. As a way to protect against that case we introduce
the concept of a "source drive", which means a drive that contains the
source image.
This commit adds the following logic around this new concept:
- Don't auto-select a source drive
- De-select an already selected drive if an image inside it is selected
- Disable the drive in the drive selector modal
- Add a "Source Drive" badge to the drive in the drive selector modal
Fixes: https://github.com/resin-io/etcher/issues/830
Change-Type: minor
Changelog-Entry: Prevent flashing the drive where the source image is located.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
Currently the `DriveConstraintsModel` errors when given an `undefined`
drive, or image; this commit changes that behaviour. Comes with tests.
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
