A ContainerManager is a type that handles more of the required resource
needed to create and run a container.
---------
Signed-off-by: crosbymichael <michael_crosby@apple.com>
This is a fairly large reworking, but it gets rid of something that has
plagued this since release which is the properties needing to be locked
to be Sendable compliant. This was somewhat of a copout because we
mostly know there's not a great deal of ways to have misused the setup
today, but alas we'd need to either mark the type as `@unchecked` or
just find a different route for setting the configuration. This change:
Exposes the underlying Configuration type that today only housed things
that aren't on the OCI spec. I'd love to just expose the OCI spec, but
we don't (and possibly never will) support everything on the spec, so
exposing it to be freely modified would be a bit odd. Now everything
related to the container is configured on this type, and the same goes
for execs.
Closes#206
Much like we have support for supplying DNS configurations and writing
out /etc/resolv.conf, this adds a way to write out /etc/hosts for a
given container.
In general I believe it's clever to synthesize an index for
single-platform image manifest, but we still need a way to distinguish
it. Add a dedicated annotation is the slightest change I've come up
with, and it's also OCI compliant. With this change come in, we can work
around https://github.com/apple/container/issues/212 and imitate the
behavior of other runtime with `container`.
Note that since `cctl` is meant to be a dedicated tool for inspecting
the Containerization framework itself, I didn't apply the indirection
for it, and it will be as-is with the genuine storage.
- The `@SendableProperty` macro now checks for supported types to
prevent a misuse with unsupported types like structs, dictionaries, and
arrays
- The new `@SendablePropertyUnchecked` can be used with classes and
enums
This allows the user the ability to raise an EOF for the containers
stdin. Today there's no way to close stdin so something as simple as
"cat" and relying on EOF to move the process forward doesn't work
While this only supports AS, xcode's default will build all arches, so
this presents a bit nicer default for Archiving an xcode application
that utilizes containerization.
Fixes#179
Signed-off-by: crosbymichael <michael_crosby@apple.com>
I think the way these types were structured made reasoning about them a
bit difficult. I don't think this fully solves the problem, but this
change aims to make things a bit simpler by hoisting a lot of the logic
for the IO relays to a new IOPair type thats goal is to simply take in a
reader and writer and handle their resource cleanup after a relay
finishes. Bundled in with this is also the buffer we'll use to copy
between them.
This change:
- Alters ManagedProcess.IO `start` to take in the process to alter
instead of this just being a side effect of the constructors.
- Gets rid of `close()` in favor of `CloseStdin`. The IO will get closed
when the relays finish, which will naturally happen if the process exits
or just closes its side of the pipes/pty. This makes it so that the one
special case (a client wants to signal no more input is coming) is still
sane.
- Move all relay logic and resource cleanup to a new IOPair type that
takes in protocols that are easily conformable by all of our various io
types ( Socket, Terminal, FileHandle).
This PR introduces a pattern of grouping mutable properties within the
`Sendable` types, encapsulated within a `State` struct. This approach
enables simultaneous updates to multiple properties and serves as a tool
against reentrancy issues.
CI was failing since the test image we use had a tag re-pushed. Pinning
the test to reference the image version by its sha
---------
Signed-off-by: Aditya Ramani <a_ramani@apple.com>
We should namespace these a bit, and we need pidfd for some upcoming
terminal work. This also just gets rid of syscall2 and replaces with a
pivot_root wrapper.
Creates a new Unpacker protocol that defines a single method
```
func unpack(_ image: Image, for platform: Platform, at path: URL, progress: ProgressHandler?) async throws -> Mount
```
This change also removes the `unpack(...)` method from the Image type.
Before
```
let mount = try await image.unpack(for: platform, at: path)
```
After
```
let unpacker = EXT4Unpacker(blockSizeInBytes: 2.gib())
let mount = try await unpacker.unpack(image, for: platform, at: path)
```
---------
Signed-off-by: Aditya Ramani <a_ramani@apple.com>
Here we implement the mechanism for ensuring that `container` doesn't
set up two default routes on containers that connect to multiple
networks. We'll implement the policy in apple/container#243.
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.
Related to https://github.com/apple/container/pull/262
Signed-off-by: Kathryn Baldauf <k_baldauf@apple.com>
Reverts f9198d6ff7
We can explore better approaches to some of the targets, but for now
lets revert as it interferes with being able to build even if we have
local changes.
Until 6.2 officially releases lets pin to a static version of the 6.2
snapshots. The Linux SDK and swift version must be aligned so this
should be less fickle than using `6.2-snapshot` as this is a friendly
identifier to choose the latest uploaded snapshot.
fixes#165
`init` depends on `vminitd/bin/vminitd`, `vminitd/bin/vmexec`, and
`bin/cctl`
`integration` depends on `bin/containerization-integration`
`bin/*` get generated via `make containerization`
Because we were installing rosetta directly in the constructor for
VZVirtualMachineInstance, and we'd prefer to not have the constructor
async as it pollutes so much more, we had devised this gnarly callback
approach for the install that is a bit of an eyesore. This changes focus
is on moving the install flow to a method that is already async so we
can piggyback off of it, and removing the install logic from the config
-> VZConfig conversion. Now the install will occur during start() if
rosetta is not installed.
This gets rid of some design decisions that I was not fond of. This
changes the process start for both execs and the init process to happen
internally in the object, as well as makes it so that all exec
functionalities can happen on the container object itself. This allows
us to get rid of the `if request.id == containerID` branches in the
rpcs, and handle this entirely in the object itself using its internal
state.
The existing integration tests should stress this just fine I believe.
This PR fixes compilation warnings observed in:
```
swift -v --version
Apple Swift version 6.2-dev (LLVM 5fbc818cf26c90b, Swift 2e1897356956e43)
Target: arm64-apple-macosx26.0
/Users/Dmitry/Library/Developer/Toolchains/swift-6.2-DEVELOPMENT-SNAPSHOT-2025-06-17-a.xctoolchain/usr/bin/swift-frontend --version
Apple Swift version 6.2-dev (LLVM 5fbc818cf26c90b, Swift 2e1897356956e43)
Target: arm64-apple-macosx26.0
Build config: +assertions
```
Currently, when a user runs `make cross-prep`, we install the latest
version of Swift. This requires installing the latest version of Static
Linux SDK, which we should update as a new version is released.
# Refactor GitHub Actions Workflow: Containerization Build
## 🛠 Summary
This PR introduces several important improvements and cleanups to the
build-containerization-template GitHub Actions workflow for better
maintainability, correctness, and readability.
### 🔧 Changes Made
#### 1. ✅ Fix invalid conditional syntax
- **!= is not supported in expressions** with **if**: in GitHub Actions.
- Only logical operators like !, &&, || are valid.
#### 2. ✅ Globalized environment variables
- Moved CURRENT_SDK and DEVELOPER_DIR to the job-level env: block to:
- Avoid redundancy across steps
- Make the workflow more maintainable
### 3. ✅ Replaced `secrets.GITHUB_TOKEN` with `github.token`
- Prefer github.token for GitHub-provided auth token to improve clarity
and scoping.
@katiewasnothere
This PR resolves the following error for new users:
```
% make cross-prep
Installing Swiftly...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 8549k 100 8549k 0 0 14.7M 0 --:--:-- --:--:-- --:--:-- 14.8M
installer: Package name is
installer: Installing at base path /Users/Dmitry
installer: The install was successful.
Welcome to swiftly, the Swift toolchain manager for Linux and macOS!
Please read the following information carefully before proceeding with the installation. If you
wish to customize the steps performed during the installation process, refer to 'swiftly init -h'
for configuration options.
Swiftly installs files into the following locations:
/Users/Dmitry/.swiftly - Directory for configuration files
/Users/Dmitry/.swiftly/bin - Links to the binaries of the active toolchain
/Users/Dmitry/Library/Developer/Toolchains - Directory hosting installed toolchains
These locations can be changed by setting the environment variables
SWIFTLY_HOME_DIR, SWIFTLY_BIN_DIR, and SWIFTLY_TOOLCHAINS_DIR before running 'swiftly init' again.
For your convenience, swiftly will also attempt to modify your shell's profile file to make
installed items available in your environment upon login. This can be suppressed with the
'--no-modify-profile' option.
Proceed? (Y/n):
Installing swiftly in /Users/Dmitry/.swiftly/bin/swiftly...
Error: The file “swiftly” couldn’t be opened because there is no such file.
make[1]: *** [swiftly] Error 1
make: *** [cross-prep] Error 2
```
There was a bug where the `www-authenticate` header in the HTTP response
from a registry would not be parsed accurately.
Specifically, if the header value had more than one `<space>` character,
the entire header would be ignored. This PR fixes this bug and adds unit
test to detect this in the future.
Fixes https://github.com/apple/container/issues/240
And most likely fixes https://github.com/apple/container/issues/237
Signed-off-by: Aditya Ramani <a_ramani@apple.com>
Make sure we always set TERM for containers that ask for a tty. Right
now this handling was spread around in a bunch of spots, but I'd wager
setting it for the client on the host via LinuxContainer/Process is more
sane and already what we do for a lot of the other fields.
Danny Canter