数据库客户端后端前端CLI桌面应用数据可视化AI 应用【免费下载链接】whodbWhere data access meets operational intelligence项目地址https://gitcode.com/gh_mirrors/wh/whodb点击查看免费下载WhoDB 是一个将数据访问与运维智能结合的开源项目其社区版CE与平台 SDK 的自动化构建、测试和多平台发布全部依托 GitHub Actions 完成。本文以仓库内 .agents/docs/ci-cd.md 为骨架结合 .github/workflows、.github/actions 与 .github/scripts 中的真实工作流实现完整拆解 WhoDB 的 CI/CD 体系从 PR 质量门禁、跨数据库 E2E 测试到一次触发即可同时发布 Docker Hub、Snap Store、Microsoft Store、Apple App Store 与 Linux 终端二进制的统一发布编排器。读完本文你将理解 WhoDB 如何用一次计算版本 可复用工作流矩阵 按需启用的商店选择完成复杂的多平台交付并能复用到自己的项目中。一、工作流总体结构与分层设计WhoDB 的 CI/CD 目录采用主编排器 可复用工作流 共享 Action 脚本/模板的四层结构.github/workflows/ lint-check.yml # PR 门禁Go 前端的 lint / typecheck / 测试 e2e-ce.yml # CE 端到端测试数据库矩阵 CLI 后端集成 security.yml # CE 安全扫描gosec / govulncheck / pnpm audit / Trivy release-ce.yml # CE 主发布编排器 _build-*.yml # 可复用构建工作流由 release 调用 _deploy-*.yml # 可复用部署工作流 _sign-validate.yml # 代码签名与产物校验 .github/actions/ calculate-version/ # 语义化版本计算 deployment-summary/ # 发布摘要生成 install-go-tools/ # Go 工具链安装 .github/scripts/ appstore-connect.sh # Apple App Store Connect API 封装 .github/templates/ RELEASE_TEMPLATE.md # GitHub Release 说明模板 AppxManifest.xml.template / entitlements.mas.plist / Info.document-types.plist关键设计约定所有可复用工作流统一以_前缀命名如 _build-docker.yml、_deploy-apple.yml表明它们只能通过workflow_call被其他工作流调用不可独立运行主编排器为 CE 的release-ce.yml与 EE 的release-ee.yml。这套约定同样记录在配套的 .agents/rules/ci-cd.md 规则文件中。二、PR 质量门禁lint-check.ymllint-check.yml 是合并 PR 前的第一道闸门在pull_request、pushmain/release 分支和手动触发时运行顶层权限收敛为contents: read。它通过一组并行 job 覆盖全部代码栈Job职责go-lint/cli-lint用 golangci-lint 分别检查core与cli两个 Go 模块core 使用自定义构建的 golangci-lintgolangci-lint customCLI 使用.golangci.yml配置go-vet/go-build对 core 执行go vet与go build ./cmd/whodbgo-testcore 单元测试go test -race -count10 ./src/... ./graph/...通过-count10放大竞态检测概率cli-testCLI 模块单元测试./cmd/... ./internal/... ./pkg/...frontend-build/frontend-lint前端pnpm build:ce、pnpm lint、pnpm typechecksdk-check一个全家桶 jobTS/Python/Go/Rust/Java 五种 SDK 的 lint、build、test、conformance以及生成物漂移门禁——node tools/generate-core.mjs --check强制提交的生成代码与 spec 快照完全一致node tools/sync-versions.mjs --check强制各语言包版本号保持 lockstep值得注意的细节sdk-check中对 Python 依赖使用python3 -m pip install --user -e sdk/packages/python[dev]注释明确说明这是为了让pyproject.toml成为版本唯一事实源对 Rust 还做了MSRV最小支持 Rust 版本检查——直接从Cargo.toml的rust_version读取并安装对应工具链编译防止依赖升级悄悄抬高版本下限。三、E2E 与安全e2e-ce.yml 与 security.yml3.1 跨数据库端到端测试e2e-ce.yml 采用一次编译、矩阵执行、报告合并的流水线策略resolve-matrix动态解析数据库矩阵。默认覆盖 postgres、mysql、mariadb、tidb、sqlite、duckdb、mongodb、redis、elasticsearch、cockroachdb、clickhouse、memcached、valkey、dragonfly、opensearch、yugabytedb、questdb、ferretdb 等数据库也支持通过databases输入参数传入逗号分隔列表精确控制。build先用go test -coverpkg./... -c -o server.test ./cmd/whodb把 CE 测试编译成单一二进制上传为 artifact避免每个数据库 runner 重复编译。e2e 矩阵每个数据库一个独立 runnerfail-fast: false保证单个数据库失败不影响其他下载测试二进制后以pnpm e2e:db:headless db跑 Playwright 测试并分别上传 blob 报告、日志与失败产物。merge-reports用playwright merge-reports把所有数据库的 blob 报告合并成一份 HTML 报告并在 Step Summary 中输出每库的通过/失败统计与最近失败详情。此外该工作流还并行运行 CLI 测试dev/run-cli-tests.sh --skip-ee -v、后端集成测试dev/run-backend-tests.sh ce-integration和 SSL 集成测试dev/run-backend-tests.sh ssl失败时通过docker compose logs --tail200转储容器日志辅助排障。3.2 安全扫描security.yml 在 PR、每周一 06:00 定时及手动触发时执行Gitleaks扫描泄露的密钥gosec对core做 Go 静态安全分析排除生成代码govulncheck检查 Go 依赖已知漏洞pnpm audit审计前端依赖最终由一段 Python 脚本把三类结果合并生成 Markdown 报告上传为 artifact另有trivy-imagejob 在定时/手动时对clidey/whodb与clidey/whodb-cli镜像做 CRITICAL/HIGH 级别的容器镜像扫描。四、发布编排器release-ce.yml 详解release-ce.yml 是整个 CI/CD 体系的核心文件头部的注释即是一份完整的产物契约artifact contractfrontend-build-ce喂养所有 CE 平台构建snap-package-*喂养 Snap 发布desktop-windows-amd64喂养微软打包desktop-darwin-*喂养苹果签名server-binaries-ce与cli-binaries分别喂养 Linux 终端发布与 npm 发布signatures喂养最终 Release 资产。4.1 触发方式Push 到release分支自动触发等效于生产发布 minor 版本递增且自动勾选所有商店目标workflow_dispatch手动触发提供细粒度控制见下方参数表。4.2 部署模式与版本递增deployment-mode决定目标渠道模式Docker HubSnap StoreMicrosoft StoreApple App Storestage-only仅vX.Y.Z版本标签edge 通道draft 草稿提交TestFlightproductionlatest标签stable 通道正式提交认证App Store 审核version-bump支持四种递增方式默认minormajor1.0.0 → 2.0.0、minor0.61.0 → 0.62.0、patch0.61.0 → 0.61.1、current不递增、原地重建另有explicit-version输入可完全绕过递增逻辑直接指定X.Y.Z。4.3 手动触发的完整输入参数输入默认值说明deployment-modestage-only选择stage-only或productionversion-bumpminormajor / minor / patch / currentexplicit-version空例如0.65.0设置后覆盖 version-bumpdeploy-docker/deploy-snap/deploy-microsoft/deploy-applefalse是否发布到对应商店deploy-linux-terminalfalse构建 Linux 终端二进制amd64、arm64、riscv64、armv6、armv7deploy-cli/deploy-npmfalse构建 CLI 二进制并发布clidey/whodb-cli到 npmdeploy-sdkfalse发布平台 SDKnpm / PyPI / crates.io / Maven / Go module tagpublish-github-releasefalse把 GitHub Release 从草稿转为公开仅在 production 模式生效stage-only 会强制覆盖为 false手动触发时若一个商店都没勾选release_flags步骤会直接报错Select at least one release target: Docker, Snap, Microsoft, Apple, Linux Terminal, CLI, npm, or SDK.4.4 发布执行的完整链路发布编排器按依赖关系依次执行calculate-version算出版本号并广播给所有下游→build-frontend前端只构建一次供所有平台复用→ 各build-*平台构建并行→sign-and-validate统一签名 校验→ 各deploy-*部署 →create-github-release最终发布闸门→deployment-summary汇总报告。create-github-release有一个非常严谨的不可变 Release 策略先用ncipollo/release-action创建草稿并上传全部资产draft: true随后Verify and publish步骤通过gh release view逐项核对.snap、.exe、.msixbundle、.dmg、whodb-*-linux-*、whodb-cli-*、签名.bundle等资产数量是否符合预期再检查发布正文长度最后才gh release edit --draftfalse正式发布——因为不可变 Release 发布后无法再追加资产。SDK 的发布还带有专门的sdk-release-gate闸门由于 npm/PyPI/crates.io/Maven 发布不可逆同一版本号无法重发该闸门要求所有选中的应用构建与部署全部成功后才允许 SDK 发布避免注册表里有了版本、应用却没发出去的错位PyPI 与 crates.io 的发布 job 故意内联在顶层工作流中而非可复用工作流因为 PyPI 可信发布Trusted Publishing的 OIDC 证书会校验顶层工作流文件名用workflow_call会同时破坏 token 验证与证书命名。Go SDK 则通过推送sdk/packages/go/vX.Y.Z子目录模块标签实现发布且必须等 npm/PyPI 都成功后执行保证各注册表版本一致。五、自定义 Action版本计算与部署摘要5.1 calculate-versioncalculate-version 是复合 Actioncomposite逻辑分三步确定模式从输入读取 deployment-mode设置标志stage-only 模式下强制publish-github-releasefalse永远只出草稿计算版本git tag列出所有标签sed s/^v//去掉v前缀后用正则^[0-9]\.[0-9]\.[0-9]$过滤——这一过滤至关重要避免把sdk/packages/go/v0.128.0这类子目录模块标签误当成最新发布版本再按major/minor/patch/current递增若传入explicit-version则先做格式校验必须匹配X.Y.Z校验失败立即退出。该 Action 输出version、previous-version、deployment-mode、stage-only以及全部deploy-*标志供release-ce.yml中所有下游 job 通过needs.calculate-version.outputs.xxx消费。5.2 deployment-summarydeployment-summary 接收版本号与各构建/部署结果生成包含构建状态表、部署状态表、附加状态验证/回滚和快捷链接的 Markdown 摘要写入GITHUB_STEP_SUMMARY。release-ce.yml 末尾还有一个内联版本的deployment-summaryjob输出更细粒度的表格每个商店一行含成功/跳过/失败原因并给出 stage 模式下的后续行动指引测试 edge/draft 产物、Snap edge→stable 提升、微软草稿提交认证、Apple TestFlight 转审核、发布 GitHub 草稿。六、可复用构建工作流所有_build-*工作流都通过workflow_call接收version输入并约定从frontend-build-ceartifact 下载前端产物_build-docker.yml源码 用矩阵在ubuntu-latestlinux/amd64与ubuntu-24.04-armlinux/arm64 原生 ARM runner上构建只构建不推送通过typegha,scopece-docker-arch写入 GHA buildx 缓存同时生成 Trivy SARIF 报告上传 GitHub Security tab。_build-apple.yml源码 在macos-latest上分别构建 DMG直下载版与 MASApp Store 版变体产出 universal binaryIntel Apple Silicon完整演示了 Apple 证书导入临时 keychain、set-key-partition-list授权 codesign、Wails 工具链缓存、BAML 原生 dylib 按架构下载打包、codesign由内向外签名dylib/框架 → 可执行文件 → 应用束刻意不用--deep以及notarytool公证 stapler装订失败时指数退避重试。_build-windows.yml构建 Windows AMD64 桌面可执行文件用于微软打包。_build-snap.yml在 amd64/arm64 双架构上构建 Snap 包设置SNAPCRAFT_PROJECT_VERSION与实验性扩展环境变量。_build-linux-terminal.yml源码 在ubuntu-latest上安装gcc-aarch64-linux-gnu、gcc-riscv64-linux-gnu、gcc-arm-linux-gnueabihf交叉编译链调用desktop-ce的make server-all VERSION...产出amd64、arm64、riscv64、armv6armv7五种无 GUI 的独立服务器二进制whodb-*-linux-*。该 job 的 CI 失败是平台构建标签问题的最早哨兵。七、部署工作流与签名校验_deploy-docker.yml源码 从 buildx 缓存重建镜像并push: true开启sbom: true与provenance: modemax生成软件物料清单与构建溯源随后docker buildx imagetools create合成多架构 manifeststage-only 只推vX.Y.Zproduction 额外更新latest最后用cosign sign对镜像签名Sigstore 生态。_deploy-apple.yml下载已签名的 MAS 应用束用productbuild打成签名 PKG通过 App Store Connect API.github/scripts/appstore-connect.sh 负责 JWT ES256 签发与六步提交查 app ID → 建/复用版本 → 等构建处理 → 关联构建 → 写 release notes → 提交审核stage-only 走 TestFlight 且continue-on-error。_deploy-microsoft.yml在 Windows runner 上先用makeappx生成 x64可选 arm64MSIX 包并合成.msixbundle再用 StoreBroker PowerShell 模块克隆最新提交、替换包文件、上传stage-only 留草稿、production 直接Complete-ApplicationSubmission提交认证。_deploy-snap.yml通过snapcraft upload --release channel分别发布 amd64/arm64 包到 edgestage或 stableproduction通道缺少凭据时仅稳定通道会硬性失败。_deploy-npm.yml利用 npm Trusted PublisherOIDCid-token: write发布clidey/whodb-cli各平台包无需长期令牌。_sign-validate.yml源码 对所有.snap/.exe/.dmg/.pkg/.msix/.msixbundle/whodb-*-linux-*产物执行cosign sign-blob --bundle生成 Sigstore 签名束打包为signatures.tar.gz随后校验 Snap 文件名版本号、Windows/macOS 桌面产物存在性、Linux 四架构二进制齐全并产出validation_manifest.json。八、平台构建标签ARM / RISC-V64 的降级策略WhoDB 的部分 CE 功能依赖 CGO 库或平台专属绑定最典型的是 BAML AI 客户端在 ARM 与 RISC-V64 上不可用。对此项目采用Go build tags 双文件模式每个带//go:build !arm !riscv64的文件必须存在一个同名的_unsupported.go存根文件带//go:build arm || riscv64导出完全相同的函数签名但返回 HTTP 501 或 no-op现有示例为 core/graph/http_ai_stream_handler.go!arm !riscv64与 core/graph/http_ai_stream_unsupported.goarm || riscv64后者在 armv7 上让 AI 流式功能返回友好错误core/graph/graphql_chat_title.go 与 core/graph/graphql_chat_title_unsupported.go 同理处理函数的注册调用必须放在无条件编译的代码中如SetupHTTPServer否则所有平台都会缺符号版式/插件add-on路由不得往 CE 里塞存根而应由插件包通过graph.RegisterHTTPRoutes自行注册参见 .agents/workflows/platform-constrained-handler.md 的完整操作流程验证方式GOOSlinux GOARCHriscv64 go build ./graph/与GOOSlinux GOARCHarm GOARM7 go build ./graph/必须通过否则 Build Linux Binaries job 必然失败。此外_build-linux-terminal.yml在构建前还会给core/baml_client及其子包的所有.go文件补上//go:build !arm !riscv64头已带 build tag 的跳过从源头把 BAML 客户端排除在 ARM/RISC-V64 构建之外让服务器在非 AI 功能上仍然可用。九、环境 Secrets 与安全基线仓库内不检入任何密钥。所有敏感凭据通过 GitHub Environment 级 secrets 注入各 job 声明了environment: permission-required/deploy-*环境做访问保护涉及的关键 secret 包括DOCKERHUB_USERNAME/DOCKERHUB_TOKEN、SNAPCRAFT_STORE_CREDENTIALS、MS_TENANT_ID/MS_CLIENT_ID/MS_CLIENT_SECRET/MS_APP_ID、APPLE_*系列证书 P12、App Store Connect API Key、公证凭据、CENTRAL_USERNAME/CENTRAL_PASSWORD/GPG_PRIVATE_KEYMaven Central等。工作流文件本身如 release-ce.yml是 secret 引用的可执行事实源任何 secret 引用变更都应回到工作流中核对。安全基线贯穿所有工作流每个 job 第一步都是step-security/harden-runner大部分采用egress-policy: block加显式白名单如 Apple 构建的 allowed-endpoints 列表详尽到 Apple 的几十个域名/IP所有第三方 Action 均固定到 SHA 提交并附版本注释如# v7.0.0杜绝 tag 漂移权限遵循最小化原则顶层声明permissions: contents: read仅个别 job 按需追加id-token: write、actions: write等Docker 镜像推送附带 SBOM 与 provenance 溯源并用 Cosign 签名文件资产用 Sigstore bundle 签名发布前还会校验签名束完整性。十、如何实际运行一次发布10.1 测试发布stage-only打开 GitHub Actions → 选择Release CE选择deployment-mode: stage-only默认version-bump按需选择 minor/patch勾选需要测试的商店如仅deploy-snapdeploy-apple运行工作流。产物会进入Docker 版本标签、Snap edge、MS Store 草稿、Apple TestFlightGitHub Release 保持草稿。10.2 生产发布将代码合并到release分支自动触发等效 production minor 全商店或者手动 dispatch 并选择deployment-mode: production按需勾选商店与publish-github-release勾选publish-github-release后工作流会在全部构建、签名、部署成功后将带全部资产的 GitHub Release 从草稿转为公开。生产发布完成后需关注微软认证状态与苹果审核状态若个别平台失败可在 Actions 页面对失败 job 使用Re-run failed jobs重跑。小结WhoDB 的 CI/CD 体系可以概括为三个关键词分层复用主编排器 _前缀可复用工作流、单一事实源calculate-version一次算出版本并广播给所有下游、发布即校验签名 资产清单校验 不可变 Release 草稿转正 SDK 闸门。对于需要跨桌面商店、容器注册表与多语言 SDK 同时交付的项目这份 .agents/docs/ci-cd.md 及其工作流实现是一份高完整度的工程范本。赞分享数据库客户端后端前端CLI桌面应用数据可视化AI 应用【免费下载链接】whodbWhere data access meets operational intelligence项目地址https://gitcode.com/gh_mirrors/wh/whodb点击查看免费下载相关推荐WhoDB 的 GitHub Actions CI/CD 体系从发布编排、多平台构建到 ARM/RISC-V64 构建标签规则WhoDB 的 GitHub Actions CI/CD 体系从发布编排、多平台构建到 ARM/RISC V64 构建标签规则 WhoDB 以 GitHub数据库客户端后端前端CLI桌面应用数据可视化AI 应用3分钟彻底告别激活烦恼KMS智能激活脚本完全指南3分钟彻底告别激活烦恼KMS智能激活脚本完全指南 你是否曾经遇到过这样的尴尬时刻在准备重要演示的前一刻Office突然弹出产品未激活的警告或者每次开运维privacy.sexy 的 CI/CD 与 GitOps 实践GitHub Actions 流水线架构、命名约定与发布流程深度解析privacy.sexy 的 CI/CD 与 GitOps 实践GitHub Actions 流水线架构、命名约定与发布流程深度解析 本文基于 docs/ci应用安全上一篇RainLoop Webmail打造极速现代的开源Web邮件客户端终极指南下一篇深度拆解LLMDet-Swin-Tiny-HF模型结构GroundingDino与BERT如何协同工作创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考