These are dynamic dependencies we've recently added to the list of top
level optional dependencies in order to be able to resolve them when
using browserify to package the Etcher CLI.
The issue is that `thread-sleep` is using a very old `node-pre-gyp`
version (0.6.9) that doesn't support Electron at all, thus resulting in
the following error when setting `npm_config_runtime=electron`:
```
node-pre-gyp ERR! UNCAUGHT EXCEPTION
node-pre-gyp ERR! stack Error: Unknown Runtime: 'electron'
```
This commit makes these dependencies production dependencies, so we can
tweak the `node-pre-gyp` version to make it work.
See: https://github.com/resin-io/etcher/pull/1228
See: https://github.com/mapbox/node-pre-gyp/issues/281
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
We have inline instructions to install Etcher from package managers.
This commit extends them to quickly mention how to uninstall as well.
Fixes: https://github.com/resin-io/etcher/issues/1225
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
`sudo-prompt`, the module we use to provide elevation for GNU/Linux,
relies on polkit to show the elevation dialog. Polkit implements a
"backend" to control privileges, but relies on different packages to
provide a GUI frontend.
If no GUI frontend can be found on the system, then `sudo-prompt` will
fail with a `No polkit authentication agent found.` In this case, we
shouldn't present a scary stack trace to the user, and we should also
not send this error to TrackJS.
As a solution, we intercept such error in
`lib/child-writer/writer-proxy.js`, and convert it into a human readable
user error using `errors.createUserError()`, which is passed to the
Etcher GUI using the "robot" mechanism.
Fixes: https://github.com/resin-io/etcher/issues/1179
Change-Type: patch
Changelog-Entry: Provide a user friendly error message when no polkit authentication agent is available on the system.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
In the main page we show the drive description, and on hover a tooltip
shows the drive name. The tooltip behaviour is changed to show both,
un-truncated.
Closes: https://github.com/resin-io/etcher/issues/1170
Changelog-Entry: Add the un-truncated drive description to the selected drive step tooltip.
We're passing a shell conditional to `deploy.script`, however Travis CI
seems to get confused about this in the deploy section, causing
GNU/Linux to run `make publish-aws-s3` directly on the Travis CI build
instead of in the Docker container, which causes the deployment to
eventually fail because of missing dependencies.
According to Travis CI:
> `deploy.script` must be a scalar pointing to an executable file or
> command.
See https://travis-ci.org/resin-io/etcher/jobs/214723725 for a failure
example.
We also move the Appveyor deploy script to a separate file for symmetry
purposes.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
The CLI still happily let you flash an image that doesn't fit on the
drive. This commit prevents such scenario right before flashing, but we
should still implement a smarter CLI drive detection widget for when the
user runs the CLI interactively.
Change-Type: patch
Changelog-Entry: Prevent flashing an image that is larger than the drive with the CLI.
Fixes: https://github.com/resin-io/etcher/issues/858
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
Currently, the Etcher CLI will print scary stack traces for every single
error (e.g: if you forgot to pass an image to the tool), given that
`errors.getDescription()` will return a stack trace if no other
description could be found.
This commit introduces an `ETCHER_CLI_DEBUG` environment variable, which
when set, it will cause the Etcher CLI to output stack traces, plus a
boolean `userFriendlyDescriptionsOnly` option to
`errors.getDescription()`, so we can control whether
`errors.getDescription()` returns things like stack traces, or
stringified error objects.
Change-Type: minor
Changelog-Entry: Don't print stack traces by default in the CLI.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
In order to package the Etcher CLI, we concatenate all the code from the
`lib/cli/etcher.js` entry point using browserify.
There are some dependencies down the hierarchy that dynamically require
other dependencies, by enclosing `require()` calls in `try`/`catch`
blocks. The dynamic dependencies these modules require are not even
present in the `package.json`, and thus rightfully confuse browserify.
See https://github.com/ForbesLindesay/spawn-sync/blob/master/lib/spawn-sync.js#L10
See https://github.com/IndigoUnited/node-cross-spawn/blob/master/index.js#L32
There are two solutions to this problem:
- Make browserify stub these problematic dependencies with a blank file
by using `--ignore`
This approach initially looks like the way to go, however it means that
every module that requires this particular dependency will receive just
a blank stub. It might be that some other dependencies rely on them, so
this approach could cause very obscure bugs later on.
- Add them to `package.json`
This is the approach taken by this commit. We add them to
`optionalDependencies` instead of `dependencies`, so we can still make
use of tools that analyse the code base for unused dependencies.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This issue only affects GNU/Linux and macOS. If the user sends SIGINT to
the application, the main process dies, but we get an orphaned blank
browser window. The problem only seems to occur when there is a
`beforeunload` window event handlers, which we use to warn the user when
quitting while flashing.
Change-Type: patch
Changelog-Entry: Prevent blank application when sending SIGINT on GNU/Linux and macOS.
Fixes: https://github.com/resin-io/etcher/issues/1028
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
Users can currently force the browser window to reload by using Cmd+R in
macOS. The `will-navigate` event handler in this same file is supposed
to protect us from this case, however it's not fired at all just in
macOS for some reason.
As a solution, we attach dummy keyboard shortcut handlers for Cmd+R,
Ctrl+R, and F5, to override the normal browser window behaviour.
The reason behind disallowing reloads is that a reload during a critical
operation such as writing, validation, elevating, unmounting, drive
scanning, etc will cause undefined behaviour, resulting in nonsense
errors that we can't solve coming to TrackJS.
See: https://github.com/electron/electron/issues/8841
Fixes: https://github.com/resin-io/etcher/issues/1210
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
We don't actually use any build context, as we just mount the local
directory as a volume anyway. Omitting it speeds up the container
start-up time. This is an enhanced version of #1173
As removing the `node_modules` completely and then re-installing
is quite time consuming and SSD-thrashing, resort to pruning
and rebuilding native add-ons when switching targets.
Change-Type: patch
When fetching metadata, a stream is opened, but never consumed.
This destroys the stream when retrieving metadata to avoid
dangling open file descriptors and such.
Change-Type: patch
Changelog-Entry: Fix unmounting freezing in macOS.
Fixes: https://github.com/resin-io/etcher/issues/985
This changes the `.travis.yml` to use the `node_js` language
as a base instead of `cpp` to avoid installing & setting up node
manually.
Change-Type: patch
`pip install awscli` outputs the following warning:
```
Running setup.py install for PyYAML
checking if libyaml is compilable
i686-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c build/temp.linux-x86_64-2.7/check_libyaml.c -o build/temp.linux-x86_64-2.7/check_libyaml.o
build/temp.linux-x86_64-2.7/check_libyaml.c:2:18: fatal error: yaml.h: No such file or directory
#include <yaml.h>
^
compilation terminated.
libyaml is not found or a compiler error: forcing --without-libyaml
(if libyaml is installed correctly, you may need to
specify the option --include-dirs or uncomment and
modify the parameter include_dirs in setup.cfg)
```
The installation gracefully continues anyway (the `--without-libyaml` is
automatically forced).
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
- Mention the production and snapshot S3 bucket
- Remove the note that `aws-s3.sh` doesn't run on Windows
- Don't document `./scripts/publish/aws-s3.sh`. Encourage maintainers to
use `make publish-aws-s3` instead
See: https://github.com/resin-io/etcher/pull/1078#discussion_r107259159
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This commit introduces the phony `package-cli` target, used to package
the Electron CLI in a directory.
Other related changes:
- The `package` target has been renamed to `package-electron`
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This commit addresses some issues with snapshot builds that we didn't
caught given we never ran the deployment step in a "real" deployment
scenario.
- On Travis CI, the service reverts all changes in the source tree
before starting the `deploy` section, which seems to trigger some
issues when deleting `node_modules`. The solution is to set the
`skip_cleanup` option
See
https://s3.amazonaws.com/archive.travis-ci.org/jobs/213614487/log.txt
```
...
warning: failed to remove node_modules/helper-date/node_modules/moment/locale/es.js
warning: failed to remove node_modules/helper-date/node_modules/moment/locale/ky.js
warning: failed to remove node_modules/helper-date/node_modules/moment/locale/pt-br.js
warning: failed to remove node_modules/helper-date/node_modules/moment/locale/hu.js
warning: failed to remove node_modules/helper-date/node_modules/moment/locale/en-nz.js
...
```
- On Appveyor CI, `curl` is not installed
See
https://ci.appveyor.com/project/resin-io/etcher/build/job/54i0erd9tsa1cg5p
as an example.
See: https://github.com/resin-io/etcher/pull/1078
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This commit makes Appveyor and Travis CI publish snapshot builds to S3
when a pull request is merged, by making use of the `publish-aws-s3`
Makefile target.
The changes required for such type of deployment are the followings:
- Set `S3_BUCKET` to `resin-nightly-downloads` when doing snapshot
builds
- Add deploy sections to `.travis.yml` and `appveyor.yml` that run `make
publish-aws-s3`
- Don't change `PRODUCT_NAME` when doing snapshot builds (given we'll be
publishing to a different S3 bucket)
- Install `awscli` in Appveyor CI and Travis CI
- Make GNU/Linux Docker containers inherit `AWS_ACCESS_KEY_ID` and
`AWS_SECRET_ACCESS_KEY` from the environment (so `awscli` is
configured correctly inside them)
- Add a prefix option to `aws-s3.sh` publish script to prepend a string
to the S3 path, so we can add a timestamp to more easily distinguish
files inside the `resin-nightly-downloads` bucket
- Print the published URL from `aws-s3.sh` for convenience purposes, so
we can click it when skimming through CI builds logs
- Add the `-R` and `-L` options when recursively copying `node_modules`
during a snapshot build to prevent weird Appveyor errors related to
hard links. The options listed before make sure that we recursively
resolve every link while copying
- Move from `wget` to `curl` to avoid certificate check failures
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
We believe this issue fixes the "rawr i'm a dinosaur" error on certain
problematic images.
Gives this only happens on a minority of images, we couldn't confirm
that the fix really solves the issue, but we'll include the upgrade on
the next Etcher version and see how it goes in the real world.
Change-Type: patch
Changelog-Entry: Fix "rawr i'm a dinosaur" bzip2 error.
Fixes: https://github.com/resin-io/etcher/issues/734
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
upx allows to reduce the package size by some mega bytes, but also
considerably slows down the application start time.
This commit ditches upx, since we can re-gain those benefits (and even
increase them) by other means (e.g: minifying JavaScript).
See: https://github.com/resin-io/etcher/issues/1138
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
We show the friendly drive name on the main page with the drive's device name
or mount point now inside a tooltip. Drive names longer than 11 characters are
truncated with a middle ellipsis.
Change-Type: minor
Changelog-Entry: Show friendly drive name instead of device name in the main screen.
Closes: https://github.com/resin-io/etcher/issues/1170
* chore: fix `lzma-native` build issues on Windows
We've been recently hitting a weird `lzma-native` build error on Windows
(both locally and on Appveyor CI):
```
Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
build
The input line is too long.
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" exited with code 1. [C:\projects\etcher\node_modules\lzma-native\build\liblzma.vcxproj]
```
After a lot of experimentation, we realised the issue was gone if we
removed `node-sass` from the development dependencies.
The issue is that `node-gyp` was recently upgraded to v3.6.0, which was
picked up by `node-sass`, which declares `node-gyp` as a dependency. For
some reason, if `node-sass` causes `node-gyp` to be updated, then
`lzma-native` fails with the above cryptic error.
I was able to trace down the error to the following `node-gyp` commit:
ae141e1906
As a solution, this commit starts to shrinkwrap development
dependencies, and locks `node-gyp` to v3.5.0 until the issue is fixed.
Fixes: https://github.com/addaleax/lzma-native/issues/30
See: https://github.com/nodejs/node-gyp/issues/1151
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
* chore: ensure some modules in npm-shrinkwrap stay at specific versions
* Address code review comments
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!)
We've recently had an incident were the `angular-mocks` version we were
running was incompatible with the `angular` version.
Each AngularJS core module is versioned equally, therefore we can write
a small script that automatically tests that they match, so we're
guarded against forgetting to similarly upgrade different dependencies.
See: https://github.com/resin-io/etcher/pull/1168
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
The event data may contain absolute paths that contain user information that
should not be logged in Mixpanel. Instead, we replace absolute path properties
with their base name.
Change-Type: patch
Changelog-Entry: Don't include user paths in Mixpanel analytics events.
I've noticed that errors reported to TrackJS appear twice. Turns out
that TrackJS pipes output of `console.error()` as errors, rather than as
extra logging.
The `AnalyticsService.logException()` function reports the exception to
TrackJS using `$window.trackJS.track()`, but then prints it to `stderr`
as well (so it appears on DevTools), causing TrackJS to report that one
too.
The solution is to disable the `console.error` boolean property of the
`_trackJs` object. From the TrackJS documentation:
```
// By default any calls to console.error() will automatically trigger an
// error. Set this to false if you don't want console.error() to
// trigger errors.
error: true,
```
See: http://docs.trackjs.com/tracker/configuration
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
* fix the command so it actually works - see https://github.com/lucasdemarchi/codespell/issues/101
* check the spelling of more files
* ignore known-binary filetypes
* fix a couple of spelling mistakes it caught
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
* feat(GUI): improve analytics events
This commit adds more events to our current analytics.
Will further improve in a future commit.
Change-Type: patch
See: https://github.com/resin-io/etcher/issues/1100
* refactor(gui): use single function to set normal and dangerous settings
Change-Type: patch
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This is the architecture of the Raspberry Pi 3. The following changes
were necessary:
- Detect the architecture using `uname -m`
- Set the Debian equivalent architecture to `armhf`
- Handle the new architecture correctly on `dependencies-npm.sh` and
`electron-download-package.sh`, referring to it as simply `arm` (which
is what `node-gyp` expects)
This PR also includes `architecture-convert.sh`, which is a script to
find an architecture equivalence for Node and Debian.
Steps to test this PR:
- `make electron-installer-debian` from a Raspberry Pi 3
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>
https://github.com/brigade/scss-lint now says "NOTICE: Consider other tools
before adopting SCSS-Lint", and recommends sass-lint as an alternative.
sass-lint has the additional advantage of being written in NodeJS, which means
it slots nicely into our existing infrastructure, and we can completely
remove our build-time dependency on Ruby.
If the drive scanning scripts cause an error, the error will be
presented to the user over and over again. Not only this is terrible UX,
which even makes hard to close the application since dialogs keep coming
in, but it also spams TrackJS, our error reporting service, and makes it
seem that errors happened dozens of times, and thus obscuring real
trending errors.
Change-Type: patch
Changelog-Entry: Stop drive scanning loop if an error occurs.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
We recently started hitting the following errors in all our CI builds:
```
TypeError: angular.module(...).info is not a function
at /etcher/node_modules/angular-mocks/angular-mock
```
The `.info()` function was released in AngularJS 1.6.3. We declare
`angular-mocks@^1.6.1` as a development dependency, which means that
once 1.6.3 was out, npm started resolving `angular-mocks@1.6.3`, however
that version is incompatible with the main Angular version we're
shrinkwrapping (1.6.1), and thus the error.
As a solution, I've upgraded both `angular` and `angular-mocks` to
1.6.3, but also locked down `angular-mocks`, since similar errors will
happen again unless we manually keep these versions in sync.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
