Ghost 的 Tinybird 数据管道 CI/CD 实践用 tb CLI 构建、校验、部署与 Preview 分支管理【免费下载链接】GhostIndependent technology for modern publishing, memberships, subscriptions and newsletters.项目地址: https://gitcode.com/GitHub_Trending/gh/Ghost本文以 Ghost 仓库中 Tinybird CLI 规范文档 CI/CD 集成指南 为核心系统讲解「Tinybird Local 构建测试 Cloud 部署校验」这一 CI/CD 推荐模式覆盖 PR 校验三步流程、生产部署命令、GitHub Actions 与 GitLab CI 完整示例、Preview 预览环境及其与 Kafka/S3/GCS 连接器的配合方式并结合 Ghost 仓库真实工作流 tinybird.yml 与本地开发编排 compose.dev.analytics.yaml 说明该模式在大型项目中的落地细节帮助读者为 Tinybird 项目搭建一条可复现、可审计、可预览的持续交付流水线。一、推荐模式Tinybird Local 负责构建测试Cloud 负责校验与部署规范给出的核心思路是把“验证”与“部署”拆分到两个阶段CIPR 阶段在 CI 中启动一个 Tinybird Local 服务容器用tb --local build构建项目、tb --local test run运行测试最后用tb --cloud deploy --check对 Cloud 做一次 dry-run 校验CD合入主干阶段变更合并到 main 分支后执行tb --cloud deploy完成生产部署。这种拆分的好处在于Local 阶段快速拦截语法与逻辑错误deploy --check在到达生产之前捕获模式兼容性、依赖解析、资源命名三类问题把 Cloud 部署留给有权限、可审计的 CD 阶段。规范同时明确生产部署必须走 CI/CD而不是手工操作。二、CIPull Request 校验三步走推荐的 PR 校验流程依次执行三条命令tb --local build— 面向 Tinybird Local 构建项目tb --local test run— 面向 Tinybird Local 运行测试tb --cloud deploy --check— 校验部署在 Cloud 上能否成功dry run。其中deploy --check是关键防线它在不做任何真实变更的前提下提前暴露 schema 不兼容、资源间依赖解析失败、命名冲突等问题避免这些问题流入生产。值得注意的是Ghost 仓库自己的 CI 工作流采用了等效但更简洁的写法tinybird.yml 中直接运行tb build与tb test run不带--local前缀。这与 CLI 规范 SKILL.md 中「配置好dev_mode后使用裸tb build--cloud/--local/--branch仅作显式手动覆盖」的约定一致——两种写法指向同一行为显式--local更利于在任意上下文中阅读流水线脚本裸命令则依赖项目内tinybird.config.json的开发模式配置。Ghost 工作流还有两处值得借鉴的工程细节路径过滤workflow 只在ghost/core/core/server/data/tinybird/**、compose.dev.analytics.yaml 及工作流自身发生变更时运行tinybird.yml#L14-L18PR 场景下再叠加AurorNZ/paths-filter做变更检测避免无关改动触发昂贵的容器化测试CLI 版本钉死tinybird.yml#L81-L95 的注释记录了一次真实的上游回归——4.6.14 会把嵌套 JSON 对象以 ClickHouse Tuple 语法而非原始 JSON 写入 String 列导致pipes/mv_hits.pipe中所有JSONExtractString(payload, ...)返回空串、29 个 endpoint 测试全部读空。因此 Ghost 用uv tool install tinybird4.6.13钉住版本并要求与 docker/tb-cli/Dockerfile 保持同步。这说明规范中「不要盲目跟随最新 CLI」在真实项目中有硬性代价。三、CD生产部署的两种形态当变更合并到 main 分支时执行tb --cloud deploy这条命令会创建 staging 部署、迁移数据、再提升到 live一步完成。对于希望显式确认的部署流程规范给出两步式写法tb --cloud deployment create --wait tb --cloud deployment promote两步式把「创建 staging」与「promote 到生产」拆成两个人可介入的动作。规范中的 Key Principles 强调CD 流水线中应使用--wait让 CI job 的结果真实反映部署结果而不是「触发即成功」的假绿。Ghost 仓库的实际 CD 走的是另一条路tinybird.yml 的deployjob 仅在 main 分支且 Tinybird 数据文件有变更时触发并通过dispatch-workflowaction 调度独立的traffic-analytics-infra仓库工作流执行deploy_staging与deploy_production。从源码结构看这是把部署编排外置到基础设施仓库但「先 staging 后 production、且由 CD 而非人工触发」的原则与规范完全一致。四、示例GitHub Actions 工作流规范给出的 CI 工作流示例.github/workflows/tinybird-ci.ymlname: Tinybird CI on: pull_request: paths: - tinybird/** env: TINYBIRD_HOST: https://api.tinybird.co TINYBIRD_TOKEN: ${{ secrets.TB_ADMIN_TOKEN }} jobs: validate: runs-on: ubuntu-latest services: tinybird: image: tinybirdco/tinybird-local:latest ports: - 7181:7181 steps: - uses: actions/checkoutv4 - name: Install Tinybird CLI run: curl https://tinybird.co | sh - name: Build project run: tb --local build working-directory: tinybird - name: Test project run: tb --local test run working-directory: tinybird - name: Deployment check run: tb --cloud --host ${{ env.TINYBIRD_HOST }} --token ${{ env.TINYBIRD_TOKEN }} deploy --check working-directory: tinybirdCD 工作流示例.github/workflows/tinybird-cd.ymlname: Tinybird CD on: push: branches: [main] paths: - tinybird/** env: TINYBIRD_HOST: https://api.tinybird.co TINYBIRD_TOKEN: ${{ secrets.TB_ADMIN_TOKEN }} jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Install Tinybird CLI run: curl https://tinybird.co | sh - name: Deploy run: tb --cloud --host ${{ env.TINYBIRD_HOST }} --token ${{ env.TINYBIRD_TOKEN }} deploy working-directory: tinybird参数说明与可复制性要点services.tinybird使用tinybirdco/tinybird-local:latest并映射7181:7181这是 Tinybird Local 的标准 API 端口Ghost 的 compose.dev.analytics.yaml 中本地开发环境同样以 7181 端口 curl -f http://localhost:7181/v0/health健康检查的方式编排tinybird-local容器可直接对照参考TINYBIRD_HOST/TINYBIRD_TOKEN通过 workflow 级 env 注入admin token 必须存为 CI/CD secret绝不能写进代码deploy --check步骤显式携带--host与--token与 Local 构建步骤无需 token形成清晰的能力边界触发条件用paths: [tinybird/**]收敛到 Tinybird 项目目录对应规范原则「把 CI 触发范围限定在 Tinybird 项目文件路径内」。五、示例GitLab CI同一模式在 GitLab CI 中的写法CI 与 CD 各为一个 jobtinybird_ci: image: ubuntu:latest stage: test rules: - if: $CI_PIPELINE_SOURCE merge_request_event changes: - tinybird/** services: - name: tinybirdco/tinybird-local:latest alias: tinybird-local before_script: - apt update apt install -y curl - curl https://tinybird.co | sh - export PATH$HOME/.local/bin:$PATH script: - cd tinybird - tb --local build - tb --local test run - tb --cloud --host $TINYBIRD_HOST --token $TINYBIRD_TOKEN deploy --check tinybird_cd: image: ubuntu:latest stage: deploy rules: - if: $CI_COMMIT_BRANCH main changes: - tinybird/** before_script: - apt update apt install -y curl - curl https://tinybird.co | sh - export PATH$HOME/.local/bin:$PATH script: - cd tinybird - tb --cloud --host $TINYBIRD_HOST --token $TINYBIRD_TOKEN deploy与 GitHub Actions 版本相比GitLab 用rules.changes做路径过滤等价于 GitHub 的pathsCI job 通过services声明 Tinybird Local 容器CD job 只在CI_COMMIT_BRANCH main时进入 deploy stage。两条流水线体现的是同一套三原则Local 构建测试、deploy --check预校验、主干触发生产部署。六、Preview 环境每个 PR 一个可运行的 Tinybird 分支Preview 环境为每个 pull request 创建一个临时 Tinybird 分支让你在合并前用生产数据验证变更是这套 CI/CD 模式中「数据可预览」的一环。6.1 使用 SDKtinybird preview一步到位tinybird preview命令来自tinybirdco/sdk与tinybird-sdk注意不是tbCLI会创建一个名为tmp_ci_git-branch的分支、构建资源并部署# GitHub Actions 示例 - run: npx tinybird preview env: TINYBIRD_TOKEN: ${{ secrets.TINYBIRD_TOKEN }}SDK 会自动检测 CI 环境GitHub Actions、GitLab CI、Vercel、CircleCI、Azure Pipelines、Bitbucket Pipelines解析出正确的分支 tokenhost 也可从 token 推断无需额外配置。同名分支已存在时会先删除再重建保证幂等。6.2 使用 tb CLI手动创建预览分支tbCLI 没有preview子命令需要手动分步完成- name: Create preview branch run: tb --host ${{ env.TINYBIRD_HOST }} --token ${{ env.TINYBIRD_TOKEN }} branch create tmp_ci_${{ github.head_ref }} --last-partition - name: Build on branch run: tb --host ${{ env.TINYBIRD_HOST }} --token ${{ env.TINYBIRD_TOKEN }} --branchtmp_ci_${{ github.head_ref }} build要点branch create带--last-partition保证分支携带最新分区数据后续所有命令通过--branch指向该预览分支。分支的完整生命周期规范可参阅同目录的 branch-development 规则。6.3 清理PR 关闭时删除预览分支# SDK - run: npx tinybird branch delete tmp_ci_${{ github.head_ref }} # tb CLI - run: tb --host ${{ env.TINYBIRD_HOST }} --token ${{ env.TINYBIRD_TOKEN }} branch rm tmp_ci_${{ github.head_ref }}6.4 带连接器Kafka / S3 / GCS的 Preview当项目使用 Kafka、S3 或 GCS 连接器时tinybird preview不会在预览分支中从连接器摄入数据。要基于连接器数据测试需手动创建分支并追加--with-connectionstb branch create tmp_ci_my_feature --last-partition --with-connections对 S3/GCS 连接器导入样例数据tb --branchtmp_ci_my_feature datasource sample my_datasource --waitKafka 连接在预览分支中默认是停止的需要显式启动tb --branchtmp_ci_my_feature datasource start my_kafka_datasource这三条命令覆盖了预览场景下最常见的数据可用性缺口分支带连接、对象存储灌样例、流式数据源拉起。七、Ghost 仓库中的本地与 CI 编排对照规范中的模式在 Ghost 仓库有两处可验证的落地可作为「从规范到工程」的参照本地开发编排compose.dev.analytics.yaml 将 Tinybird 开发环境拆成四个服务——tinybird-local上游镜像钉死 digest、7181 端口、ClickHouse/Redis 卷持久化与健康检查、tb-cli基于 docker/tb-cli/Dockerfile 构建的一次性容器挂载ghost/core/core/server/data/tinybird目录执行资源初始化并通过shared-config卷把生成的 workspaceId/adminToken 传给ghost-dev与 analytics 代理、analyticsPROXY_TARGET指向http://tinybird-local:7181/v0/events的事件代理以及ghost-dev本体。其中tb-cli容器以service_completed_successfully作为下游依赖条件相当于把「本地 bootstrap」也纳入了编排的确定性之中。CI 侧.github/workflows/tinybird.yml 完整实现了本文第二节所述模式——changesjob 做 Tinybird 路径变更检测testsjob 以 digest 钉死的tinybirdco/tinybird-local服务容器运行tb buildtb test rundeployjob 在 main 分支且有数据文件变更时调度基础设施仓库执行 staging/production 部署。此外Ghost 还为 CI 专门制作了精简版 Tinybird Local 镜像 docker/tinybird-local-slim上游约 2.1GB 拉取/解压后约 6.9GB精简版约 0.7GB/2.4GB启动时间相当其构建与健康检查逻辑tb --output json --cloud sql SELECT 1 AS healthcheck见 Dockerfile#L44-L45可作为大型 runner 磁盘预算受限时的容器化参考。八、Key Principles 与延伸阅读规范总结的六条核心原则可作为落地清单逐条自查生产部署应通过 CI/CD 完成而非手动操作CI 中用 Tinybird Local 构建与测试tb --local build、tb --local test run再用tb --cloud deploy --check对 Cloud 做校验CD 流水线中使用--wait让 job 结果反映真实部署结果admin token 存为 CI/CD secret绝不入库将 CI 触发范围限定在 Tinybird 项目文件路径避免无关运行需要「每个 PR 一个带生产数据的完整可运行分支」时使用 Preview 环境。围绕本主题仓库中同一规范体系下还有几篇规则文档值得对照阅读cli-commands 命令速查、local-development 本地开发、development-workflows 开发工作流、branch-development 分支开发 与 tokens 令牌管理Tinybird 项目文件的组织方式则见 tinybird 技能目录。【免费下载链接】GhostIndependent technology for modern publishing, memberships, subscriptions and newsletters.项目地址: https://gitcode.com/GitHub_Trending/gh/Ghost创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Ghost 的 Tinybird 数据管道 CI/CD 实践：用 tb CLI 构建、校验、部署与 Preview 分支管理
Ghost 的 Tinybird 数据管道 CI/CD 实践用 tb CLI 构建、校验、部署与 Preview 分支管理【免费下载链接】GhostIndependent technology for modern publishing, memberships, subscriptions and newsletters.项目地址: https://gitcode.com/GitHub_Trending/gh/Ghost本文以 Ghost 仓库中 Tinybird CLI 规范文档 CI/CD 集成指南 为核心系统讲解「Tinybird Local 构建测试 Cloud 部署校验」这一 CI/CD 推荐模式覆盖 PR 校验三步流程、生产部署命令、GitHub Actions 与 GitLab CI 完整示例、Preview 预览环境及其与 Kafka/S3/GCS 连接器的配合方式并结合 Ghost 仓库真实工作流 tinybird.yml 与本地开发编排 compose.dev.analytics.yaml 说明该模式在大型项目中的落地细节帮助读者为 Tinybird 项目搭建一条可复现、可审计、可预览的持续交付流水线。一、推荐模式Tinybird Local 负责构建测试Cloud 负责校验与部署规范给出的核心思路是把“验证”与“部署”拆分到两个阶段CIPR 阶段在 CI 中启动一个 Tinybird Local 服务容器用tb --local build构建项目、tb --local test run运行测试最后用tb --cloud deploy --check对 Cloud 做一次 dry-run 校验CD合入主干阶段变更合并到 main 分支后执行tb --cloud deploy完成生产部署。这种拆分的好处在于Local 阶段快速拦截语法与逻辑错误deploy --check在到达生产之前捕获模式兼容性、依赖解析、资源命名三类问题把 Cloud 部署留给有权限、可审计的 CD 阶段。规范同时明确生产部署必须走 CI/CD而不是手工操作。二、CIPull Request 校验三步走推荐的 PR 校验流程依次执行三条命令tb --local build— 面向 Tinybird Local 构建项目tb --local test run— 面向 Tinybird Local 运行测试tb --cloud deploy --check— 校验部署在 Cloud 上能否成功dry run。其中deploy --check是关键防线它在不做任何真实变更的前提下提前暴露 schema 不兼容、资源间依赖解析失败、命名冲突等问题避免这些问题流入生产。值得注意的是Ghost 仓库自己的 CI 工作流采用了等效但更简洁的写法tinybird.yml 中直接运行tb build与tb test run不带--local前缀。这与 CLI 规范 SKILL.md 中「配置好dev_mode后使用裸tb build--cloud/--local/--branch仅作显式手动覆盖」的约定一致——两种写法指向同一行为显式--local更利于在任意上下文中阅读流水线脚本裸命令则依赖项目内tinybird.config.json的开发模式配置。Ghost 工作流还有两处值得借鉴的工程细节路径过滤workflow 只在ghost/core/core/server/data/tinybird/**、compose.dev.analytics.yaml 及工作流自身发生变更时运行tinybird.yml#L14-L18PR 场景下再叠加AurorNZ/paths-filter做变更检测避免无关改动触发昂贵的容器化测试CLI 版本钉死tinybird.yml#L81-L95 的注释记录了一次真实的上游回归——4.6.14 会把嵌套 JSON 对象以 ClickHouse Tuple 语法而非原始 JSON 写入 String 列导致pipes/mv_hits.pipe中所有JSONExtractString(payload, ...)返回空串、29 个 endpoint 测试全部读空。因此 Ghost 用uv tool install tinybird4.6.13钉住版本并要求与 docker/tb-cli/Dockerfile 保持同步。这说明规范中「不要盲目跟随最新 CLI」在真实项目中有硬性代价。三、CD生产部署的两种形态当变更合并到 main 分支时执行tb --cloud deploy这条命令会创建 staging 部署、迁移数据、再提升到 live一步完成。对于希望显式确认的部署流程规范给出两步式写法tb --cloud deployment create --wait tb --cloud deployment promote两步式把「创建 staging」与「promote 到生产」拆成两个人可介入的动作。规范中的 Key Principles 强调CD 流水线中应使用--wait让 CI job 的结果真实反映部署结果而不是「触发即成功」的假绿。Ghost 仓库的实际 CD 走的是另一条路tinybird.yml 的deployjob 仅在 main 分支且 Tinybird 数据文件有变更时触发并通过dispatch-workflowaction 调度独立的traffic-analytics-infra仓库工作流执行deploy_staging与deploy_production。从源码结构看这是把部署编排外置到基础设施仓库但「先 staging 后 production、且由 CD 而非人工触发」的原则与规范完全一致。四、示例GitHub Actions 工作流规范给出的 CI 工作流示例.github/workflows/tinybird-ci.ymlname: Tinybird CI on: pull_request: paths: - tinybird/** env: TINYBIRD_HOST: https://api.tinybird.co TINYBIRD_TOKEN: ${{ secrets.TB_ADMIN_TOKEN }} jobs: validate: runs-on: ubuntu-latest services: tinybird: image: tinybirdco/tinybird-local:latest ports: - 7181:7181 steps: - uses: actions/checkoutv4 - name: Install Tinybird CLI run: curl https://tinybird.co | sh - name: Build project run: tb --local build working-directory: tinybird - name: Test project run: tb --local test run working-directory: tinybird - name: Deployment check run: tb --cloud --host ${{ env.TINYBIRD_HOST }} --token ${{ env.TINYBIRD_TOKEN }} deploy --check working-directory: tinybirdCD 工作流示例.github/workflows/tinybird-cd.ymlname: Tinybird CD on: push: branches: [main] paths: - tinybird/** env: TINYBIRD_HOST: https://api.tinybird.co TINYBIRD_TOKEN: ${{ secrets.TB_ADMIN_TOKEN }} jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Install Tinybird CLI run: curl https://tinybird.co | sh - name: Deploy run: tb --cloud --host ${{ env.TINYBIRD_HOST }} --token ${{ env.TINYBIRD_TOKEN }} deploy working-directory: tinybird参数说明与可复制性要点services.tinybird使用tinybirdco/tinybird-local:latest并映射7181:7181这是 Tinybird Local 的标准 API 端口Ghost 的 compose.dev.analytics.yaml 中本地开发环境同样以 7181 端口 curl -f http://localhost:7181/v0/health健康检查的方式编排tinybird-local容器可直接对照参考TINYBIRD_HOST/TINYBIRD_TOKEN通过 workflow 级 env 注入admin token 必须存为 CI/CD secret绝不能写进代码deploy --check步骤显式携带--host与--token与 Local 构建步骤无需 token形成清晰的能力边界触发条件用paths: [tinybird/**]收敛到 Tinybird 项目目录对应规范原则「把 CI 触发范围限定在 Tinybird 项目文件路径内」。五、示例GitLab CI同一模式在 GitLab CI 中的写法CI 与 CD 各为一个 jobtinybird_ci: image: ubuntu:latest stage: test rules: - if: $CI_PIPELINE_SOURCE merge_request_event changes: - tinybird/** services: - name: tinybirdco/tinybird-local:latest alias: tinybird-local before_script: - apt update apt install -y curl - curl https://tinybird.co | sh - export PATH$HOME/.local/bin:$PATH script: - cd tinybird - tb --local build - tb --local test run - tb --cloud --host $TINYBIRD_HOST --token $TINYBIRD_TOKEN deploy --check tinybird_cd: image: ubuntu:latest stage: deploy rules: - if: $CI_COMMIT_BRANCH main changes: - tinybird/** before_script: - apt update apt install -y curl - curl https://tinybird.co | sh - export PATH$HOME/.local/bin:$PATH script: - cd tinybird - tb --cloud --host $TINYBIRD_HOST --token $TINYBIRD_TOKEN deploy与 GitHub Actions 版本相比GitLab 用rules.changes做路径过滤等价于 GitHub 的pathsCI job 通过services声明 Tinybird Local 容器CD job 只在CI_COMMIT_BRANCH main时进入 deploy stage。两条流水线体现的是同一套三原则Local 构建测试、deploy --check预校验、主干触发生产部署。六、Preview 环境每个 PR 一个可运行的 Tinybird 分支Preview 环境为每个 pull request 创建一个临时 Tinybird 分支让你在合并前用生产数据验证变更是这套 CI/CD 模式中「数据可预览」的一环。6.1 使用 SDKtinybird preview一步到位tinybird preview命令来自tinybirdco/sdk与tinybird-sdk注意不是tbCLI会创建一个名为tmp_ci_git-branch的分支、构建资源并部署# GitHub Actions 示例 - run: npx tinybird preview env: TINYBIRD_TOKEN: ${{ secrets.TINYBIRD_TOKEN }}SDK 会自动检测 CI 环境GitHub Actions、GitLab CI、Vercel、CircleCI、Azure Pipelines、Bitbucket Pipelines解析出正确的分支 tokenhost 也可从 token 推断无需额外配置。同名分支已存在时会先删除再重建保证幂等。6.2 使用 tb CLI手动创建预览分支tbCLI 没有preview子命令需要手动分步完成- name: Create preview branch run: tb --host ${{ env.TINYBIRD_HOST }} --token ${{ env.TINYBIRD_TOKEN }} branch create tmp_ci_${{ github.head_ref }} --last-partition - name: Build on branch run: tb --host ${{ env.TINYBIRD_HOST }} --token ${{ env.TINYBIRD_TOKEN }} --branchtmp_ci_${{ github.head_ref }} build要点branch create带--last-partition保证分支携带最新分区数据后续所有命令通过--branch指向该预览分支。分支的完整生命周期规范可参阅同目录的 branch-development 规则。6.3 清理PR 关闭时删除预览分支# SDK - run: npx tinybird branch delete tmp_ci_${{ github.head_ref }} # tb CLI - run: tb --host ${{ env.TINYBIRD_HOST }} --token ${{ env.TINYBIRD_TOKEN }} branch rm tmp_ci_${{ github.head_ref }}6.4 带连接器Kafka / S3 / GCS的 Preview当项目使用 Kafka、S3 或 GCS 连接器时tinybird preview不会在预览分支中从连接器摄入数据。要基于连接器数据测试需手动创建分支并追加--with-connectionstb branch create tmp_ci_my_feature --last-partition --with-connections对 S3/GCS 连接器导入样例数据tb --branchtmp_ci_my_feature datasource sample my_datasource --waitKafka 连接在预览分支中默认是停止的需要显式启动tb --branchtmp_ci_my_feature datasource start my_kafka_datasource这三条命令覆盖了预览场景下最常见的数据可用性缺口分支带连接、对象存储灌样例、流式数据源拉起。七、Ghost 仓库中的本地与 CI 编排对照规范中的模式在 Ghost 仓库有两处可验证的落地可作为「从规范到工程」的参照本地开发编排compose.dev.analytics.yaml 将 Tinybird 开发环境拆成四个服务——tinybird-local上游镜像钉死 digest、7181 端口、ClickHouse/Redis 卷持久化与健康检查、tb-cli基于 docker/tb-cli/Dockerfile 构建的一次性容器挂载ghost/core/core/server/data/tinybird目录执行资源初始化并通过shared-config卷把生成的 workspaceId/adminToken 传给ghost-dev与 analytics 代理、analyticsPROXY_TARGET指向http://tinybird-local:7181/v0/events的事件代理以及ghost-dev本体。其中tb-cli容器以service_completed_successfully作为下游依赖条件相当于把「本地 bootstrap」也纳入了编排的确定性之中。CI 侧.github/workflows/tinybird.yml 完整实现了本文第二节所述模式——changesjob 做 Tinybird 路径变更检测testsjob 以 digest 钉死的tinybirdco/tinybird-local服务容器运行tb buildtb test rundeployjob 在 main 分支且有数据文件变更时调度基础设施仓库执行 staging/production 部署。此外Ghost 还为 CI 专门制作了精简版 Tinybird Local 镜像 docker/tinybird-local-slim上游约 2.1GB 拉取/解压后约 6.9GB精简版约 0.7GB/2.4GB启动时间相当其构建与健康检查逻辑tb --output json --cloud sql SELECT 1 AS healthcheck见 Dockerfile#L44-L45可作为大型 runner 磁盘预算受限时的容器化参考。八、Key Principles 与延伸阅读规范总结的六条核心原则可作为落地清单逐条自查生产部署应通过 CI/CD 完成而非手动操作CI 中用 Tinybird Local 构建与测试tb --local build、tb --local test run再用tb --cloud deploy --check对 Cloud 做校验CD 流水线中使用--wait让 job 结果反映真实部署结果admin token 存为 CI/CD secret绝不入库将 CI 触发范围限定在 Tinybird 项目文件路径避免无关运行需要「每个 PR 一个带生产数据的完整可运行分支」时使用 Preview 环境。围绕本主题仓库中同一规范体系下还有几篇规则文档值得对照阅读cli-commands 命令速查、local-development 本地开发、development-workflows 开发工作流、branch-development 分支开发 与 tokens 令牌管理Tinybird 项目文件的组织方式则见 tinybird 技能目录。【免费下载链接】GhostIndependent technology for modern publishing, memberships, subscriptions and newsletters.项目地址: https://gitcode.com/GitHub_Trending/gh/Ghost创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
