When users run commands with a debug build, they see a warning that
debug builds may have worse performance. Add instructions to BUILDING.md
so that users who wish to install from source know how to get a release
build.
I tested the command locally and ran `container --version` to verify
that I got a release build.
This matches other container commands that rely on user arguments at the
end, such as `container run`. Closes#395.
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
0.5.0 introduces a new way to configure the containers and execs. This
is now done all upfront at constructor time in a callback style. I'm
very happy with the config improvements, but because IO can only be
setup at constructor time this makes it so that we need to supply IO at
creation time of the VM or exec, which isn't the end of the world. All
that really changes is `boostrap()` and `createProcess()` now take in IO
instead of slightly later in `process.start()`
The demonstration is that patch versions can be updated without breaking
changes, and that minor versions include breaking changes.
Please excuse the small documentation commit, just caused me a moment of
confusion.
readabilityHandler is a bit crummy if it's a regular file. This just
writes our own loop and exits and shuts down the write end of the pipe
if we get to the end of the file.
Looks like we've been ignoring the "cause" field for
ContainerizationError when sent over xpc. Add the cause to the
`ContainerXPCError` message field instead of a new `cause` field since
`Error` is not encodable. The goal here is just to preserve information.
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
I want to access the different variants of an image in my app, which
information is only available in the ImageDetail. Although the function
ClientImage.details() -> ImageDetail and its return type are already
public, its properties aren’t, which prevents access to this
information.
Changed `SandboxSnapshot` initializer from `package init()` to `public
init()` to enable external package consumers to create and use
`SandboxSnapshot` instances in their custom Sandbox plugins.
The `SandboxSnapshot` is used for `container list` functionality
* Closes#148.
* Storing the default nameserver in the bundle config means that DNS
won't work if the container stops and then restarts later when the
subnet address has changed.
Define a `UnpackStrategy` function type in the `SnapshotStore` to give
more control over how an image is unpacked.
Previously, we were creating a 512 GB sparse block file for the initial
file system of a container, which is overkill.
With this change, the vminit image is unpacked to a smaller block file,
while container images are unpacked to the 512 GB block
Follows the same pattern as
https://github.com/apple/container/blob/main/Sources/Helpers/RuntimeLinux/RuntimeLinuxHelper.swift#L71
Signed-off-by: Aditya Ramani <a_ramani@apple.com>
See discussion below for example. For multiple network interfaces in a
single container we'll want to integrate against a containerization that
includes apple/containerization#156.
The change bumps the containerization dependency to 0.2.0 and addresses
the breaking API changes.
```console
% container network
OVERVIEW: Manage container networks
USAGE: container network <subcommand>
OPTIONS:
--version Show the version.
-h, --help Show help information.
SUBCOMMANDS:
create Create a new network
delete, rm Delete one or more networks
list, ls List networks
inspect Display information about one or more networks
See 'container help network <subcommand>' for detailed help.
```
Tags on the repo should be a way to classify an item instead of denoting
workflow or status of the item. Remove the addition of the triage label
on bug and feature issues.
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
Github now has a "Type" feature for issues. Types are set at the
organization level and can be used for consistent classification of
issues across an organization. We'd like to switch to using these to
classify if an issue is a bug or feature instead of labels. Labels will
be used for more granular classification within a repo.
See [github
docs](https://docs.github.com/en/issues/tracking-your-work-with-issues/configuring-issues/managing-issue-types-in-an-organization)
for more information about GitHub Issue Types.
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
Danny Canter