mirror of
https://github.com/nestriness/nestri.git
synced 2026-09-19 17:25:19 +03:00
8246aa5538
Get this thing going..
<!-- greptile_comment -->
<!-- greptile_summary -->
<h2><a
href="https://app.greptile.com/api/retrigger?id=63134761"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://greptile-static-assets.s3.amazonaws.com/badges/RetriggerDark.svg?v=1"><source
media="(prefers-color-scheme: light)"
srcset="https://greptile-static-assets.s3.amazonaws.com/badges/Retrigger.svg?v=1"><img
alt="Retrigger"
src="https://greptile-static-assets.s3.amazonaws.com/badges/Retrigger.svg?v=1"
align="right"></picture></a>Confidence Score: 5/5</h2>
The PR appears safe to merge; all previous findings are resolved and the
latest readiness change introduces no established actionable regression.
<h3>Summary</h3>
- Establishes required guest filesystems, runtime directories, device
permissions, and service processes.
- Reports initialization and service deaths over the lifecycle channel.
- Supports launch, restart, and shutdown commands for a resident guest.
- Separates service and workload identities and configures per-launch
runtime environments.
- Removes the currently inactive nescope screenshot option and makes
capture-chain verification fail explicitly when compositor readback is
unavailable.
- Reworks the guest image around `nesinit` as PID 1 without a
distribution service manager.
<h3>Diagram</h3>
```mermaid
sequenceDiagram
participant Host
participant Init as nesinit
participant FS as Guest filesystems
participant Services as Service stack
participant Workload
Init->>Host: Ready(protocol version)
Host->>Init: Boot(mount descriptors)
Init->>FS: Establish and mount shares
Init->>Services: Spawn services in order
Services-->>Init: Required sockets ready
Init->>Host: Initialized(service names)
Host->>Init: Launch(id, exec, on_exit)
Init->>Workload: Spawn with isolated UID/runtime
Init->>Host: Started(id)
Workload-->>Init: Exit status
Init->>Host: WorkloadExited(id, status)
Host->>Init: Launch / Restart / Shutdown
```
<sub>Reviews (4) · Last reviewed commit: ["fix(nesinit): readiness is a
socket
that..."](731d34df9d)</sub>
<!-- /greptile_comment -->
---------
Co-authored-by: DatCaptainHorse <DatCaptainHorse@users.noreply.github.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
41 lines
1.3 KiB
Docker
41 lines
1.3 KiB
Docker
# The guest rootfs build's context.
|
|
#
|
|
# The name is load-bearing and it is not `.containerignore`. Podman looks for
|
|
# an ignore file *adjacent to the Containerfile and named after it* — here,
|
|
# `Containerfile.containerignore` — before falling back to one at the root of
|
|
# the build context. The context is the repository root, so a bare
|
|
# `build/.containerignore` sits in neither place and is silently read by
|
|
# nothing: the build still works, it just sends the whole tree.
|
|
#
|
|
# Docker looks for the `.dockerignore` suffix only, so a docker build reads the
|
|
# repository-root file instead of this one and sends more than it needs. That
|
|
# is the cost of the container-agnostic name and it is only a cost in bytes.
|
|
#
|
|
# This file *replaces* the repository-wide ignore file rather than adding to
|
|
# it, so the first block below is that file repeated. The second is what only
|
|
# this build excludes.
|
|
#
|
|
# This build's context is the repository root (see `Makefile`), and it COPYs
|
|
# the workspace manifests plus the Rust members and nothing else. The
|
|
# TypeScript half is therefore dead weight in the context — a few megabytes
|
|
# sent to the daemon versus the whole tree.
|
|
.git
|
|
node_modules
|
|
target
|
|
build/output
|
|
.env
|
|
.env.*
|
|
.wrangler
|
|
dist
|
|
.output
|
|
|
|
docs
|
|
apps/api
|
|
apps/auth
|
|
packages
|
|
*.md
|
|
deno.lock
|
|
bun.lock
|
|
.zed
|
|
.github
|