We currently compile CSS into `build/css`, however we plan to use
node-gyp in this project, which can't be configured to build to a
directory other than `build`, therefore, the compiled CSS must move
somewhere else.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This change makes Travis CI spawn 3 jobs:
- GNU/Linux with TARGET_ARCH=x64
- GNU/Linux with TARGET_ARCH=x86
- macOS with TARGET_ARCH=x64
We add `make info` before starting the build for convenience.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
Currently, `electron-installer-appimage.sh` deletes temporary stuff it
needs as it goes (like the AppDir, AppImageAssistant, or even the
AppImage after creating a ZIP). Since this is not very Make-friendly,
the script has been split into the following smaller scripts that
perform a single task:
- `electron-create-appimage-linux.sh`
- `electron-create-appdir.sh`
Utilising them in different Makefile rules effectively results in Make
persisting the "temporary artifacts".
See: https://github.com/resin-io/etcher/pull/913#discussion_r90801230
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This will allow us to later publish development builds for both
architectures from Appveyor. In order to easily do so, the Makefile is
used instead of the current `./scripts/build/windows.bat`.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
`$(error ...)` (and `$(warning ...)`) functions in a Makefile can't be indented - if they are make displays a `*** commands commence before first target. Stop.` error.
This commit adds new rules to create directories and sets order only
pre-requisites to the existing rules as a way to centralise directory
creation, which is currently scattered around all the build scripts.
See: https://github.com/resin-io/etcher/pull/923#discussion_r90881453
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
If there are any files publishable to S3 then a `publish-aws-s3` target will
automagically exist, and similarly if there are any files publishable to
Bintray then a `publish-bintray-debian` target will automagically exist.
Like all phony targets, these get displayed by `make help` when available.
By changing the `Makefile` to use `jq` instead of `node` for getting settings
from `package.json`, the time to do `make help` drops from over 1.5 seconds to
under 0.05 seconds!
This makes it easier to have re-usable functionality that we can
call/source from all scripts, like logic to determine the current
operating system, or to check for a dependency in the `$PATH`.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
Also sets `help` as the default target, so that typing just `make` displays
the list of possible targets. Also customises the list of targets based on
TARGET_PLATFORM (because you can't build e.g. `electron-installer-dmg` when
you're on Linux).
Code-signing in OS X now relies on the presence of a
`CODE_SIGN_IDENTITY` variable. If it doesn't exist, all the builds will
gracefully complete without code-signing.
As a consequence of this change, the `electron-installer-dmg.sh` script
has been divided into `electron-create-readwrite-dmg.sh`,
`electron-create-readwrite-dmg.sh`, and `electron-sign-dmg.sh`.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
Currently, `scripts/unix/electron-download-package.sh` contains its own
logic to determine if the package was already downloaded.
This commit takes the electron package uncompressing task to the
configure scripts, and reduce `electron-download-package.sh` to a script
that simply downloads the zip to a certain location, since this change
allows us to have a separate Make rule to download the Electron zip (and
thus have Make take care of caching).
After this change, the `electron-configure-package-*.sh` scripts are no
longer routines that modify a certain directory, but scripts that take
the zip as an input and actually create the package directory, which
aligns better with Make's design.
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>
Additionally, we setup an EditorConfig rule to automatically switch to
tab style on Makefile.
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>
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>
By locking the electron version in `package.json`, we can require it
from the Makefile to ensure production and development are both running
the exact same electron version, and ensures they don't easily get out
of sync.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
* Upgrade Electron to v0.37.6
The main motiviation for such upgrade is that an error manifesting
itself as `Cannot read property 'object' of undefined` on certain Linux
systems was fixed in v0.37.4.
See https://github.com/electron/electron/issues/5229
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
* Make use of shell module by requiring `shell`
Otherwise we get a strange issue when trying to stub it:
TypeError: Attempted to wrap undefined property openExternal as function
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>
This PR fixes a frequent issue users were having where opening
`Etcher.app` would result in:
"Etcher.app" is damaged and can't be opened. You should move it to
the trash.
Checking the code-signature of the application returned the following
error message:
$ spctl -a -v Etcher.app
Etcher.app: invalid signature (code or signature have been modified)
The solution is based on the following paragraphs from Apple's "OS X
Code Signing in Depth" technical note:
https://developer.apple.com/library/mac/technotes/tn2206/_index.html
> Code signing uses extended attributes to store signatures in non-Mach-O
> executables such as script files. If the extended attributes are lost
> then the program's identity will be broken. Thus, when you ship your
> script, you must use a mechanism that preserves extended attributes.
>
> One way to guarantee preservation of extended attributes is by packing
> up your signed code in a read-write disk image (DMG) file before signing
> and then, after signing, converting to read-only. You probably don't
> need to use a disk image until the final package stage so another less
> heavy-handed method would be to use ZIP or XIP files.
In summary, what we now do is:
- Create a temporal read-write DMG image.
- Perform the code-signing *inside* the DMG image.
- Convert the temporal DMG image into a compressed read-only image.
Sadly, this custom workflow doesn't fit in `electron-packager` nor
`electron-builder`, so we had to re-implement the features those
packages provide us in a nice encapsulated way ourselves.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
The `bluebird` module contains a directory called "release", which gets
omitted by `electron-packager`.
After some experimentation, there doesn't seems to be a way to make
`electron-packager` ignore a pattern only on the current directory,
therefore we change the name of our output directory to something that
can't possibly collide with something else.
