开发工具代码编辑器数据科学【免费下载链接】positronPositron, a next-generation data science IDE项目地址https://gitcode.com/gh_mirrors/po/positron点击查看免费下载Positron 的 e2e 测试需要在多种 Linux 发行版和 CPU 架构下获得完全一致的运行环境docker/images/目录下的镜像配置正是为此而设计它既是 GitHub Actions CI 流水线的标准测试容器也是本地开发尤其是 Apple Silicon 开发机复现 CI 环境的载体。读完本文你将理解 Positron 各 CI 镜像的目录组织与内容构成、多架构镜像的构建与发布机制、PostgreSQL 测试数据库的固定初始化流程、开发许可证的注入方式以及如何在本地一键拉起与 CI 相同的环境跑 Playwright e2e 测试。一、镜像仓库的目录结构docker/images/按操作系统分目录组织每个目录包含该系统的 Dockerfile、按架构拆分的 docker-compose 文件docker-compose.amd64.yml/docker-compose.arm64.yml以及deps/下的按架构区分的系统软件包清单。README 中明确列出的核心目录如下ubuntu24_04/— Ubuntu 24.04 环境支持 AMD64 与 ARM64 双架构包含用于测试的 PostgreSQL 数据库配置详见 Ubuntu 24.04 READMErocky_8/— Rocky 8 环境同样双架构、含 PostgreSQL 测试配置详见 Rocky 8 READMErocky_9/— Rocky 9 环境双架构专门为 Workbench e2e 的 Rocky 泳道lane而存在——Posit 没有发布 RHEL 8 的 arm64 Workbench 包只有 Rocky 9 才能让 Apple Silicon 上的本地调试保持原生native循环详见 Rocky 9 READMEopenSUSE15_6/— openSUSE Leap 15.6 环境双架构同时服务 Chromium e2e 的 SUSE 泳道和 Workbench e2e 的 SUSE 泳道。需要注意它与 Rocky 泳道的一个关键差异openSUSE 的 Workbench 包只有 x86_64 版本因此npm run pwb -- --osopensuse15在 Apple Silicon 上会强制运行仿真的 amd64 容器而 CI runner 本身是 amd64、可以原生运行。从仓库实际内容看除 README 列举的四个目录外docker/images/下还存在SLES15_6/、debian/和共享的postgres/目录。这与 ci-images-build-os.yml 工作流中workflow_dispatch的os选项ubuntu24_04、rocky_8、rocky_9、openSUSE15_6、SLES15_6、debian完全对应——镜像构建工作流支持这六套 OS 配置而顶层 README 的清单只覆盖了其中的四套。每个 OS 目录的内部布局高度一致以 Ubuntu 为例见 ubuntu24_04/README.md文件作用Dockerfile.ubuntu24_04同时适配 AMD64 与 ARM64 的单一 Dockerfile通过ARCHbuild arg 区分docker-compose.arm64.yml/docker-compose.amd64.yml按架构拆分的 Compose 编排各定义db与test两个服务deps/ubuntu2404_packages_amd64.txt/..._arm64.txt两种架构各自的 apt 软件包清单PostgreSQL 镜像则独立构建于共享的 postgres/ 目录Dockerfile.postgresinit-scripts/被各 compose 文件中的db服务引用。二、镜像里装了什么统一的测试环境构成README 的Purpose一节指出这些镜像为 Positron 在不同架构下提供一致的测试环境包含构建依赖Build dependencies所需的 R 与 Python 环境包括e2e 测试内容test/e2e/test-files实际用到的包运行时测试依赖例如 QuartoPositron license server开发用许可证服务Fluxbox 与 x11vnc用于在本地看到正在运行的测试界面。结合 Dockerfile.ubuntu24_04 的源码可以把这套环境拆解得更具体架构参数化Dockerfile 以ARG ARCHamd64开头并FROM --platformlinux/${ARCH} ubuntu:24.04随后从 compose 文件接收CPU_ARCH、NODE_ARCH、NODE_VERSION、RIG_ARCH、QUARTO_ARCH、CONDA_ARCH、AWS_ARCH、R_ARCH_SUFFIX等架构相关 build args。这解释了 compose 文件中 amd64 传R_ARCH_SUFFIX: 而 arm64 传-arm64的原因——R 二进制包的下载地址依赖该后缀。语言运行时R通过rig管理多版本镜像安装 R 4.5.2默认与 R 4.4.2并将pak装入共享 site libraryPython三路并存——uv 管理的 Python 3.10.12 venv/root/.venvCI 中通过RETICULATE_PYTHON指向它、pyenv 安装的 Python 3.13.0、以及藏在~/scratch下的 conda 3.12.10 环境。这个多环境并存的布局是有意为之e2e 测试需要覆盖 Reticulate/Positron 发现不同 Python 环境的场景包括隐藏解释器hidden interpreters这类边界情况Node.js固定版本当前 compose 文件锁定24.18.0加node-gyp、npm-run-all、yarn全局依赖。测试内容依赖的锁定策略镜像构建时会拉取test/e2e/test-files下的 requirements.txt 和 DESCRIPTION分别装入 uv venv 与 R site library。R 侧安装特别值得注意它把 PPMPosit Package Manager仓库钉到一个带日期的快照compose 中的PPM_SNAPSHOT: 2026-06-30避免latest渠道元数据已更新但文件已轮换的发布窗口竞争导致间歇性 404而运行时的.Rprofile仍指向latest。Quarto 与 TinyTeX下载对应架构的 Quarto 安装包TinyTeX 安装后被迁移到/opt/TinyTeX并把tlmgr仓库固定到单一 CTAN 镜像而非轮询的mirror.ctan.org对网络依赖步骤做了三层重试保证构建确定性。无头渲染的字体加固Dockerfile 中有一段针对 Electron/Chromium 冷启动的注释——fontconfig 的FcInit在精简镜像上多线程并发时曾在 libexpat 深处偶发 GP-fault是 amd64 上 ext-host 泳道的主要 flake 来源。镜像层通过升级带安全补丁的libexpat1/libfontconfig1、装齐字体集并在构建末尾执行fc-cache -f把缓存预热使运行时的FcInit变成纯缓存命中。这是用镜像层缩小竞态窗口的典型做法。许可证服务构建阶段用TOKENbuild arg 克隆私有的posit-dev/positron-license仓库并cargo build出pdollicense server随镜像分发——这正是 READMEPurpose中 the positron license server 的落点。可视化端口EXPOSE 8080 5900 9323分别对应测试服务、VNCx11vnc和 Playwright HTML 报告与本地开发文档中的http://localhost:9323报告地址相互印证。Rocky 与 SUSE 系镜像的内容差异在 rocky_9/README.md 中有一张极具参考价值的对照表说明了 EL8 → EL9 后哪些 Rocky 8 历史 workaround 被移除Rocky 8 的做法Rocky 9 的做法原因用ar x解包 Quarto.deb直接dnf install官方 Quarto RPMar解包跳过了 postinstquarto 二进制无法进入 PATH源码编译 GEOS/GDAL/libgit2使用发行版包EPEL9 的 GEOS 3.13 / GDAL 3.10 比 Rocky 8 手编版本更新且 EL8 的 GDAL 3.0.4 缺少terra所需的GDAL_DCAP_MULTIDIM_RASTER钉gcc-toolset-13并打 Makeconf 补丁用系统 GCC 11EL8 的 GCC 8 不支持 Arrow 需要的 C20GCC 11 支持arm64 上装系统 TeX Live双架构都用 TinyTeXTinyTeX 需要 glibc ≥ 2.29EL8 为 2.28EL9 为 2.34钉sf1.0-20、限制 bokeh/panel 等按DESCRIPTION/requirements.txt原样安装那些钉版是为绕开 EL8 源码编译失败--set-enabled powertools--set-enabled crbEL9 将 PowerTools 更名为 CodeReady BuilderPPM 渠道__linux__/rockylinux8PPM 渠道__linux__/rhel9rockylinux8不是真实存在的 PPM 渠道404R 因此退回源码编译rhel8实际映射为centos8此外 EL8 → EL9 的软件包改名procps→procps-ng、postgresql-devel→libpq-devel、fluxbox→openbox等在deps/rocky9_packages_*.txt中逐一对应处理而perl与libxcrypt-compat两个包之所以显式列出是因为 EL9 更精简的基础镜像不再传递性地提供它们前者让tlmgr能运行后者解决 uv 预编译 CPython 依赖libcrypt.so.1的加载问题。这类细节是维护多发行版 CI 镜像时非常实用的踩坑记录。三、PostgreSQL 测试数据库固定库名与初始化脚本README 明确规定连接容器内 PostgreSQL 需要设置以下环境变量E2E_POSTGRES_USER— e2e 测试使用的 PostgreSQL 用户默认testuserE2E_POSTGRES_PASSWORD— e2e 测试使用的密码默认testpassword数据库名不再可配置Postgres 容器固定初始化两个库——periodic元素周期表示例数据与dvdrentalDVD 租赁示例数据。这个固定库名决策在 postgres/init-scripts/10-init-databases.sh 的注释中写得很清楚官方 Postgres entrypoint 只会自动执行 SQL 到唯一的POSTGRES_DB而各数据集需要各自独立的库因此脚本显式创建两个库并从/sql/加载 dumpdump 特意放在/sql而非 entrypoint 自动执行目录避免被二次灌入POSTGRES_DB。脚本全文逻辑如下# 创建两个固定库 psql -v ON_ERROR_STOP1 --username $POSTGRES_USER --dbname postgres -EOSQL CREATE DATABASE periodic; CREATE DATABASE dvdrental; EOSQL # 分别加载对应 dump psql -v ON_ERROR_STOP1 --username $POSTGRES_USER --dbname periodic -f /sql/periodic_table.sql psql -v ON_ERROR_STOP1 --username $POSTGRES_USER --dbname dvdrental -f /sql/dvdrental.sqldocker/images/postgres/Dockerfile.postgres 的构建也很简洁基于postgres:latest把init-scripts/拷入/docker-entrypoint-initdb.d/由 entrypoint 自动执行、把sql/拷入独立的/sql/目录并给脚本加执行权限。它预期外部注入标准的POSTGRES_USER/POSTGRES_PASSWORD/POSTGRES_DB变量而在 GitHub Actions 中这些值由E2E_*secrets 传入如 test-e2e-ubuntu.yml 的services.postgres块。在 compose 侧db服务还体现了两个工程细节健康检查pg_isready -U ${E2E_POSTGRES_USER:-testuser} -d periodic间隔 5 秒、重试 20 次、start_period30 秒test服务通过depends_on: db: condition: service_healthy保证先等数据库就绪再启动测试容器——这正是 READMEUsage in GitHub Actions中Start db container and await its readiness的具体实现环境传递test服务拿到的是测试视角的连接参数POSTGRES_HOSTdb、POSTGRES_PORT5432、POSTGRES_DBperiodic、POSTGRES_DVDRENTAL_DBdvdrental凭据同样来自E2E_POSTGRES_*变量带testuser/testpassword兜底默认值可参考 docker-compose.amd64.yml。四、GitHub Actions 中的使用方式README 概括了工作流使用镜像的通用模式即三步从 GitHub Container Registry 拉取指定镜像启动 db 容器并等待其就绪携带必要环境变量启动测试容器。ci-images-build-os.yml 揭示了镜像的生产侧。它通过workflow_dispatch手动触发输入tag与osbuildjob 以amd64/arm64矩阵在各自原生 runnerubuntu-24-arm64-8-core或 amd64 自托管 runner上分别执行docker buildx bake -f docker-compose.$ARCHITECTURE.yml test --set test.platformlinux/$ARCHITECTURE --load每个架构推送单架构标签positron-os-arch:tag随后mergejob 用docker buildx imagetools create把两个架构标签拼成多架构 manifestpositron-os:tag。推送与 manifest 创建都包在retry()里最多 4 次、退避递增注释说明了原因GHCR 在高并发下会间歇性返回unknown blob/ HTTP2PROTOCOL_ERROR。Postgres 镜像由独立的 ci-images-build-postgres.yml 走同样的双架构 manifest 合并流程发布为positron-postgres。消费侧以 test-e2e-ubuntu.yml 为代表job 的container字段直接使用ghcr.io/posit-dev/positron-ubuntu24:tag作为 runner 容器options: --user 0:0 --initservices.postgres挂载ghcr.io/posit-dev/positron-postgres:tag并映射 5432 端口job 级env中同时导出E2E_POSTGRES_USER/E2E_POSTGRES_PASSWORD来自 secrets、R_LIBS_SITE/R_LIBS_USER指向镜像内的共享 site library/usr/local/lib/R/site-library、RETICULATE_PYTHON: /root/.venv/bin/python等——这些与上文镜像内各路径一一呼应拉取私有镜像需要 GHCR 凭据工作流用POSITRON_GITHUB_RO_USER/POSITRON_GITHUB_RO_PAT静态 PAT注释解释了原因bot 无法把 token 安全地传给 job。Ubuntu 24.04 的 README 还指出该镜像被 PR、Merge、Full Suite、Release 与 Extension Verification 等工作流复用从仓库工作流目录的检索结果看positron-ubuntu24同样出现在单元测试、ext-host、内存指标、扩展夜间检查等多个泳道中是 Positron 事实上的默认 Linux 测试底座。五、Positron Server 开发许可证POSITRON_DEV_LICENSEREADME 中独立成节的部分Positron Server 需要一个开发许可证在 CI 和本地环境都要设置。CI 侧通过POSITRON_DEV_LICENSEsecret 注入。配套的 install-license 复合 action 展示了完整流程——克隆posit-dev/positron-license仓库、安装 Rust stable 工具链、cargo build出pdol最后把密钥写入pdol/target/debug/pdol_rsa并chmod 600本地侧通过license.txt文件设置。run-with-license.sh 是该机制的脚本化实现校验license.txt与.env存在、安全地逐行导出.env只接受KEYVALUE形式拒绝任意 shell 代码、用docker manifest inspect验证 ghcr.io 登录状态然后export POSITRON_DEV_LICENSE$(cat license.txt)保留多行再执行docker compose up。六、本地开发在 Apple Silicon 上复现 CIREADME 末尾把本地开发指向 Ubuntu 24.04 的 README后者进一步指向 docker/environments/arm-local/。这是在 ARM 机器上完整复现 CI 环境的工具链核心流程前置准备来自 arm-local/README.md创建配置cp .env.example .env填入 E2E Postgres 连接信息创建license.txtPositron Workbench 开发许可证内容docker login ghcr.io -u 你的 GitHub 用户名密码使用带read:packages权限的 Personal Access Token给 Docker Desktop 分配足够资源建议 CPU 8 核、内存 16 GB、Swap 2 GB。两个终端快速起步# 终端 1启动容器 npm run arm:start # ubuntu24Rocky 8 用 npm run arm:start:rocky # 终端 2连接并初始化 npm run arm:connect # 菜单二选一Setup/Update 环境首次克隆/后续拉取重装或直接进入 shell这些 npm 脚本定义在根 package.jsonarm:start→run-with-license.sh ubuntu24arm:connect→connect.sh另有arm:stop、arm:stop:rocky、arm:status。容器就绪后即可运行测试# Electron 测试容器内 npx playwright test --project e2e-electron --workers 2 --grep :connections # 浏览器测试可从本地 Positron 仓库直接跑 npx playwright test --project e2e-server --workers 2 --grep :web配套能力还包括CI 免交互模式cd docker/environments/arm-local ./connect.sh --ci main、失败报告npx playwright show-report --host 0.0.0.0浏览器访问http://localhost:9323、VNC 实时观察容器内执行/tmp/start-vnc.shVNC 客户端连localhost:5900、手动启动 Positron./scripts/code.sh --no-sandbox、以及容器内 SSH宿主机~/.ssh/config配Port 3456后配合 VS Code Remote SSH。文档还特别警告test/e2e/fixtures/settings.json会被测试运行改写不要提交该文件。对于只想用 docker compose 直起某一 OS 镜像的场景不经过 arm-local 包装各 OS 目录的 compose 文件可直接使用例如 rocky_8/README.md 给出cd rocky_8 docker-compose -f docker-compose.amd64.yml up -d # 或 docker-compose.arm64.yml需要GITHUB_TOKEN作为TOKENbuild arg 克隆positron-license以及E2E_POSTGRES_USER/E2E_POSTGRES_PASSWORD/POSITRON_DEV_LICENSE等环境变量。七、关键环境变量速查汇总 README 与各 OS README、脚本中出现的环境变量变量作用默认值 / 说明E2E_POSTGRES_USERe2e 测试的 PostgreSQL 用户testuserE2E_POSTGRES_PASSWORDe2e 测试的 PostgreSQL 密码testpasswordPOSTGRES_USER/POSTGRES_PASSWORD/POSTGRES_DBPostgres 容器自身标准变量由E2E_*派生注入CI 中来自E2E_*secretsPOSITRON_DEV_LICENSEPositron Server 开发许可证多行文本CI 用 secret本地经license.txt导出GITHUB_TOKEN克隆私有positron-license仓库作为TOKENbuild arg构建/本地 compose 必需POSTGRES_HOST/POSTGRES_PORT/POSTGRES_DB/POSTGRES_DVDRENTAL_DB测试容器内的数据库连接参数compose 中固定为db/5432/periodic/dvdrental八、小结与延伸阅读这套镜像体系的设计要点可以归纳为三条架构参数化单一 Dockerfile 双 compose 按架构 deps 清单 GHCR 多架构 manifest、数据布局固定化Postgres 双库硬编码初始化消除环境漂移、测试内容与镜像同频从test/e2e/test-files的requirements.txt/DESCRIPTION精确安装依赖并用 PPM 日期快照锁定构建确定性。结合 CI 工作流中的容器服务编排与本地的arm-local脚本开发者可以在 Apple Silicon 上获得与 GitHub Actions 高度一致的调试环境。如需继续深入建议按以下路径阅读仓库源码镜像总览与目的docker/images/README.md各 OS 镜像ubuntu24_04、rocky_8、rocky_9EL8→EL9 差异对照表数据库初始化postgres/Dockerfile.postgres、10-init-databases.sh、periodic_table.sql、dvdrental.sql镜像构建与发布ci-images-build-os.yml、ci-images-build-postgres.ymlCI 消费示例test-e2e-ubuntu.yml、test-e2e-rocky.yml、install-license action本地开发docker/environments/arm-local/README.md、run-with-license.sh测试内容依赖源test/e2e/test-files赞分享开发工具代码编辑器数据科学【免费下载链接】positronPositron, a next-generation data science IDE项目地址https://gitcode.com/gh_mirrors/po/positron点击查看免费下载相关推荐如何将Imposm3集成到现有GIS工作流中完整指南 ️如何将Imposm3集成到现有GIS工作流中完整指南 ️ OpenStreetMap数据导入工具Imposm3是GIS工作流中的强大助手它能高效地将OS大数据用 devbox 构建可预测的本地 MySQL 开发环境服务启停、数据初始化与连接实践用 devbox 构建可预测的本地 MySQL 开发环境服务启停、数据初始化与连接实践 本篇技术指南聚焦 devbox 项目中 MySQL 开发环境的完整搭建开发工具CLIInstant 定制 PostgreSQL 17 开发镜像构建指南pg_hint_plan 与 wal2json 的本地开发与 CI 实践Instant 定制 PostgreSQL 17 开发镜像构建指南pg_hint_plan 与 wal2json 的本地开发与 CI 实践 Instant 的后端数据库创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考