企业官网建设流程全解析

一次推送跑完 3 个阶段：Baserow CI/CD 流水线与 Docker 镜像构建拆解

【免费下载链接】baserowBuild databases, automations, apps & agents with AI — no code. Open source platform available on cloud and self-hosted. GDPR, HIPAA, SOC 2 compliant. Best Airtable alternative.项目地址: https://gitcode.com/GitHub_Trending/ba/baserow

新人第一次把功能分支合进develop之后，本地终端就再没出现过任何反应——但服务器后台正默默跑着一整条链：拉取代码、构建镜像、执行自动化测试、把通过验证的 Docker 镜像推送到仓库、再通知下游项目重新构建。这条由 GitLab CI/CD 驱动的流水线，把"能不能合并"的判断从人手里交给了机器，是 Baserow 迭代速度的底层支撑。

从 commit 到镜像上线的主干链路

主干可以压缩成一句话：build阶段先产出带全部开发依赖的 dev 镜像 →lint/test阶段挂载源码在 dev 镜像里跑完所有检查 →build-final以 dev 镜像为缓存构建生产镜像 →publish只推送盖过"测试通过"章的镜像。所有细节都写在根目录的.gitlab-ci.yml和docs/development/ci-cd.md里，配置文件开头的那行注释指路得很清楚。

镜像层缓存为什么敢跨分支复用

问题：Baserow 的后端是 Python、前端是 Node.js，从零装一遍依赖要烧掉流水线大量时间。

做法：构建全部基于BuildKit缓存。每次构建把带ci-latest-分支名标签的镜像推回镜像仓库，作为下一次流水线的起点；build-final阶段再拿 dev 镜像里保存的中间层去加速生产镜像的构建。

代价：这里有个容易踩的坑——一旦缓存了FROM 基础镜像和apt upgrade这两层，Docker 就永远不会重跑它们，哪怕基础镜像已经发布了安全补丁。Baserow 的解法是每天在develop上定时触发一条TRIGGER_FULL_IMAGE_REBUILD=yes的流水线，强制全量重建所有缓存镜像，顺带跑一批标记为"每日一次"的慢测试。安全补丁因此最多只会在流水线里滞后一天。

develop 与 master 分支的镜像策略差异

问题：master 分支可能几周没有提交，如果它自己维护一套缓存，要么缓存先被 7 天清理任务删掉，要么层陈旧到形同虚设。

做法：master 干脆不自建缓存，直接复用develop最新的ci-latest镜像构建。好处还不止省时间：如果某天基础镜像的变更把构建打坏了，坏的一定是 develop 和所有功能分支，团队先在开发线修好，master 永远站在"已验证安全"的层上。换句话说，develop 是全仓库唯一承担"重建风险"的地方，master 只消费结果。

权衡：发布流程因此快了很多，但 master 的镜像与 develop 的逐层共享，任何对"分支隔离"的假设都要小心。

一条提交标签跳过或拉满整条流水线

问题：不是每次提交都值得跑完整流水线，也不是每次都需要只跑最小集。

做法：在 commit message 里写[skip-ci]，这条提交直接不触发任何流水线；写[build-all]，则不管当前分支是谁，连 all-in-one、cloudron 等全部镜像变体一起构建。GitLab 界面还支持手动创建一次性流水线，在 UI 上直接覆盖ENABLE_JOB_SKIPPING、BUILD_ARM这类变量——改 CI 配置时先用手动流水线验证，再提 MR，比等自动流水线跑挂了再回滚省事得多。

多平台构建：ARM64 只给 master 用

问题：用户既在 x86 服务器上自托管，也越来越多地跑在 ARM 机器上。

做法：master 分支的镜像同时构建 AMD64 和 ARM64 两种架构，靠 Docker 的远程构建驱动连到一台专用 ARM64 服务器上执行 ARM 侧构建，而不是本地模拟。

代价：ARM 构建要给流水线加上 5~10 分钟。之所以只开在 master 上（BUILD_ARM_ON_BRANCH控制），就是为了让 develop 和功能分支的反馈循环保持快——每天几十次推送都不需要等 ARM 那一份，代价只是开发线出来的镜像暂时只有 AMD64。

自己动手：5 步跑通验证

1. 克隆仓库：git clone https://gitcode.com/GitHub_Trending/ba/baserow
2. 读 CI 配置，重点看stages与variables两块，理解每个变量控制哪段行为
3. 对照docs/development/ci-cd.md里的分支说明，弄清自己推哪个分支会触发哪些阶段
4. 本地起开发环境：./dev.sh start，用 本地开发脚本 把前后端和数据库一并拉起来
5. 本地先跑后端测试再推 MR，把 CI 要抓的问题提前在本地抓掉

这套流程真正省下的，不是某一步的时间，而是"每次发布都需要人肉确认镜像是否可信"这件事——构建、验证、推送被绑成原子操作，人只在打 tag 那一刻出现。

【免费下载链接】baserowBuild databases, automations, apps & agents with AI — no code. Open source platform available on cloud and self-hosted. GDPR, HIPAA, SOC 2 compliant. Best Airtable alternative.项目地址: https://gitcode.com/GitHub_Trending/ba/baserow