We don't really do x64 builds for OS X at the moment, but nice to make
the build scripts consistent.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This is the first step towards decoupling the build system as many
different scripts, for maintainability and convenience purposes.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
When running the install script as root (e.g. inside a Docker container), bower complained that it
"shouldn't" be run with sudo. When running the x86 install multiple times, it tried to move
Etcher-linux-ia32 inside the existing Etcher-linux-x86/ folder, rather than renaming it, which meant
later commands failed.
If we pass relative paths as arguments to the AppImage, they get
resolved from `/tmp/.mount_XXXXXX/usr`. We can exploit this to run the
Etcher CLI directly from the AppImage, rather than having to mount it
ourselves:
```sh
ELECTRON_RUN_AS_NODE=1 Etcher-linux-x64.AppImage bin/resources/app.asar [OPTIONS]
```
By using this little trick, we get rid of both our custom mounting logic
and the need of surrounding the command to run in single quotes,
therefore avoiding a whole new kind of escaping issues.
Since running the CLI directly from the AppImage means that the
`desktopintegration` will be ran for the CLI, we pass the `SKIP`
environment variable to avoid having it prompt the user for
installation.
We also updated the `desktopintegration` script to the latest version,
which reduces the amount of logging plus other minor fixes.
Fixes: https://github.com/resin-io/etcher/issues/637
Change-Type: patch
Changelog-Entry: Fix Etcher leaving zombie processes behind in GNU/Linux.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This PR zips the package that is built by running:
```sh
.\scripts\build\windows.bat package <arch>
```
And puts it in `etcher-release/installers`.
Fixes: https://github.com/resin-io/etcher/issues/760
Change-Type: minor
Changelog-Entry: Publish standalone Windows builds.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
AppImages need to be marked as executables before they can be used.
Distributing them directly means that virtually all web browsers will
automatically remove the execution permissions, leading us to have to
explain users how to add it back with `chmod`, etc.
For simplicity purposes, we'll be distributing AppImages inside ZIPs,
which ensure the execution permissions are added back when the user
decompresses it.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
We translate function arguments (e.g: `$1`, `$2`, etc) to readable names
using shell variables in the top of every shell function in the build
scripts.
Since we were not declaring these variables as `local`, two functions
using the same "argument name" would override each other.
For example:
```sh
function foo() {
variable=$1
# Do something with $variable
}
function bar() {
variable=$1
# Do something with $variable
}
foo "Hello World"
echo $variable
> Hello World
bar "Changed variable"
echo $variable
> Changed variable
```
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
The `$output_package` variable is defined inside the `package_x$ARCH`
functions, which means that if we run the following commands:
```sh
./scripts/build/linux.sh package x64
./scripts/build/linux.sh appimage x64
```
The `$output_package` variable will not be defined when the script runs
the `appimage` command.
To workaround this issue, we declare a new `$package_directory` variable
inside the `appimage` command clause.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
Debian packaging tools cannot analyze the binaries if they are compressed
with upx. If we move the compression to the appimage command, then the
output of the package command can be used for building debian packages.
With this addition, the `package` command simply creates a standalone package, while "appimage" is the one that creates the actual AppImage. The "all" command still generates the AppImage as before.
This results in ~10MB savings, which is not much, but still worth
reducing as much as we can.
See: https://github.com/resin-io/etcher/issues/711
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
We were previously requiring users to run the exact same NodeJS version as
Electron bundled in order to avoid native add-on compilation incompatibilities,
however this problem is completely mitigated by configuring NPM to build
against an Electron specific V8.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
Currently build scripts install dependencies and package everything on
every run. In order to allow more customisation, the build scripts now
accept the following commands:
- `install`: Only install dependencies.
- `package`: Only package the application.
- `all`: Install dependencies and package the application.
The above differentiation allows us to improve the documentation and CI
configuration files to point to the `install` commands instead of having
to explain how to configure NPM correctly, since that's done by the
build scripts by default.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
The `$OWD` environment variable, which stands for "Original Working
Directory" is set in recent AppImageKit versions and equals the
directory from where the AppImage was run.
We set the open dialog default path to this environment variable for
consistency with other GNU/Linux applications.
Change-Type: patch,
Changelog-Entry: Set dialog default directory to the place where the AppImage was run from in GNU/Linux.
See: 1569d6f854
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>
Currently we had AppImage scripts and other resources in various
different places in the code base.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
If you run an `npm install` and then run `npm shrinkwrap`, the resulting
shrinkwrap file will contain the installed optional dependencies, making
them "required". If such optional dependency is platform dependent, `npm
install` will fail on different platform.
This is a known `shrinkwrap` limitation whose only workaround seems to
be manually filtering out platform specific dependencies from
`npm-shrinkwrap.json`.
For this purpose, we introduced the following changes:
- A custom `shrinkwrapIgnore` property in `package.json`, where we can
list specific modules that need to be filtered out from
`npm-shrinkwrap.json`.
- A NodeJS script to generate `npm-shrinkwrap.json` and omit modules
specified in `shrinkwrapIgnore` automatically.
- An NPM script called `shrinkwrap`, for convenience.
- Add `macos-alias` and `fs-xattr` to `shrinkwrapIgnore`.
- Regenerate `npm-shrinkwrap.json` based on newer dependencies from PRs
created before we introduced `npm-shrinkwrap.json` but merged after that
file was in place.
See: https://github.com/npm/npm/issues/2679
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
Currently, when the AppImage was being ran as `root` we would attempt to
run `./usr/bin/etcher`, assuming we were inside the AppDir already and
the relative path would resolve correctly.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
Consider the case where a previously elevated mount was not unmounted
correctly. `mount | grep $(basename $APPIMAGE)` would evaluate to a
multi-line string, and therefore `awk` will perform its work on *each*
line separately, usually returning something like:
```
/tmp/.mountXXXX
/tmp/.mountYYYY-elevated
```
We then pass `$mountpoint` to `mkdir -p`, which evaluates to:
```
mkdir -p /tmp/.mountXXXX
/tmp/.mountYYYY-elevated
```
Therefore `/tmp/.mountXXXX` gets created, and
`/tmp/.mountYYYY-elevated` is ran as an executable, causing all sort of
cryptic errors to come out. This can be even worse, since the third
column of a `mount` line is not always a path, so the errors make even
less sense.
Fixes: https://github.com/resin-io/etcher/issues/482
Fixes: https://github.com/resin-io/etcher/issues/459
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
This dependency is not used directly by our build scripts, but its used
by `node-gyp` when building native modules, and its much nicer to show a
warning early on than having to halt the build script in the middle for
missing this dependency (specially on Windows systems).
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
Since the addition of a patch to only install production dependencies on
build scripts, the Windows build would fail when reaching to
`electron-builder`, since this dependency might not be installed at that
point.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
This allows the users to continuously run the build script without
having to remove `etcher-release` or certain files inside that directory
to prevent silly "file exists" errors.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
Not building Etcher with the exact NodeJS version bundled with Electron
can cause all sorts of weird issues. This was previously documented, but
its now enforced so Etcher packagers don't forget by accident.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
With the addition of native addons to Etcher, its no longer possible to
package the application for all operating system in a single host.
Given we need to build on Windows, we're creating cross-platform bash
and batch scripts and deprecating the original Makefile.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
Otherwise, the `.` is interpreted as a period in a regular expression,
which matches every literal character, causing some packages deep in
the `node_modules/` hierarchy to be ignored for no reason.
For example, if we ignore `.git`, then a package like `foo-git` will be
excluded from the final package.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
This is useful to prompt the user to install the `.desktop` file.
The `Description` key in `Etcher.desktop` was changed to `Comment` since
`desktop-file-validate` complained with:
Etcher.desktop: error: file contains key "Description" in group "Desktop
Entry", but keys extending the format should start with "X-"
After checking the desktop file format specification, the correct key
should be "Comment"
(https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s05.html).
See: bc6e519964 (commitcomment-17164442)
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
