Files
Netcatty/resources/et
lateautumn233 a4bf2234cd Add build-et-binaries workflow to compile the et client
Build the EternalTerminal `et` client in CI the way mosh-client is:

- build-et-binaries.yml builds et for linux x64/arm64, macOS universal
  and windows x64, uploads artifacts, and optionally publishes them to a
  dedicated binary repository on manual workflow_dispatch.
- scripts/build-et/{linux,macos,windows} compile et from upstream.
- .gitignore excludes the fetched binaries; resources/et/README.md
  documents source provenance.
2026-06-02 20:35:07 +08:00
..

Bundled EternalTerminal et client

This directory holds the EternalTerminal client binary (et) bundled with the Netcatty installer. Netcatty launches this bundled et directly (see electron/bridges/terminalBridge/etSession.cjs); et performs its own SSH bootstrap and EternalTerminal protocol handshake against the remote etserver / etterminal.

Unlike mosh-client, et is a pure network-transport client and does not render a terminal locally, so there is no terminfo bundle here — only the single et (et.exe on Windows) binary.

How binaries land here

  1. .github/workflows/build-et-binaries.yml builds et on relevant pushes/PRs, or on a manual workflow_dispatch. It uses scripts/build-et/build-linux.sh and scripts/build-et/build-macos.sh for Linux/macOS, and scripts/build-et/build-windows.ps1 for Windows:

    target provenance
    linux-x64 upstream source, manylinux2014, vcpkg static deps + glibc
    linux-arm64 upstream source, manylinux2014, vcpkg static deps + glibc
    darwin-universal upstream source, lipo arm64 + x86_64, macOS system dylibs only
    win32-x64 upstream source, MSVC + vcpkg x64-windows-static (no DLLs)
    win32-arm64 (not built — add after a tested arm64 client is available)

    ET builds with CMake + Ninja + vcpkg (cmake -DDISABLE_TELEMETRY=ON -GNinja -DCMAKE_BUILD_TYPE=RelWithDebInfo).

  2. When manually dispatched with release_tag, that workflow publishes the binaries to the dedicated binaricat/Netcatty-et-bin repository. The release gets a tag like et-bin-6.2.10-1, with SHA256SUMS attached.

  3. Release packaging runs scripts/resolve-et-bin-release.cjs before npm run fetch:et. It uses an explicit workflow input first, then the ET_BIN_RELEASE repository variable, then the latest non-draft et-bin-* GitHub Release from the dedicated binary repository. The fetch step pulls the binaries into resources/et/<platform-arch>/. For local packaging, set ET_BIN_RELEASE yourself before running the same fetch command. Override ET_BIN_OWNER / ET_BIN_REPO only when testing a different binary repository. electron-builder.config.cjs then copies the matching binary into Resources/et/et[.exe].

    Local dev uses the same binary path: npm run dev runs npm run fetch:et:dev first, which downloads the host platform's bundled et into this gitignored directory. Netcatty does not fall back to a system-installed et; if the bundled binary is missing, ET startup fails loudly instead of using whatever happens to be installed on the developer machine.

The directory is otherwise empty (binaries are gitignored).

Licenses

  • EternalTerminal is licensed under Apache-2.0 (https://github.com/MisterTea/EternalTerminal).
  • Netcatty is GPL-3.0; Apache-2.0 is one-way compatible with GPL-3.0, so redistribution as part of the installer is permitted.
  • vcpkg-managed deps (boost Boost-License, libsodium ISC, protobuf BSD-3-Clause, gflags BSD-3-Clause) are compatible with GPL-3.0.

Reproducible build

To reproduce the Linux binary locally:

docker run --rm -v $PWD:/workspace -w /workspace \
  -e ET_REF=et-v6.2.10 -e ARCH=x64 -e OUT_DIR=/workspace/out \
  quay.io/pypa/manylinux2014_x86_64 \
  bash scripts/build-et/build-linux.sh

For macOS the build needs an Xcode toolchain; see scripts/build-et/build-macos.sh. For Windows see scripts/build-et/build-windows.ps1.

Roadmap

  • Add Windows arm64 only after a tested standalone arm64 client is available.
  • Make ET_REF track upstream release tags automatically.