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>
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>
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, 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`.
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.
The last part of `quickstart` feels weird. By consensus, we remove the
part that attempts to create a project directory and leave that step to
the user.
We get a weird error message from pine otherwise:
ResinRequestError: Request error: It is necessary that each app name
that is of a user (Auth), has a Length (Type) that is greater than or
equal to 4.
Current has the following problems:
- Our custom message gets printed even if the notifier doesn't contain
an update.
- The notifier box is deferred, therefore it's printed at the end of the
command. Since our custom message is printed at the beginning, it makes
no sense at all.
If the spinner message doesn't fit in your terminal, each spinner
position will be printed in different lines.
We mitigate this by dramatically shortenning the message.
Currently, the fact that `os initialize` requires elevated permissions
forced us to require calling commands that reuse it, such as `device
init` and `quickstart` with administrator permissions as well.
This ended up causing issues like saving images in the cache that belong
to root, or initializing git repositories that requires `sudo` to
commit.
The solution is to call `os initialize` as a child process preppending
`sudo` within `device init`.
Fixes: https://github.com/resin-io/resin-cli/issues/109
Currently, if `device init` was ran without an application argument, we
attempted to get the application name from the current directory, given
it was a git repository.
This approach led to confusions from time to time, so now we prompt the
user to select one of it's own applications from a dropdown instead of
checking the current directory in this edge case.
Fixes: https://github.com/resin-io/resin-cli/issues/197
`update-notifier` persist its update check results in a file, which is
then read when running again the application.
If this file gets written when the application is being run as root, we
get ugly EPERM issues.
For this we use the `update-notifier` module with its default settings.
This module will print a nice banner prompting the user to run the
corresponding npm command to update.
- Add helpers.confirm() to abstract the process of asking for
confirmation.
- Add helpers.selectDeviceType() to abstract the form needed to ask for
device types.
The functions on this module are reused by app actions.
