This change prevents the script erroring with `BINTRAY_USER: unbound variable` when `$BINTRAY_USER` isn't defined, and instead displays the "Please define the following ..." message as expected.
We currently hardcode the temporary directory location to `/tmp`. Some
Linux systems define `$TMPDIR`, so we should attempt to re-use that
first.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
Currently, we create a "resources app" and install dependencies on it.
This means that to create another "resources app", the whole dependency
installation process needs to be repeated.
As a solution, we cache dependencies at
`release/electron-$(TARGET_PLATFORM)-$(TARGET_ARCH)-dependencies/` and
copy them to the resources apps as we need them.
This has the additional benefit that the resources app depends on the
dependencies rather than the other way around (dependencies depend on
the resources app), which didn't feel right.
In order to accomodate to these changes, the dependencies scripts are
now in charge of taking their corresponding manifests with them when the
prefix option is passed, given that neither `npm` nor `bower` allow to
customise the output location.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This Makefile ties together all the build scripts we've been developing
so far. It currently only supports UNIX based operating systems, but
Windows support will be added soon.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
Currently, `installer-appimage` creates only the AppImage, and we rely
on code outside the main task to package it up as a Zip. Since Zip is
a required step for AppImage deployment (since the AppImage will lose
its execution permissions if its moved around), we integrate Zip
generation into the AppImage task itself.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
We're currently exitting with error code 0 when displaying the usage
information on build scripts, which means that if the user forgets or
mistypes an option argument, the script will carry on its way.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
The purpose of this change is to stay true to the Makefile approach,
where each rule is meant to create a single directory/file.
Currently, `unix/dependencies.sh` resulted in `bower_components` and
`node_modules`. Splitting this rule also means that we don't have to
install bower dependencies where we don't need them (e.g: the CLI).
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
Previously, the build scripts would override the top level
`node_modules` and `bower_components`. After this commit, the
dependencies are installed directly in the Electron package.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
The logic to install dependencies on Windows now separately lives in
`scripts/windows/dependencies.bat`, similarly to what we've been done
with other operating systems.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This refactors the way that the build shell-scripts check for dependencies
in order to cut down on code duplication, and also adds additional
dependency-checks that were missing previously.
Change-Type: minor
Including them means we have to nicely display them in the final `.dmg`.
For simplicity reasons, we'll omit it for now.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
The `darwin.sh` script now accepts the following commands:
- `develop-electron`
- `installer-dmg`
- `installer-zip`
In order to accomplish this, `./scripts/darwin/package.sh` is no longer
relying on `electron-packager`.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
Making use of `codesign` directly allows us to have much more
flexibility in how we sign things, which will prove very valuable when
adapting this `sign.sh` script to code sign the Etcher CLI.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
The GNU/Linux build script (as the rest of the OSes will in the near
future), now accepts the following command:
- `develop-electron`
- `develop-cli`
- `installer-cli`
- `installer-appimage`
- `installer-debian`
Each of the commands is now completely independent from the others.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
In order to take a whitelisting approach to dependencies, the
`unix/dependencies.sh` script is ran as part of packaging as well, but
passing the `-p` (production) flag.
In the future, the current `install`, `package`, and `installer` targets
will be deplaced by `develop-<type>`, `installer-<type>`.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This is the first step towards properly publishing the Etcher CLI. The
option is not present in Windows yet, and its intentionally undocumented
for the time being.
See: https://github.com/resin-io/etcher/issues/355
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
- Unify both `linux/dependencies.sh` and `darwin/dependencies.sh` in
`unix/dependencies.sh`
- Add `-f` (force) option to `unix/dependencies.sh`
- Add `-p` (production) option to `unix/dependencies.sh`
- Allow passing a target type to `unix/dependencies.sh`
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
Related changes
- Remove AppImages related binary blob from `scripts/build/AppImages` and
fetch them from the internet instead.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
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>
