This PR defines the snapshotter protocol
```swift
///Mount a snapshot and all its previous layers
func prepare(_ snapshot: Snapshot) async throws -> Snapshot
/// Commit a snapshot, making it permanent.
func commit(_ snapshot: Snapshot) async throws -> Snapshot
/// Remove a snapshot from snapshot store
func remove(_ snapshot: Snapshot) async throws
```
It updates executors to work with this new protocol
This PR introduces the `Differ` with methods:
```swift
// Differ protocol
func diff(base: Snapshot?, target: Snapshot) async throws -> Descriptor
func apply(descriptor: Descriptor, to base: Snapshot?) async throws -> Snapshot
```
It also introduces `DiffKey`, which is a MerkeTree based key for fast
diff computations between two dirs
- Sets up API server as source of truth for installation root, similarly
to what was done for the data root. `system start` establishes the
install root, setting the environment variable `CONTAINER_INSTALL_ROOT`
when launching the API server.
- The API server propagates the environment variable when launching
helpers, and returns the install root to the CLI via the health check
XPC.
- Includes several fixes for detecting plugins that use app bundle
layout.
- Part of #384.
- Rename to reflect that these are not just client defaults.
- Relocate so callers don't need the heavyweight coupling to
ContainerClient to access the type.
Closes#339.
This change adds named volume support to container, providing volume
management CLI commands - `create, delete, list and inspect`. The
implementation uses EXT4 block-based persistent storage with a new
`VolumesService` actor for thread-safe operations, integrates seamlessly
with the existing container mount system through a new `.volume`
filesystem type, and provides atomic volume operations with XPC-based
API communication. Volumes are stored in isolated directories with
configurable sizes (default 512GB) and include proper cleanup and
container usage tracking for safe deletion.
Example Usage:
```
# Create a volume
container volume create mydata
# Use volume in container
container run -v mydata:/data alpine
# List volumes
container volume list
# Inspect volume details
container volume inspect mydata
# Clean up
container volume rm mydata
```
Remove the option token from the dockerfile tokenizer for the native
builder. This cleans up some of the logic around handling options
depending on if they're instruction options or user provided options to
a command.
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
This PR adds support for CMD and LABEL instructions in the native
builder's parser.
This also changes how options are tokenized. Options now include the raw
string so that when constructing a command for instructions like CMD and
RUN, we can use the exact user input without having to add logic in the
tokenizer to know when we're parsing a command verses other options,
etc.
Closes https://github.com/apple/container/issues/428 and
https://github.com/apple/container/issues/429
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
Closes: #314
This change uses the new `.hosts` config entry
on Containerization's LinuxContainer config to setup a default
/etc/hosts file in the container. Today the two entries are localhost to
127.0.0.1 and the container's IP to its hostname.
We're working on making a pure swift container image build system that
leverages containerization. This PR represents our initial design and
initial work towards this goal.
The native builder is still in active development and most of the
implementation has not been started or completed. We will be opening a
series of issues that represent various (but not necessarily all) pieces
of work that need to be done here.
There are docs included in this PR that describe the overall design of
each component and outline some of our goals. The easiest way to view
the docs by themselves (since this is a massive PR) is to look at the
docs commit in the `Commits` tab.
We'd love any feedback!
@wlan0
---------
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
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>
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.
```
This PR resolves a race condition when removing a container immediately
after stopping it, caused by the `stop` command returning before the
container fully transitions to the stopped state (#130).
**Changes:**
- Enhanced `TestCLIRmRace.swift` with robust test logic and helper
methods (`containerExists`, `safeRemove`).
- Improved error handling to distinguish race conditions from successful
removals.
- Added exponential backoff retry logic for cleanup operations.
- Updated `CLITest.swift` with missing `doRemove` method.
- Fixed `BuilderStart.swift` to handle `.stopping` case.
- Improved error messages with container ID for better debugging.
**Testing:**
- ✅ All tests pass (`make test`, `make integration`).
- ✅ Verified on macOS 26.
- ✅ Race condition test validates success and failure scenarios.
- ✅ Code formatted (`make fmt`).
Hopefully, this will pass the integration tests on GitHub.
Signed-off-by: ramsyana <47033578+ramsyana@users.noreply.github.com>
This PR resolves the problem of dropped progress updates and ensures the
accuracy of the information provided in the progress bar. Additionally,
it adds the displaying of the finished state to the progress bar.
Requires merging and tagging
https://github.com/apple/containerization/pull/91.
`BuildFSSync.walk` relied on an implementation detail to skip traversing
the path ".", relative to the build context dir.
Specifically, it assumed that:
- `URL.parentOf()` would return false when the parent argument was
relative.
- `URL.path(percentEncoded: false)` would preserve the relativity of an
input path.
These assumptions held on earlier macOS releases, so the context
directory silently remained untouched.
In some versions of macOS , `URL.path(percentEncoded: false)` always
returns an absolute path, regardless of how the URL was created. Because
of this change, `URL.parentOf()` now returns true for ".", and
BuildFSSync.walk begins descending into the context directory—something
it was never meant to do.
This solution:
- Remove the hidden dependency on `URL.parentOf()` for context‑directory
detection.
- Add an explicit check for "." inside BuildFSSync.walk and bail out
early.
Replace fragile calls to `URL.path(percentEncoded: false`) with the
stable, documented `URL.relativePath`, which preserves relativity when
the original path was relative.
Its a bit weird to have to pass `--http` when pulling / pushing images
if we are trying to do so from a local registry
This PR adds a `RequestScheme` enum type which tries to detect if the
connection to the registry should be over http or https. This auto
detection is the default behavior and can be overridden by passing the
`--scheme http/https` flag to the `run` ,`pull`, `push` `login` and
`registry default` command
The auto detection works by looking at the hostname / IP. HTTP is used
in the following cases
- If the hostname starts with `localhost` or is `127.x.x.x`
- if the host looks like an IP from the private address space
- If the host ends with the current default dns domain name
Also in this PR:
- Removing some used CLI flag groups and TODOs
- Better error messages when registry credentials are not found for a
host
Signed-off-by: Aditya Ramani <a_ramani@apple.com>
Sidhartha Mani