This commit adds the ability to run a Docker build for an architecture
which is not the host architecture, using qemu-linux-user. Currently
this is only supported for linux.
Added:
* Installation of qemu which supports propagated execve flags
* Copying of qemu binary into the build context
* Transposing the given Dockerfile to use the qemu binary
* Intercepting of the build stream, so the output looks *almost* exactly
the same.
Change-type: minor
Signed-off-by: Cameron Diver <cameron@resin.io>
The command line arg was taking `devicetype`, but the rest of the code
uses `deviceType`. Thus it was impossible to specify a device type
in practice to build a `Dockerfile.template`.
Change-type: patch
Signed-off-by: Gergely Imreh <imrehg@gmail.com>
This gives the user enough notice to stay well updated, but won't spam
them if they're using resin-cli frequently.
Connects-to: #485
Change-type: patch
Signed-off-by: Cameron Diver <cameron@resin.io>
This commit will highlight the usage of the cache when doing a docker
build via `resin build`, which not only helps the user understand what
the build is doing, but also achieves more parity with the cloud
builder.
Change-type: patch
Signed-off-by: Cameron Diver <cameron@resin.io>
If build is ran through `resin deploy`, then logs will be stored and
uploaded to the database, where the dashboard can display them
Change-type: minor
Signed-off-by: Cameron Diver <cameron@resin.io>
`resin build` had access to the `--nocache` and `--tag` options for
building with docker, but `resin deploy` did not. This commit adds the
options to the shared dockerUtils.appendOptions function.
Change-type: patch
Signed-off-by: Cameron Diver <cameron@resin.io>
Upon changing the name of the source parameter from `context`, some
places weren't changed, this commit fixes that.
Change-type: patch
Signed-off-by: Cameron Diver <cameron@resin.io>
Using `resin build` a user can now build an image on their own docker
daemon. The daemon can be accessed via a local socket, a remote host and
a remote host over a TLS socket. Project type resolution is supported.
Nocache and tagging of images is also supported.
Using `resin deploy` a user can now deploy an image to their fleet. The
image can either be built by `resin-cli`, plain Docker, or from a remote
source.
Change-type: minor
Signed-off-by: Cameron Diver <cameron@resin.io>
This error was introduced as part of
`9cf42462c029e038e09efc961736946be8bfcb9b`, since the `forceUpdateLock`
option being used in the `reboot` command contains a `parameter`
property despite being declared a boolean.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
New images will ship a `device-type.json` file in the first partition,
which we can use instead of querying the API for certain configuration
and initialisation commands.
If the file is not found, or is malformed, we still fallback to the API.
Signed-off-by: Juan Cruz Viotti <jviotti@openmailbox.org>
This PR adds functionality to `resin sync` to try to infer what the
device uuid is as follows:
- If the argument to `resin sync` is an app, get all the devices from
that application. If there is only one, auto-select it, otherwise show
an interactive drive selection widget.
- If the argument to `resin sync` is a uuid, use it directly, without
trying to infer anything.
- If no argument is passed to `resin sync`, display an interactive
selection widget showing all your devices from all your applications.
Signed-off-by: Juan Cruz Viotti <jviottidc@gmail.com>
Currently we log a CLI event with the passed command, however this might
include usr params, like a uuid, and therefore cause thousands of
different event names in Mixpanel.
Currently, `config generate` requires a device uuid. The command now
accepts either a uuid or an application name, and generates a
config.json accordingly.
Currently, such error will be thrown when
`resin.auth.twoFactor.challenge()` rejects, but an invalid code is not
the only thing this function can reject for.
If `updateCheckInterval` has any meanginful value, the alert will be
shown one out of ten times, or something like that, making the user
likely to miss updates.
The underlying issue is that `update-notifier`, if it detects a cached
update notification, it deletes it, and only attempts to show it back if
`updateCheckInterval` is greater than `Date.now() - lastUpdateCheck`.
A device resource needs to be registered with the API before being able
to create the `config.json` file that goes in a device.
This means thats the device image is configured and written to an
external drive (e.g: SDCard) *after* the device resource registered.
If any of the above operations fail, there will be an unitialized orphan
device living in the selected application that the user will have to
remove himself.
In my system (MBPr 13), printing the current version takes over 2
seconds:
```sh
$ time ./bin/resin version
2.4.0
./bin/resin version 1.37s user 0.19s system 73% cpu 2.130 total
```
The CLI takes almost all of these time to parse the dependency tree
before returning control over the actually called command.
To mitigate this problem, we only require the NPM dependencies a command
requires when executing such command, and thus prevent dependencies from
being required and parsed unnecessary.
After this improvement, printing the original example (`resin version`)
returns in less than a second (2x improvement):
```sh
$ time ./bin/resin version
2.4.0
./bin/resin version 0.88s user 0.09s system 102% cpu 0.938 total
```
This is useful in the scenario when the user is using the CLI in an
environment in which he/she doesn't have access to a web browser, like a
headless server or a Vagrant development environment.
Some CLI commans prompt to select an existing application, presending a
dropdown with all the application names, however it's hard to remember
which application belon to which device type, which makes it easier to
select the wrong application.
When you change the `resinUrl` config from time to time it can be
confusing to remember where you're logging in, or in which host you're
in.
Currently I have to check the configuration files/environment variables
manually or run `resin settings`.
This PR prints the detected resin url on `resin login` and `resin
whoami` so it's always clear where you are.
The command to get information about a device, `resin device` requires a
`uuid` as a parameter. Given that we don't show uuids in `resin
devices`, the user has no way to know what uuid to pass to get extra
information.
We also remove some non very used information columns from `resin
devices` to make space for the uuid.
