opencode 的 CI 加速容器packages/containers 预构建镜像的设计与构建全流程【免费下载链接】opencodeThe open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/openc/opencode本篇基于 packages/containers/README.md 展开系统讲解 opencode 仓库如何通过一组预构建的 Docker 镜像base、bun-node、rust、tauri-linux、publish来加速 GitHub Actions 中的 Linux 作业涵盖每个镜像的工具链构成与继承关系、构建脚本 的环境变量约定与多架构发布机制、CI 发布工作流 的完整配置以及如何在job.container中正确引用这些镜像。读完后你可以复现整套镜像的本地构建与推送流程并理解多架构amd64 arm64构建、Buildx 依赖等关键细节。一、设计目标用预构建镜像消除 CI 的重复安装成本opencode 的 CI 需要安装大量又大又慢的依赖——Bun、Node.js、Rust 工具链、Tauri 的 WebKit 开发库、Docker CLI 与 AUR 工具等。每次 GitHub Actions 作业从零安装这些依赖会显著拉长构建时间。packages/containers目录的方案是把它们烘焙进一组预构建的 Linux 镜像供工作流通过job.container直接运行Prebuilt images intended to speed up GitHub Actions jobs by baking in large, slow-to-install dependencies. These are designed for Linux jobs that can usejob.containerin workflows. —— packages/containers/README.md使用这些镜像有两个明确的适用边界原文 Notes 部分仅对 Linux 作业有效。macOS 和 Windows 作业无法运行在 Linux 容器内这两类 runner 仍需常规安装步骤如果作业本身使用 Docker Buildx容器必须能访问宿主 Docker daemon或以 privileged 模式运行docker-in-docker否则构建无法进行。二、镜像家族五个 Dockerfile 的继承关系与各层构成packages/containers下共有 5 个镜像每个镜像对应一个子目录中的 Dockerfile。它们的继承关系为base→bun-node→rust→tauri-linux另有一条bun-node→publish的旁支。镜像基于新增内容baseubuntu:24.04常用构建工具与通用工具bun-nodebaseBun 1.3.14 Node.js 24源码中标注 24.4.0rustbun-nodeRust stableminimal profiletauri-linuxrustTauri Linux 构建依赖publishbun-nodeDocker CLI 与 AUR 工具baseUbuntu 24.04 基础工具层base/Dockerfile 是整条继承链的根安装内容全部走apt-get --no-install-recommends并设置DEBIAN_FRONTENDnoninteractive以避免交互提示FROM ubuntu:24.04 ARG DEBIAN_FRONTENDnoninteractive RUN apt-get update \ apt-get install -y --no-install-recommends \ build-essential \ ca-certificates \ curl \ git \ jq \ openssh-client \ pkg-config \ python3 \ unzip \ xz-utils \ zip \ rm -rf /var/lib/apt/lists/*这一层覆盖了绝大多数 JS/Rust 项目 CI 的共性需求编译链build-essentialpkg-config、下载与文本处理curl、jq、unzip、xz-utils、版本管理git与 SSH 客户端最后清理 apt 缓存以压缩镜像体积。bun-nodeBun Node.js 双运行时层bun-node/Dockerfile 通过ARG REGISTRYghcr.io/anomalyco参数化基础镜像来源默认拉取${REGISTRY}/build/base:24.04这样整套镜像可以在不改动 Dockerfile 的情况下指向私有或镜像源仓库ARG REGISTRYghcr.io/anomalyco FROM ${REGISTRY}/build/base:24.04 SHELL [/bin/bash, -lc] ARG NODE_VERSION24.4.0 ARG BUN_VERSION1.3.14 ENV BUN_INSTALL/opt/bun ENV PATH/opt/bun/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin源码中还值得注意两个实现细节Node.js 安装做了架构自适应脚本内先uname -m判断当前架构aarch64映射为arm64其余按x64处理再从nodejs.org下载对应 tarball 解压到/usr/local并执行corepack enable。这是该镜像能作为多架构镜像发布的前提之一SHELL [/bin/bash, -lc]使后续 RUN 指令以登录 shell 执行保证从/etc/profile等路径加载环境变量与 bun 安装脚本的路径设置兼容。Bun 通过官方安装脚本固定版本安装到/opt/bunBUN_VERSION默认为1.3.14与仓库根 package.json 的packageManager: bun1.3.14保持一致安装后依次断言bun --version、node --version、npm --version任何一个失败都会让构建中断。rust 与 tauri-linuxRust 与桌面端构建层rust/Dockerfile 在bun-node之上安装 Rust刻意保持轻量ARG RUST_TOOLCHAINstable ENV CARGO_HOME/opt/cargo ENV RUSTUP_HOME/opt/rustup ENV PATH/opt/cargo/bin:/opt/bun/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin RUN set -euo pipefail; \ curl -fsSL https://sh.rustup.rs | sh -s -- -y --profile minimal --default-toolchain ${RUST_TOOLCHAIN}; \ rustc --version; \ cargo --version工具链使用 rustup 的minimalprofile对应 README 中 Rust (stable, minimal profile)CARGO_HOME/RUSTUP_HOME放在/opt下以便缓存或复用。tauri-linux/Dockerfile 则是面向 Tauri 桌面端 Linux 打包的依赖层补齐 WebKit 与系统库FROM ${REGISTRY}/build/rust:24.04 RUN apt-get update \ apt-get install -y --no-install-recommends \ libappindicator3-dev \ libwebkit2gtk-4.1-dev \ librsvg2-dev \ patchelf \ rm -rf /var/lib/apt/lists/*其中libwebkit2gtk-4.1-dev是 Tauri 2 系列在 Linux 上编译的硬依赖patchelf常用于打包时修正二进制的 rpath。publish发布专用层publish/Dockerfile 基于bun-node安装docker.ioDocker CLI 客户端与pacman-package-managerAUR 工具链用于发布流水线中在容器内直接调用 Docker 和构建 AUR 包。三、构建脚本 script/build.ts环境变量约定与多架构发布整套镜像由 packages/containers/script/build.ts 统一构建README 给出的两个入口命令是# 仅本地构建 REGISTRYghcr.io/anomalyco TAG24.04 bun ./packages/containers/script/build.ts # 构建并推送到 registry REGISTRYghcr.io/anomalyco TAG24.04 bun ./packages/containers/script/build.ts --push参数解析逻辑脚本对参数的处理比 README 的两行命令更细可以结合源码确认以下行为REGISTRY默认ghcr.io/anomalyco镜像完整名拼接为${REGISTRY}/build/name:${TAG}TAG默认24.04与 Ubuntu 基础版本对应的仓库标识推送开关命令行--push或环境变量PUSH1任一生效Bun 版本自动派生脚本读取仓库根 package.json 的packageManager字段要求必须形如bunversion当前为bun1.3.14否则直接抛错退出。该版本随后作为BUN_VERSIONbuild-arg 传给bun-node镜像——这意味着升级仓库的 Bun 版本后重新构建镜像即可让 CI 环境同步升级无需改动 Dockerfile构建顺序固定const images [base, bun-node, rust, tauri-linux, publish]保证每一层所需的父镜像先于子镜像存在。Buildx 实例与双平台构建--push模式下脚本会检查docker buildx ls中是否已有名为opencode的 Buildx 实例没有则执行docker buildx create --name opencode --use随后所有镜像统一按--platform linux/amd64,linux/arm64构建并推送对应 README Notes 中的 multi-arch (amd64 arm64)。各镜像的构建参数差异如下源码逐镜像分支生成镜像本地构建推送构建basedocker build -f .../base/Dockerfile -t ... .docker buildx build --platform linux/amd64,linux/arm64 ... --push .不传 build-argbun-node同上 --build-arg REGISTRY$REGISTRY --build-arg BUN_VERSION$BUNbuildx 同样两个 build-arg --pushrust/tauri-linux/publish同上 --build-arg REGISTRY$REGISTRYbuildx --build-arg REGISTRY$REGISTRY--push另外值得注意脚本执行前会把工作目录切换到仓库根process.chdir(rootDir)且所有构建命令的上下文均为仓库根目录docker build ... .而非 Dockerfile 所在目录因此 Dockerfile 内引用的都是根相对路径语义复现构建时不要在子目录中执行。四、CI 发布流水线containers.yml 工作流镜像的自动发布由 .github/workflows/containers.yml 驱动关键配置可以逐项确认on: push: branches: [dev] paths: - packages/containers/** - .github/workflows/containers.yml - package.json workflow_dispatch: permissions: contents: read packages: write jobs: build: runs-on: blacksmith-4vcpu-ubuntu-2404 env: REGISTRY: ghcr.io/${{ github.repository_owner }} TAG: 24.04几个值得关注的点触发路径设计仅在dev分支上、且改动涉及packages/containers/**、工作流自身或package.json时触发。把package.json纳入触发路径正是为了配合 build.ts 的BUN_VERSION派生逻辑——Bun 版本一升级镜像就自动重建Registry 跟随仓库所有者REGISTRY写为ghcr.io/${{ github.repository_owner }}而非硬编码仓库改名或迁移后无需改动工作流多架构构建的完整前置作业依次使用 QEMUdocker/setup-qemu-action为 arm64 交叉模拟提供支持、Docker Buildxdocker/setup-buildx-action提供构建器并以GITHUB_TOKEN登录 GHCR依赖上面的packages: write权限最终执行bun ./packages/containers/script/build.ts --push与 README 的推送命令一致。五、在 Workflow 中使用这些镜像README 给出的job.container用法示例如下任何 Linux 作业都可以这样引用jobs: build-cli: runs-on: ubuntu-latest container: image: ghcr.io/anomalyco/build/bun-node:24.04使用时的注意事项继承自原文档 Notes容器内的作业运行环境就是对应镜像本身因此bun、node、cargo等命令开箱即用无需再走 setup 步骤选择镜像按最小依赖原则纯 JS 任务用bun-nodeRust 任务用rustTauri 桌面端构建用tauri-linux发布流水线用publish避免不必要的层若作业需要 Buildx需为容器配置对宿主 Docker daemon 的挂载或改用 privileged 的docker-in-docker方案macOS/Windows 作业无法使用本套镜像保持原有安装流程即可。六、小结可验证的目录索引整套方案的信息在仓库中的落点非常集中便于按图索骥内容路径镜像说明与使用方式packages/containers/README.md构建/推送脚本packages/containers/script/build.ts基础工具层packages/containers/base/DockerfileBun Node 层packages/containers/bun-node/DockerfileRust 层packages/containers/rust/DockerfileTauri Linux 依赖层packages/containers/tauri-linux/Dockerfile发布工具层packages/containers/publish/Dockerfile自动发布工作流.github/workflows/containers.yml这套设计的关键经验可以概括为三点以继承链复用基础层控制镜像数量与构建时间把版本号Bun、Node、TAG参数化并绑定到仓库根package.json使升级运行时与重建镜像自动化衔接用REGISTRYbuild-arg 隔离镜像源保证同一套 Dockerfile 可服务公开与私有注册表。【免费下载链接】opencodeThe open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/openc/opencode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 opencode 的 CI 加速容器：packages/containers 预构建镜像的设计与构建全流程
opencode 的 CI 加速容器packages/containers 预构建镜像的设计与构建全流程【免费下载链接】opencodeThe open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/openc/opencode本篇基于 packages/containers/README.md 展开系统讲解 opencode 仓库如何通过一组预构建的 Docker 镜像base、bun-node、rust、tauri-linux、publish来加速 GitHub Actions 中的 Linux 作业涵盖每个镜像的工具链构成与继承关系、构建脚本 的环境变量约定与多架构发布机制、CI 发布工作流 的完整配置以及如何在job.container中正确引用这些镜像。读完后你可以复现整套镜像的本地构建与推送流程并理解多架构amd64 arm64构建、Buildx 依赖等关键细节。一、设计目标用预构建镜像消除 CI 的重复安装成本opencode 的 CI 需要安装大量又大又慢的依赖——Bun、Node.js、Rust 工具链、Tauri 的 WebKit 开发库、Docker CLI 与 AUR 工具等。每次 GitHub Actions 作业从零安装这些依赖会显著拉长构建时间。packages/containers目录的方案是把它们烘焙进一组预构建的 Linux 镜像供工作流通过job.container直接运行Prebuilt images intended to speed up GitHub Actions jobs by baking in large, slow-to-install dependencies. These are designed for Linux jobs that can usejob.containerin workflows. —— packages/containers/README.md使用这些镜像有两个明确的适用边界原文 Notes 部分仅对 Linux 作业有效。macOS 和 Windows 作业无法运行在 Linux 容器内这两类 runner 仍需常规安装步骤如果作业本身使用 Docker Buildx容器必须能访问宿主 Docker daemon或以 privileged 模式运行docker-in-docker否则构建无法进行。二、镜像家族五个 Dockerfile 的继承关系与各层构成packages/containers下共有 5 个镜像每个镜像对应一个子目录中的 Dockerfile。它们的继承关系为base→bun-node→rust→tauri-linux另有一条bun-node→publish的旁支。镜像基于新增内容baseubuntu:24.04常用构建工具与通用工具bun-nodebaseBun 1.3.14 Node.js 24源码中标注 24.4.0rustbun-nodeRust stableminimal profiletauri-linuxrustTauri Linux 构建依赖publishbun-nodeDocker CLI 与 AUR 工具baseUbuntu 24.04 基础工具层base/Dockerfile 是整条继承链的根安装内容全部走apt-get --no-install-recommends并设置DEBIAN_FRONTENDnoninteractive以避免交互提示FROM ubuntu:24.04 ARG DEBIAN_FRONTENDnoninteractive RUN apt-get update \ apt-get install -y --no-install-recommends \ build-essential \ ca-certificates \ curl \ git \ jq \ openssh-client \ pkg-config \ python3 \ unzip \ xz-utils \ zip \ rm -rf /var/lib/apt/lists/*这一层覆盖了绝大多数 JS/Rust 项目 CI 的共性需求编译链build-essentialpkg-config、下载与文本处理curl、jq、unzip、xz-utils、版本管理git与 SSH 客户端最后清理 apt 缓存以压缩镜像体积。bun-nodeBun Node.js 双运行时层bun-node/Dockerfile 通过ARG REGISTRYghcr.io/anomalyco参数化基础镜像来源默认拉取${REGISTRY}/build/base:24.04这样整套镜像可以在不改动 Dockerfile 的情况下指向私有或镜像源仓库ARG REGISTRYghcr.io/anomalyco FROM ${REGISTRY}/build/base:24.04 SHELL [/bin/bash, -lc] ARG NODE_VERSION24.4.0 ARG BUN_VERSION1.3.14 ENV BUN_INSTALL/opt/bun ENV PATH/opt/bun/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin源码中还值得注意两个实现细节Node.js 安装做了架构自适应脚本内先uname -m判断当前架构aarch64映射为arm64其余按x64处理再从nodejs.org下载对应 tarball 解压到/usr/local并执行corepack enable。这是该镜像能作为多架构镜像发布的前提之一SHELL [/bin/bash, -lc]使后续 RUN 指令以登录 shell 执行保证从/etc/profile等路径加载环境变量与 bun 安装脚本的路径设置兼容。Bun 通过官方安装脚本固定版本安装到/opt/bunBUN_VERSION默认为1.3.14与仓库根 package.json 的packageManager: bun1.3.14保持一致安装后依次断言bun --version、node --version、npm --version任何一个失败都会让构建中断。rust 与 tauri-linuxRust 与桌面端构建层rust/Dockerfile 在bun-node之上安装 Rust刻意保持轻量ARG RUST_TOOLCHAINstable ENV CARGO_HOME/opt/cargo ENV RUSTUP_HOME/opt/rustup ENV PATH/opt/cargo/bin:/opt/bun/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin RUN set -euo pipefail; \ curl -fsSL https://sh.rustup.rs | sh -s -- -y --profile minimal --default-toolchain ${RUST_TOOLCHAIN}; \ rustc --version; \ cargo --version工具链使用 rustup 的minimalprofile对应 README 中 Rust (stable, minimal profile)CARGO_HOME/RUSTUP_HOME放在/opt下以便缓存或复用。tauri-linux/Dockerfile 则是面向 Tauri 桌面端 Linux 打包的依赖层补齐 WebKit 与系统库FROM ${REGISTRY}/build/rust:24.04 RUN apt-get update \ apt-get install -y --no-install-recommends \ libappindicator3-dev \ libwebkit2gtk-4.1-dev \ librsvg2-dev \ patchelf \ rm -rf /var/lib/apt/lists/*其中libwebkit2gtk-4.1-dev是 Tauri 2 系列在 Linux 上编译的硬依赖patchelf常用于打包时修正二进制的 rpath。publish发布专用层publish/Dockerfile 基于bun-node安装docker.ioDocker CLI 客户端与pacman-package-managerAUR 工具链用于发布流水线中在容器内直接调用 Docker 和构建 AUR 包。三、构建脚本 script/build.ts环境变量约定与多架构发布整套镜像由 packages/containers/script/build.ts 统一构建README 给出的两个入口命令是# 仅本地构建 REGISTRYghcr.io/anomalyco TAG24.04 bun ./packages/containers/script/build.ts # 构建并推送到 registry REGISTRYghcr.io/anomalyco TAG24.04 bun ./packages/containers/script/build.ts --push参数解析逻辑脚本对参数的处理比 README 的两行命令更细可以结合源码确认以下行为REGISTRY默认ghcr.io/anomalyco镜像完整名拼接为${REGISTRY}/build/name:${TAG}TAG默认24.04与 Ubuntu 基础版本对应的仓库标识推送开关命令行--push或环境变量PUSH1任一生效Bun 版本自动派生脚本读取仓库根 package.json 的packageManager字段要求必须形如bunversion当前为bun1.3.14否则直接抛错退出。该版本随后作为BUN_VERSIONbuild-arg 传给bun-node镜像——这意味着升级仓库的 Bun 版本后重新构建镜像即可让 CI 环境同步升级无需改动 Dockerfile构建顺序固定const images [base, bun-node, rust, tauri-linux, publish]保证每一层所需的父镜像先于子镜像存在。Buildx 实例与双平台构建--push模式下脚本会检查docker buildx ls中是否已有名为opencode的 Buildx 实例没有则执行docker buildx create --name opencode --use随后所有镜像统一按--platform linux/amd64,linux/arm64构建并推送对应 README Notes 中的 multi-arch (amd64 arm64)。各镜像的构建参数差异如下源码逐镜像分支生成镜像本地构建推送构建basedocker build -f .../base/Dockerfile -t ... .docker buildx build --platform linux/amd64,linux/arm64 ... --push .不传 build-argbun-node同上 --build-arg REGISTRY$REGISTRY --build-arg BUN_VERSION$BUNbuildx 同样两个 build-arg --pushrust/tauri-linux/publish同上 --build-arg REGISTRY$REGISTRYbuildx --build-arg REGISTRY$REGISTRY--push另外值得注意脚本执行前会把工作目录切换到仓库根process.chdir(rootDir)且所有构建命令的上下文均为仓库根目录docker build ... .而非 Dockerfile 所在目录因此 Dockerfile 内引用的都是根相对路径语义复现构建时不要在子目录中执行。四、CI 发布流水线containers.yml 工作流镜像的自动发布由 .github/workflows/containers.yml 驱动关键配置可以逐项确认on: push: branches: [dev] paths: - packages/containers/** - .github/workflows/containers.yml - package.json workflow_dispatch: permissions: contents: read packages: write jobs: build: runs-on: blacksmith-4vcpu-ubuntu-2404 env: REGISTRY: ghcr.io/${{ github.repository_owner }} TAG: 24.04几个值得关注的点触发路径设计仅在dev分支上、且改动涉及packages/containers/**、工作流自身或package.json时触发。把package.json纳入触发路径正是为了配合 build.ts 的BUN_VERSION派生逻辑——Bun 版本一升级镜像就自动重建Registry 跟随仓库所有者REGISTRY写为ghcr.io/${{ github.repository_owner }}而非硬编码仓库改名或迁移后无需改动工作流多架构构建的完整前置作业依次使用 QEMUdocker/setup-qemu-action为 arm64 交叉模拟提供支持、Docker Buildxdocker/setup-buildx-action提供构建器并以GITHUB_TOKEN登录 GHCR依赖上面的packages: write权限最终执行bun ./packages/containers/script/build.ts --push与 README 的推送命令一致。五、在 Workflow 中使用这些镜像README 给出的job.container用法示例如下任何 Linux 作业都可以这样引用jobs: build-cli: runs-on: ubuntu-latest container: image: ghcr.io/anomalyco/build/bun-node:24.04使用时的注意事项继承自原文档 Notes容器内的作业运行环境就是对应镜像本身因此bun、node、cargo等命令开箱即用无需再走 setup 步骤选择镜像按最小依赖原则纯 JS 任务用bun-nodeRust 任务用rustTauri 桌面端构建用tauri-linux发布流水线用publish避免不必要的层若作业需要 Buildx需为容器配置对宿主 Docker daemon 的挂载或改用 privileged 的docker-in-docker方案macOS/Windows 作业无法使用本套镜像保持原有安装流程即可。六、小结可验证的目录索引整套方案的信息在仓库中的落点非常集中便于按图索骥内容路径镜像说明与使用方式packages/containers/README.md构建/推送脚本packages/containers/script/build.ts基础工具层packages/containers/base/DockerfileBun Node 层packages/containers/bun-node/DockerfileRust 层packages/containers/rust/DockerfileTauri Linux 依赖层packages/containers/tauri-linux/Dockerfile发布工具层packages/containers/publish/Dockerfile自动发布工作流.github/workflows/containers.yml这套设计的关键经验可以概括为三点以继承链复用基础层控制镜像数量与构建时间把版本号Bun、Node、TAG参数化并绑定到仓库根package.json使升级运行时与重建镜像自动化衔接用REGISTRYbuild-arg 隔离镜像源保证同一套 Dockerfile 可服务公开与私有注册表。【免费下载链接】opencodeThe open source coding agent.项目地址: https://gitcode.com/GitHub_Trending/openc/opencode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考