Baserow CI/CD实战指南：5个阶段从一次提交到Dockerhub发布

Baserow CI/CD实战指南5个阶段从一次提交到Dockerhub发布【免费下载链接】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往 Baserow 仓库推一个 commit背后的 GitLab CI/CD 流水线到底干了什么这篇文章拆解 .gitlab-ci.yml 定义的五阶段流水线、三个分支各自的触发规则、版本发布到 Dockerhub 的完整路径以及 Docker 层缓存的设计取舍。读完后你应能回答谁在什么时候构建、哪些东西会被推送出去、流水线卡住时该翻哪个文件。一次提交的Baserow流水线跑什么流水线固定分为五个阶段build构建开发镜像、lint代码检查、test测试、build-final构建生产镜像、publish发布。在 feature 分支上实际只会走到前三段的一半先构建 backend 和 web-frontend 的「开发变体」镜像。这里的开发变体指用 Dockerfile 里 dev 阶段编译出的镜像带全套开发依赖但在 CI 里它主要扮演缓存角色——把 Python、Node 依赖层固化下来省得每次重装。随后 lint 和 test 阶段直接在这些开发镜像里执行检查后端有 lint、启动自检和拆成 10 个并行组的 pytest 单测外加一个覆盖度合并任务前端跑 eslint/stylelint 与单元测试。端到端测试用 Playwright 分 4 片执行把前端、后端、Celery worker、PostgreSQL 和模拟 S3 一起拉起来但按规则只在 master 和 develop 之外的分支上跑。这套机制还带「跳过」逻辑共享任务模板定义在 .gitlab/ci_includes/jobs.yml其中 skippable 类任务会判断当前 commit 是否已跑过相同测试、且相关文件没有变化是则直接跳过避免重复劳动。feature 分支到此为止——不构建生产镜像也不发布任何东西。什么分支会触发生产镜像构建与发布build-final 阶段是最关键的闸门它只在四种情况下运行——master 分支、develop 分支、commit 消息里带[build-all]标签或手动把BUILD_ALL_IN_ONE变量设为 true。构建出的生产镜像会打上ci-tested-前缀的标签存进 GitLab 的 CI 镜像仓库这个前缀是发布任务的唯一准入凭证任何没通过测试的镜像都无法被推送出去。develop 分支在测试通过后会把镜像以develop-latest标签推到 Dockerhub同时触发下游项目如 baserow-saas的流水线。master 分支构建逻辑相同但发布要等打 tag 才发生。至于清理ci-latest-和ci-tested-前缀的镜像超过 7 天就会被每天 11 点CET的定时任务删掉防止仓库无限膨胀。Baserow版本发布到Dockerhub的4个步骤正式版本的发布不需要人肉 docker push全程由流水线完成从 develop 向 master 发起合并请求并合并等合并提交的流水线成功完成构建与测试给这个合并提交打上版本 tag比如1.8.2GitLab 会为 tag 自动开一条新流水线tag 流水线把已测试镜像推到 Dockerhub打latest和版本号两个标签。有几个边界情况值得记住tag 打在 master 的旧提交上时只会推版本号标签而不会动latesttag 打在任何非 master 提交上会直接失败因为版本发布只允许来自 master如果第 2 步的构建还没成功tag 流水线也会失败什么都推不出去。另外打 tag 时还会打包并发布 deploy/helm 下的 Helm chart 到 chart 仓库。Baserow CI如何用Docker层缓存省时间 ⚡整条构建链靠 BuildKit 的镜像缓存加速规则分两层。普通分支构建时先尝试拉取同分支最新的ci-latest-分支名镜像做缓存源拉不到就退而用 develop 分支的ci-latest-develop再拉不到才从头构建构建完还会把新镜像推回去供下次流水线复用。build-final 阶段则同时用开发镜像和上一个生产镜像做双缓存。master 分支比较特殊它不维护自己的缓存只从 develop 借。原因是发布之间可能隔好几个星期自己的缓存要么早被 7 天清理任务删掉要么层层落后于 develop让「只有 develop 会坏、先在 develop 修好再进 master」比双份维护更稳妥。缓存也有安全代价——底层镜像和系统包的层一旦被缓存就不再重跑新发布的补丁进不来。Baserow 的对策是每天在 develop 上跑一条定时流水线把TRIGGER_FULL_IMAGE_REBUILDyes设为变量强制所有构建加--no-cache --pull从零重建顺带刷新供其他分支复用的缓存这条「早班流水线」还会额外执行标记了once_per_day_in_ci的低频测试。ARM 构建只挂在 master 上通过BUILD_ARM变量和 buildx 远程代理连到一台 ARM64 服务器做多架构构建多花 5-10 分钟所以 develop 和功能分支的镜像只有 AMD64。流水线不听话时手动触发与排错两个 commit 消息标签是最常用的开关[skip-ci]让某次提交完全不走 CI[build-all]则强制构建全部镜像含生产变体、all-in-one、cloudron。改动 CI 配置本身时更好的办法是从 GitLab 的 pipelines/new 页面为指定分支手动开一条流水线逐个覆盖变量做实验常见的有TRIGGER_FULL_IMAGE_REBUILD、ENABLE_JOB_SKIPPING、ENABLE_COVERAGE、ENABLE_RELEASES、BUILD_ALL_IN_ONE。有两张 CI 基础镜像——跑 docker build 的 dind 镜像和装 git、jq 等工具的 util 镜像——它们的构建任务被设成了手动触发避免每个新分支都重复构建改了对应 Dockerfile 后流水线里会出现对应的手动任务点一下即可重建推送。排错时建议打开流水线页面把「Group jobs by」切到 Job dependencies 并勾选 Show dependencies能看到全部任务的依赖图完整规则以 docs/development/ci-cd.md 为准。想在本地复现问题时用 dev.sh 起一套完整的开发环境端到端测试脚本独立放在 e2e-tests/ 目录下可以单独跑。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考