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>
* 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>
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>
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>
We use that variable in the Makefile but we're not defining it, which
means that maintainers publishing Etcher need to remember to pass that
as an option.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
- Add missing backslash that caused the command to not be interpreted
completely
- Update `electron-sign-exe.exe` to `electron-sign-exe-win32.exe` in
Makefile
- Use hyphen options instead of Windows slash style, which confuses bash
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This commits introduces the following Windows rules:
- `electron-installer-zip`
- `electron-installer-nsis`
Other changes:
- Remove `scripts/build/windows.bat`
- Update `docs/RUNNING-LOCALLY.md` to point to Makefile
- Update `docs/PUBLISHING.md` to point to Makefile
- Remove `7z` from `docs/RUNNING-LOCALLY.md` pre-requisites
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This variable was renamed to `BUILD_TEMPORARY_DIRECTORY`, but the
Makefile silently expands this to nothing and carries on with the build.
Now that the variable is expanded correctly, we must add it as an
order-only prerequisite so it gets created.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This target would easily allow us to create a package for the
application without being wrapped into an installer, which is
particularly useful to provide custom builds, or test asar related
issues, for example.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
We have a big comment block in the `electron-develop` target which gets
printed everytime the target gets executed.
After some research, turns out GNU Make will ignore the comments if they
are not indented.
See: http://stackoverflow.com/a/18363477/1641422
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This commit introduces a `RELEASE_TYPE` option to the Makefile, which
can be either `production` or `snapshot`. If its `production`, the
behaviour its same as it was before.
If `RELEASE_TYPE` is `snapshot`, the shorter version of the current
commit hash is appended to the version (replacing the
`APPLICATION_VERSION` in the Makefile, as well as the `package.json`
version inside the `.asar`), and the publish scripts get configured to
deploy to different "snapshot" locations.
This commit also reduces the size of the version tag in the bottom right
corner a bit so that it fits when the commit hash is appended to it.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
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>
