Now that the Redux store is no longer front-end dependent, we can move
most of the models to lib/shared. Currently, lib/shared is a mess, and
contains all sorts of functionality, however moving things out of the
GUI is the first step. Once we have everything decoupled, we can
organise all the code we have there.
Signed-off-by: Juan Cruz Viotti <jv@jviotti.com>
After https://github.com/resin-io/etcher/pull/1569, the redux store can
run outside of a browser context. This commit moves it to `lib/shared`,
where we will likely move all the other models as well. As an extra, I
renamed `Store` to `store`, since there was no reason for that variable
to be capitalized.
Change-Type: patch
Signed-off-by: Juan Cruz Viotti <jv@jviotti.com>
We're currently persisting the user settings in localSettings by using a
redux plugin called redux-localstorage. As a way to decouple the redux
store from a technology that is browser specific, this commit makes the
following changes:
- Create local-settings.js, which is concerned with managing settings in
a persisting location
- Decouple the redux store from the persisting storage method
- Extend the settings model to persist settings, cache reads, etc
Change-Type: patch
Signed-off-by: Juan Cruz Viotti <jv@jviotti.com>
- Exclude *.dll/*.exe files from the asar in non-Windows operating
systems (from 19.8.0)
- Correctly parse boolean flags in `--extraMetadata` (in v19.9.0)
See: https://github.com/electron-userland/electron-builder/releases/tag/v19.9.1
Change-Type: patch
Signed-off-by: Juan Cruz Viotti <jv@jviotti.com>
This commit is the first on a series of commit to incrementally
implement support for configuration files (so we avoid a huge PR like we
have at the moment).
Once of the first things we can do is replace the `SET_SETTING` redux
action with an atomic `SET_SETTINGS` action that sets all the settings
for the application at once.
The purpose of this change is that later the `SET_SETTINGS` action can
be modified to stringify all the settings and store them in a
configuration file, without having to deal with merges, conflicts, etc
(since the client application if forced to resolve those problems before
calling the `SET_SETTINGS` action.)
The behaviour of the code remains almost the same, with the exception
that the user can now set settings that we don't know about, so the user
can switch between Etcher versions without getting weird errors if one
of the configuration keys he has doesn't exist in the other version.
See: https://github.com/resin-io/etcher/pull/1382
Change-Type: patch
Signed-off-by: Juan Cruz Viotti <jv@jviotti.com>
Etcher supports disabling the update notification dialog by setting the
`ETCHER_DISABLE_UPDATES` environment variable.
In order to simplify disabling updates for when these are managed by a
package manager (e.g. in a debian package), this removes support for the
`ETCHER_DISABLE_UPDATES` environment variable, and instead requires
packagers to tweak the `updates.enabled` property of the package.json
file, which is set to `true` by default.
We don't want to encourage end users to disable the update mechanism, so
the documention was removed from `USER-DOCUMENTATION.md`. This option
will remain as something only packagers should tweak.
Change-Type: minor
Changelog-Entry: Remove support for the `ETCHER_DISABLE_UPDATES` environment variable.
Signed-off-by: Juan Cruz Viotti <jv@jviotti.com>
Electron v1.6.1 introduced checkbox support to the native message
dialog, giving us everything that was needed to implement the update
notifier modal using a native dialog.
This change allows us to get rid of a lot code.
See: https://github.com/electron/electron/pull/8590
Change-Type: patch
Changelog-Entry: Turn the update notifier modal into a native dialog.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
* 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
We limit the Store state flashing percentage to be within 0-100,
throwing errors otherwise. Comes with tests.
Changelog-Type: Bound flash progress percentage within 0-100 range.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
`etcher-latest-version` was kept in a separate repository in order to
re-use it with the Etcher website, however the Etcher website is not
using it at all, and we're moving towards having the website in the main
repository.
Therefore, this commit brings back the logic from
`etcher-latest-version`, but introduces it as
`lib/shared/s3-packages.js`, in order to not tie ourselves to the
AngularJS framework, and as a step towards the Etcher SDK.
As a nice little bonus, this commit adds support for an
`ETCHER_FAKE_S3_LATEST_VERSION` environment variable that can be used to
trick Etcher that there is an available update, and therefore show the
update notifier modal.
Also, this commit adds support for snapshot builds update-checks, by
checking the `resin-nightly-downloads` S3 bucket if the current version
contains a git commit hash build number.
If the version is not a production release, then the update notifier
modal doesn't present the checkbox to disable update notifications for X
days.
We also add a property called `updates.semverRange` to `package.json`,
which can be used to fine control which versions are considered as
candidates for an update notification.
This commit adds a setting called `includeUnstableChannel`, which can be
used to tweak whether unstable (beta) releases are considered or not
when checking for the latest available version.
See: https://github.com/resin-io-modules/etcher-latest-version
Fixes: https://github.com/resin-io/etcher/issues/953
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
Currently, both of these functions accept two arguments: the error
title, and the error description. This function signature makes is hard
to keep adding options to these error creation functions, like an error
code, so this commit refactors them to take a single argument: an
options object containing `title` and `description` properties.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
We remove the usage of Angular from 'FlashStateModel' and its usage
throughout the project comes under the new 'flashState' moniker.
Depends: https://github.com/resin-io/etcher/pull/1261
`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>
* chore: get the CI tests working again
* an updated eslint-plugin-lodash was creating extra linter errors where we
were using built-in String methods instead of the lodash equivalents
* an updated codespell package now installs with a different executable-name
(no .py extension), and now supports multiple dictionaries
* while I was at it I replaced the messy double-quoting-string logic with the
command-join module
Changelog-type: patch
* chore: downgrade codespell to 1.9.2 because the latest version has issues running on Windows
(we'll hopefully be able to revert this commit when codespell works again properly!)
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>
This is one step towards enforcing the linter until we barely have to
check for style issues on code reviews.
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 type in `@type` should be surrounded by curly braces
- We should use `@type` in some cases where we used `@property`
- `@module` descriptions should go above such tag
- Namespaces should not declare their access type
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
Currently Etcher will auto-select a system drive if its the only
available one when the "unsafe mode" is enabled, which doesn't feel
right.
Change-Type: patch
Changelog-Entry: Don't auto select system drives in unsafe mode.
See: https://github.com/resin-io/etcher/pull/1061
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>
We currently attempt to read extra metadata from ZIP files, such as a
logo, image name, image url, etc. In order to simplify the metadata
story, we decided that this metadata will not live on the image itself,
but rather on a centralised repo, which greatly simplified our custom
archive extraction logic and allows us to make use of these nice
features even when streaming the image directly from the internet.
We'll be working on bringing back this functionality from a centralised
repo in subsequent commits.
Change-Type: major
Changelog-Entry: Remove extended archives metadata extraction logic.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This is a long lasting task. The `etcher-image-stream` project takes
care of converting any kind of image input into a NodeJS readable
stream, handling things like decompression in betwee, however its a
module that, except for weird cases, there is no benefit on having
separate from the main repository.
In order to validate the assumption above, we've left the module
separate for almost a year, and no use case has emerged to keep it
like that.
This commit joins the code and tests of that module in the main
repository.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This commit extracts the byte-related conversions from the `byte-size`
AngularJS module and the `FlashStateModel` to a re-usable generic
CommonJS module at `lib/shared/units.js`, than can also be used by the
CLI.
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
System drives in the drive-list widget now have a red warning label
beneath. Also new is the `isSystemDrive()` method under
`SelectionStateModel` and its unit-tests.
See: https://github.com/resin-io/etcher/issues/888
Changelog-Entry: Label system drives in the drive-list widget
Recently, we've added support for a `recommendedDriveSize` property in
the `manifest.json` of extended image archives, which the image can use
to warn the user that his drive, even if it is large enough to hold the
image, might not be large enough to deliver a good usage experience
later on.
When this property is found, the GUI reacts in the following ways:
- Drives that are large enough to hold the image but don't meet the
recommended drive size are tagged with a warning label in the drive
selector component.
- Attempting to select a "labeled" drive opens a warning modal asking
for user confirmation.
- Drives that don't meet the recommended drive size declared in the
image won't get auto-selected.
- If there is a drive already selected, and the user picks an image
whose recommended drive size is greater than the drive size, the
currently selected drive gets auto-deselected.
Code-wise, the following significant changes have been introduced:
- Implement `SelectionStateModel.getImageRecommendedDriveSize()`.
- Implement `SelectionStateModel.isDriveSizeRecommended()`.
- Extract `WarningModal` out of the settings page (the dangerous setting
modal).
Change-Type: minor
Changelog-Entry: Allow images to declare a recommended minimum drive size.
See: https://github.com/resin-io-modules/etcher-image-stream/pull/36
Fixes: https://github.com/resin-io/etcher/issues/698
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>
We've recently added support for a `supportUrl` property in an archive
image `_info/manifest.json`, which the publisher can use to define the
URL where it would like to redirect users facing problems.
This PR makes the "Need help?" link at the top right corner open the
configured `supportUrl` url, and fallback to the original Etcher's help
page if no `supportUrl` is found.
In order to accomplish this, we made the following changes:
- Implement `SelectionStateModel.getImageSupportUrl()`
- Implement `HeaderController` controller
Change-Type: minor
Changelog-Entry: Make the "Need help?" link dynamically open the image support url.
Fixes: https://github.com/resin-io/etcher/issues/662
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>
We were currently throwing a validation error if the error code was not
string when setting the flash results, however a number error code makes
sense in some cases, and its what its returned by a `ChildProcess`
object.
Change-Type: patch
See: https://github.com/resin-io/etcher/issues/609
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
Currently, the client application knows too much about how the flash
results are stored in the internal state, and relies on its structure to
perform its logic.
This PR introduces several getters to `FlashStateModel` and makes
`FlashStateModel.getFlashResults()` private, ensuring clients don't
depend on the flash results object.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
`ImageWriterService` currently has two responsibilities. It contains
logic to start and manage a flash process, and provides an API to
interact with the current flash state.
To honour the single responsibility principle, we extract
`FlashStateModel` from `ImageWriterService`.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
We recently introduced a feature where a single available drive would be
auto-selected even if the user didn't select an image.
This introduces a potential scenario that brings the state to an
incoherent state:
- Start Etcher.
- Let a drive get auto-selected.
- Select an image larger than the auto-selected drive.
In this case, the drive is known to not have enough space to hold the
image, but remains auto-selected.
This PR makes sure the drive is deselected automatically in the above
scenario.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
Currently, we intentionally prevent a drive from being auto-selected if
there was no selected image for UX purposes, however this way of
thinking has been challenged, and we didn't find a real UX problem by
doing this.
As a minor design improvement, we gray out the drive name in the main
window when an image hasn't been selected yet.
Change-Type: minor
Changelog-Entry: Perform drive auto-selection even when there is no selected image.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
Instead of storing the whole selected drive object, we barely store a
reference to the corresponding drive in the available drives array (the
reference being the drive device).
This greatly simplifies the application state in the following ways:
- The drive metadata (size, description, etc) is not duplicated in the
state, enforcing a single source of truth.
- If the selected drive stops being available (e.g: is unplugged), the
reference doesn't hold anymore, making this functionality very natural
to implement.
- Makes `SelectionStateModel.isCurrentDrive()` much more inuitive, since
we don't have to document that changes in the metadata of the drive
object, or extra keys such as `$$hashKey` don't change the result of
this function.
- Ensures the state never goes into a problematic state where we try to
to write to an unavailable drive.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
