Constraints

Boundary Conditions

BC1: Single deployment architecture (amd64)

The Unraid production server is x86-64 (amd64). Docker images built for arm64 will either fail to start (wrong ELF format) or run with performance overhead under QEMU emulation. All production builds MUST produce amd64 images. Any runner or workflow configuration that could produce arm64 artifacts without explicit multi-arch intent is a bug.

BC2: Internal DNS required for Gitea access

The Gitea server at git.wylab.me is only resolvable via Technitium DNS (192.168.1.50). Public DNS (1.1.1.1, 8.8.8.8) cannot resolve this hostname. Runner job containers must have access to an internal DNS resolver — either via host networking, Docker bridge gateway (172.17.0.1), or direct Technitium IP — to perform git operations against git.wylab.me. Builds that run without DNS fix will fail at the checkout step.

BC3: OOM limit at concurrent jobs ≥ 3 on OrbStack

The macOS ARM64 runner using OrbStack crashes under concurrent dotnet builds when capacity exceeds 2. This constraint is empirically derived from session logs (6 → 4 → 3 → 2). OrbStack's no-swap behavior amplifies OOM risk. This constraint does not apply to Linux runners with swap enabled.

BC4: Zombie containers without shutdown_timeout

Without shutdown_timeout: 30m in runner config.yml, containers from cancelled or timed-out jobs accumulate on the host. These zombie containers consume disk space, network namespaces, and potentially Docker resources. This constraint applies to all runner hosts.

BC5: Third-party actions require Docker pull access

Actions using Docker images (e.g., yaml-schema-validator) require the runner job container to have Docker registry access. In environments where the registry is unreachable (firewall, no internet, auth failure), these actions fail with "pull access denied." The yaml-schema- validator action failure is a documented instance.

BC6: act-cache-server port 39913 must be reachable from job containers

Native Gitea cache (act-cache-server) requires TCP connectivity from job containers to the runner host on port 39913. In bridge network mode, this is the Docker bridge gateway IP (typically 172.17.0.1). Firewall rules or network configuration that block this port cause all cache steps to time out (ETIMEDOUT), making every build a full cold build.

Assumptions

The Unraid host remains operational and connected to the LAN for all builds.
git.wylab.me TLS certificate is valid; Traefik handles renewal.
The wylab-station-14 repository is a standard C# .NET project buildable with dotnet build.
The target Docker image for the SS14 server is self-contained (all dependencies bundled in the image).
No GPU or special hardware is required for the build process (only for the game server at runtime).

Known Limitations

No deployment automation: The pipeline builds and pushes the Docker image but does not automatically restart the Unraid SS14 container. Deployment is manual (Unraid Docker UI or shell).
No test step documented: Source logs do not document a unit test step in the workflow. SS14 may have tests but they are not part of the captured pipeline configuration.
Single point of failure: If the Unraid runner is the only registered runner (after abandoning external VPS and Mac runner), any Unraid maintenance window blocks all builds.
No artifact versioning strategy: The exact tagging scheme for Docker images (e.g., :latest vs. :commit-sha vs. :semver) is not specified in source logs.
Runner registration tokens expire: Gitea runner tokens are single-use; re-registering a runner requires a new token from the Gitea admin UI.

3.6 KiB Raw Blame History