`etcher-latest-version` was kept in a separate repository in order to
re-use it with the Etcher website, however the Etcher website is not
using it at all, and we're moving towards having the website in the main
repository.
Therefore, this commit brings back the logic from
`etcher-latest-version`, but introduces it as
`lib/shared/s3-packages.js`, in order to not tie ourselves to the
AngularJS framework, and as a step towards the Etcher SDK.
As a nice little bonus, this commit adds support for an
`ETCHER_FAKE_S3_LATEST_VERSION` environment variable that can be used to
trick Etcher that there is an available update, and therefore show the
update notifier modal.
Also, this commit adds support for snapshot builds update-checks, by
checking the `resin-nightly-downloads` S3 bucket if the current version
contains a git commit hash build number.
If the version is not a production release, then the update notifier
modal doesn't present the checkbox to disable update notifications for X
days.
We also add a property called `updates.semverRange` to `package.json`,
which can be used to fine control which versions are considered as
candidates for an update notification.
This commit adds a setting called `includeUnstableChannel`, which can be
used to tweak whether unstable (beta) releases are considered or not
when checking for the latest available version.
See: https://github.com/resin-io-modules/etcher-latest-version
Fixes: https://github.com/resin-io/etcher/issues/953
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
Versionist is a small utility to automatically generate CHANGELOGs based
on a certain commit convention.
This PR adds a new `changelog` npm script that calls Versionist to
preppend a new CHANGELOG entry based on our current structure.
Dealing with links to changes between versions in GitHub is hard to
automatise with a tool like Versionist. We chose to get rid of such
links since they are a nice to have, but don't provide any meaningful
value to maintainers, since they can manually see the diffs with `git
diff`.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
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>
- Make sure we use the same tile style.
- Make sure we wrap lines in the same way.
- Use hyphens as file name separators.
- Move links to the bottom of the docs.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
This PR documents the process to upgrade the Electron version correctly,
in order to prevent any potential compatibility issue when building
native dependencies.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
We will be generating shrinkwrap files in every release for the
following purposes:
- Be able to run an `npm install` containing the exact package versions
used at the time of publishing.
- Auto-generate dependency updates CHANGELOG entries by comparing
shrinkwrap files between versions.
See: https://docs.npmjs.com/cli/shrinkwrap
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
