## Type of Change
- [ ] Bug fix
- [x] New feature
- [ ] Breaking change
- [ ] Documentation update
## Motivation and Context
Plugins technically exist, but to add shortcuts or to do existing things
with functions in `container` requires calling a compiled binary. This
pull request aims to remove that hurdle and instability by exposing
commands as a new `ContainerCommands ` target.
Simply import `ContainerCommands` and you can access almost
any command as if it were a native part of the binary. This makes
plugin development significantly easier.
Closes#609.
Common subcommands for all defaults.
- Closes#384.
- Replaces `registry default` and `system dns default` subcommands with
`system property`.
- Users can use `system property ls` to see details about each supported
default value.
- `system property set` implements reasonable validation for all
properties.
- NOTE: Probing of the registry for `registry default set` was removed,
which means users will find out about a botched setting when pulling or
pushing.
- Updates docs.
## Type of Change
- [ ] Bug fix
- [x] New feature
- [x] Breaking change
- [x] Documentation update
## Motivation and Context
See #384.
## Testing
- [x] Tested locally
- [x] Added/updated tests
- [x] Added/updated docs
## Type of Change
- [x] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update
## Motivation and Context
Fixes https://github.com/apple/container/issues/588. This PR changes the
archiver compression file enumeration to use the
[enumerator(atPath:)](https://developer.apple.com/documentation/foundation/filemanager/enumerator(atpath:))
version. This version returns relative paths instead of full file paths
from the filesystem. /tmp is symlinked to /private/tmp and some swift
packages will handle that path differently. While a call to Foundation's
`URL.resolvingSymlinksInPath()` will return "/tmp", a call to
`FileManager.enumerator(at:)` will return "/private/tmp". This
difference causes a container image build to fail when the user is using
a path under /tmp or other special case paths as the context directory.
## Testing
- [x] Tested locally
- [x] Added/updated tests
- [ ] Added/updated docs
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
- Closes#615.
Improves project organization. Separates service so it can be tested and
used separately from the executable target. No functional changes.
- Closes#557.
- Breaking change: removes `.upToNextOption` for labels on volumes as
this is not what is done for containers, and it forces the argument to
precede the options if a label is supplied, which is non-intuitive.
## Type of Change
- [ ] Bug fix
- [x] New feature
- [x] Breaking change
- [x] Documentation update
## Motivation and Context
Consistent features and UX across managed resources.
## Testing
- [x] Tested locally
- [x] Added/updated tests
- [x] Added/updated docs
## Type of Change
- [x] Dependency update
## Motivation and Context
A change was made in container-builder-shim to support BuildKit's
default global args
https://github.com/apple/container-builder-shim/pull/44. A new tag of
container-builder-shim was made with this change and this PR updates to
that new tag for container-builder-shim.
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
- Closes#547.
- Reduce DNS test count, make tests more readable.
## Type of Change
- [x] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update
## Motivation and Context
Painful to have to unset the default domain on a dev system to pass
local integration tests.
## Testing
- [x] Tested locally
- [x] Added/updated tests
- [ ] Added/updated docs
- Closes#568.
## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [x] Documentation update
## Motivation and Context
Uninstall script will fail with an informative message if the users
doesn't run `container system stop`, but including this step in the
upgrade process reinforces the need to do this. Upgrading without
restarting the service can lead to unexpected failures due to API or
persistent data incompatibility.
## Testing
- [ ] Tested locally
- [ ] Added/updated tests
- [x] Added/updated docs
Users frequently saw “failed to find plugin …” when the system services
weren’t running; the message didn’t explain the root cause or where
plugins are looked up. No change to plugin execution flow; only error
messaging and path discovery hints are improved for a better UX.
## Type of Change
- [x] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update
## Description
Correct signal semantics for plugins: Container binary currently execs
into plugin binaries. If the parent CLI keeps SIGINT/SIGTERM handlers
installed, it can intercept/alter signal behavior intended for the
plugin (e.g., preventing graceful shutdown in foreground workflows).
## Motivation and Context
During the development of a plugin (docker compose compatibility
plugin), I encountered a major issues where CTRL-C (SIGTERM) was not
being sent to my plugin. CLI plugins, especially those that have long
running tasks need a way to handle signals from the OS. Current, we exec
into plugin binaries. If the parent CLI keeps SIGINT/SIGTERM handlers
installed, it can intercept/alter signal behavior intended for the
plugin (e.g., preventing graceful shutdown in foreground workflows).
### What we changed:
- Signals handed back to plugins:
- DefaultCommand resets SIGINT/SIGTERM to defaults immediately before
exec’ing the plugin.
- Rationale: since exec replaces the process image, signals should be
delivered to (and handled by) the plugin without parent interference.
- Non‑plugin commands remain unaffected by this change.
- Compatibility: No change to plugin ABI or exec flow.
### Alternatives considered:
- Supervising child instead of exec: central forwarding of signals from
parent to plugin. Rejected for now to avoid changing process tree/stdio
semantics; resetting to defaults before exec preserves current model
while fixing signal interference.
## Testing
- [X] Tested locally
- [ ] Added/updated tests
- [ ] Added/updated docs
## Type of Change
- [x] Process update
## Description
Remove description field in PR template
## Motivation and Context
I think having separate `Description` and `Motivation and Context`
sections have been redundant in recent usage of the PR template. This PR
removes the `Description` section. Ideally the PR title should cover the
same content previously in the `Description` section.
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
## Type of Change
- [x] Bug fix
## Description
Allow kernel set with tar to use relative paths to tar file. Fixes
https://github.com/apple/container/issues/573.
## Motivation and Context
`absoluteString` will prefix a scheme to the file path that looks like
"file://". This will cause file manager to fail to find the file at the
file path even if it exists. Change to instead just get the `path` of
the file, which does not add a scheme prefix.
## Testing
- [x] Tested locally
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
## Type of Change
- [x] New feature
## Description
Add option to force kernel setting and tests for CLI `kernel set`.
Related to https://github.com/apple/container/pull/575.
## Motivation and Context
This PR adds additional tests to ensure that we can set kernels from
local files, remote tar files, and local tar files. A new option `force`
is added to the `kernel set` subcommand which will overwrite an existing
kernel with the same name if one exists to make testing easier. The
tests ensure that a container can be started with the newly set kernel
and resets to the default recommended kernel when complete.
## Testing
- [x] Tested locally
- [x] Added/updated tests
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
## Type of Change
- [x] Bug fix
## Description
This PR checks if the found entry in the archive for the requested
kernel path is a symlink, and if so, follows the symlink. I've opened a
separate issue to track creating tests for kernel downloading here
https://github.com/apple/container/issues/574 and will create a
follow-up PR for those.
## Motivation and Context
This PR fixes an issue reported in
https://github.com/apple/container/issues/475 where installing a kernel
from a tar archive does not follow symlinks in the archive.
## Testing
- [x] Tested locally
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
## Type of Change
- [x] Bug fix
## Description
Resolves#565. Relative paths in type=bind mounts now resolve to
absolute paths instead of being validated as volume names. Added some
tests generated using gen AI for this scenario.
This PR improves the user experience when using the uninstall script to
include usage output when an incorrect number of options are provided to
the script.
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
- Disabled tests that failed with release config.
- Changed so merge builds build with release config so this doesn't burn
us next release.
- Added `swift --version` to Makefile so we can see what we're running
up in CI.
- Fixes#231.
- Extends #313 (@dcantah) so that all of `container create`, `container
run`, `container build`, `container image pull`, and `container image
save` accept the three options.
- `container build` now processes comma-separated lists for
`--platform`, `--arch`, and `--os`. It first checks `--platform`,
assembling the union of all platform values. If that set is non-empty,
the builder builds the values in the set. Otherwise, the set consists of
all combinations of the specified architecture and os values, finally
defaulting to `linux` and the host architecture if no options are
provided.
- All other commands work accept a single platform, preferring the
`--platform` option over `--arch` and `--os` when both are specified.
`--os` defaults to `linux`, and `--arch` defaults to the host
architecture.
- Clarify help messages and present the args in consistent order, with
platform first since it takes precedence if present.
- Deduplicate redundant platform options for `container build`.
This reverts commit 41add29673.
We've discovered a quite fun issue with some of our rpcs (stop+delete)
in sequence when done fast enough. It needs a bit of reworking to get
into shape. While the work here is very useful, we can add this back
after the rpc ordering is solved.
I'm not sure why we had these going to OSLog, but I'd wager they're a
bit more useful being displayed directly to the user during the command
they're running.
Today force deleting (if a container is running then stop()'ing first)
is handled entirely in the cli, which is brittle. The CLI doesn't know
if the container was started with --rm so it would have to do a weird
timeout + list dance to check if the containers gone after stopping.
This change remedies this by just having the daemon take in a `force`
boolean to the delete rpc. If this is provided and the container is
running then we'll stop first, and then cleanup. We can additionally not
cleanup if --rm was provided as the daemon has the data to determine if
a container asked for autoRemove.
If any of the container run tests fail on the basic setup phases (e.g.
actually starting the container) we should log the bootlog to see if we
can glean any info off of this.
- This helps with brew cask packaging, can postflight link
libexec/container/plugins to the appropriate cask location, and the
plugin discovery will traverse the link.
This PR fixes SSH forwarding for exec processes.
Currently, only init processes received the `SSH_AUTH_SOCK` environment
variable when using `--ssh` flag. Exec processes didn't have access to
the SSH agent socket, even though the socket was mounted.
Now we set environment variable for exec processes to match init process
behavior, ensuring SSH forwarding works consistently across processes,
and refactoring SSH forwarding condition into `hostSocketUrl()` helper
function.
Add `--ssh` flag to forward the host's SSH agent socket into the
container, so we can use SSH authentication for things like cloning
private repos, and also updates the socket path every time the container
starts to handle socket path changes like reboot/re-login.
Closes#498
- Closes#150, #394.
- Introduces `AttachmentConfiguration` type so that we can add key-value
options to `--network` in the future.
- Eliminates redundant `ContainersService.Item` type.
- Since we now ensure at ContainersService that hostnames will not
conflict, the network helper IP allocator now simply provides the
existing IP if for an allocation on an existing hostname, which should
handle (in an eventually consistent way) the case where a container
fails to deallocate an IP on shutdown.