Dashy 发布工作流与 CI/CD 自动化全解：版本管理、GitHub Actions 与 Git 协作规范-北京尧图网络

Dashy 发布工作流与 CI/CD 自动化全解版本管理、GitHub Actions 与 Git 协作规范【免费下载链接】dashy A self-hostable personal dashboard built for you. Includes status-checking, widgets, themes, icon packs, a UI editor and tons more!项目地址: https://gitcode.com/GitHub_Trending/da/dashyDashy 是一款可自托管的个人仪表盘personal dashboard其发布流程并非简单的手动打 Tag而是一套由 GitHub Actions 驱动的半自动化流水线PR 合并后自动 bump 版本号、自动打 Tag、自动构建并发布多架构 Docker 镜像、自动起草 GitHub Release同时通过多级 CI 检查与文档同步机制保障质量。本文以 docs/release-workflow.md 为骨架结合仓库内真实的工作流文件.github/workflows逐层拆解其版本化策略、六大自动化工作流的内部实现与 Git 协作约定。读完本文你将能完整理解 Dashy 的发布链路并可直接借鉴其思路为自己的开源项目搭建类似的自动化发布体系。一、版本化与发布总览Dashy 的版本发布遵循一条清晰的自动化链路核心思路是以 PR 合并为起点以 Git Tag 为枢纽向下游驱动 Docker 镜像发布与 Release 草稿。其高层流程可概括为所有新功能、修复与更新都通过 Pull Request 合入master分支PR 合并后package.json中的version会被自动 bump 一个patch值除非该 PR 已经手动更新过版本号只要version发生变化就会自动创建并推送一个新的 Git Tag同时触发 Docker 镜像 Tag 的创建与推送如果 bump 的是major 或 minor版本而非 patch还会额外起草一份 GitHub Release。这套打 Tag 流程由 GitHub Actions 工作流 tag.yml 管理。该工作流也支持维护者手动触发既可以显式指定一个版本号也可以留空以自动 bump patch 版本。1.1 创建 Release 的两种方式只有仓库维护者maintainer可以发布 Release。实际发布通常由 Tag 工作流在 major/minor 版本更新时自动触发但也可以通过 release.yml 的workflow_dispatch手动调度传入一个已存在但尚未发布的 Tag 版本号来手动触发。需要特别注意的是机器人只会创建Draft Release草稿维护者需要进入 Releases 标签页检查内容无误后手动点击Publish完成正式发布。1.2 版本规则语义化版本Dashy 采用语义化版本Semantic Versioning的变体形式当前仓库package.json中的版本为4.6.5其节奏为通常每周多个 patch 版本、每两周一个 minor 版本、每季度一个 major 版本。版本类型示例触发场景Patch4.6.9每次代码变更合并后自动发布Minor4.7.0一组功能特性集中发布Major5.0.0大型版本可能不向后兼容这一约定与 tag.yml 中的实现互相印证工作流默认执行npm version patch --no-git-tag-version完成 patch bump而手动调度时则允许传入完整的X.Y.Z版本号。1.3 Changelog 与更新记录Dashy 的变更记录由 Release 工作流自动生成见下文 Release 一节其 release notes 会与上一个X.Y.0Tag 做 diff 对比因此维护者无需手工编写 Changelog。此外每次 Tag 创建后Tag 工作流还会通过DOCS_SITE_REBUILD_HOOK秘密变量触发文档站点的重建tag.yml保证线上的更新记录始终与最新版本同步。二、六大自动化工作流逐层拆解Dashy 在 .github/workflows 目录下维护了多套 GitHub Actions 工作流除本文核心的六套外还包括close-stale-issues.yml、wiki-sync.yml等辅助流程。下面按文档顺序逐一拆解核心六套工作流。2.1 CIPR 质量闸门目标在 Pull Request 上运行检查尽早捕获明显或关键的问题。CI 工作流 ci.yml 会针对 PR 运行一系列检查。它首先通过dorny/paths-filter做路径过滤path-filter判断哪些文件发生了变化从而让大多数检查只在相关文件被修改时运行其余检查直接跳过以节省 CI 资源。具体检查项如下检查项工具/方式触发条件LintESLintyarn lint源码或配置变更Typecheckvue-tscyarn typecheck任何代码或配置变更TestVitest 单元测试套件yarn test每个 PRLocale check自研脚本yarn validate-locales语言或 locale 内容src/assets/locales更新Spellcheckcrate-ci/typos英文语言包en.json更新Build checkyarn build并校验dist产物每个 PRDocker smoke testdocker-smoke-test.sh每个 PRDependency auditactions/dependency-review-actionfail-on-severity: moderateyarn.lock变更Secret scanningTruffleHog--only-verified每个 PRWorkflow auditactionlint zizmor工作流文件变更.github/workflows/**源码级细节Locale check使用仓库自研脚本 tests/locales/check-locales.js。该脚本会扫描src下的所有.vue/.js文件中的翻译调用$t、$tc、i18n.t等然后与src/assets/locales下的 JSON 语言包做交叉校验语言文件必须合法可解析、必须在 src/utils/languages.js 中注册、代码中使用的翻译 key 必须存在于en.json缺失会失败并输出各语言相对en.json的覆盖率报告。其中en.json被视为最关键的源语言因为缺失的翻译会回退到英文。Docker smoke test脚本 tests/docker-smoke-test.sh 会真实地docker build镜像、启动容器并依次验证关键端点首页返回title、/conf.yml返回配置、/system-info返回meta、POST/config-manager/save保存配置后能读回、/cors-proxy无参数时返回 400、/status-check返回预期结构最后检查容器日志中不存在崩溃特征签名如UnhandledPromiseRejection、FATAL ERROR。continue-on-error: true意味着该检查失败不会阻断合并而是作为警告提示。Workflow audit使用 actionlint 对工作流文件做语法与静态检查再使用 zizmor 做安全审计扫描危险触发器等安全隐患——这与 tag.yml 中出现的zizmor: ignore[dangerous-triggers]注释相呼应。所有检查完成后summaryjob 会将各检查结果渲染成一张 Markdown 汇总表写入 job summary。工作流文件ci.yml触发条件Pull Request针对master/develop分支打开或更新也支持手动调度输入参数无输出无各 job 的状态汇总2.2 Docker多架构镜像构建与发布目标构建并发布 Docker 镜像。Docker 工作流 docker.yml 使用仓库根目录的 Dockerfile 构建镜像。其核心特征多架构构建通过矩阵matrix在原生 runner 上并行构建linux/amd64与linux/arm64两个平台arm64 使用ubuntu-24.04-armrunner最后在mergejob 中用docker buildx imagetools create合并为多架构 manifest。双仓库发布镜像同时发布到 GHCRghcr.io/owner/dashy与 Docker Hublissy93/dashy通过DOCKER_USERNAME/DOCKER_PASSWORD变量/秘密配置未配置时跳过。Trivy 安全扫描每次构建后用 Trivy 以CRITICAL严重级别扫描漏洞ignore-unfixed: trueSARIF 结果上传到 GitHub 安全扫描当定时任务schedule触发时若存在 CRITICAL 漏洞则以退出码 1 使任务失败并在 job summary 中打印可读的漏洞表格。供应链安全为镜像附加SBOMSPDX 格式与build provenance构建来源证明认证actions/attest、actions/attest-build-provenance随镜像一同发布到 GHCR。Docker Tag 计算基于 Dockerfile 与事件类型动态计算docker/metadata-action生成latest手动触发或定时任务、{{version}}、{{major}}.{{minor}}、{{major}}.x等语义化 Tag。Dockerfile 本身是典型的多阶段构建build阶段基于node:24-alpine执行yarn install与yarn builddeps阶段仅安装生产依赖yarn install --production并清理缓存最终运行阶段只复制node_modules、dist、public、services、ConfigSchema.json、server.js、package.json与默认conf.yml以node用户运行USER node通过tini作为 PID 1 入口ENTRYPOINT [/sbin/tini, --]并声明HEALTHCHECK调用node services/healthcheck.js。同时构建时传入的VERSION、REVISION、CREATED会被写入 OCI labelsorg.opencontainers.image.*实现镜像元数据的可追溯性。工作流文件docker.yml触发条件Tag 推送、每周定时任务cron0 4 * * 0、手动调度输入参数Tag可选手动调度时指定留空则按当前 ref 构建latest输出多架构镜像SHA、manifest、digest、SBOM、构建来源认证2.3 Release打包并起草 Release目标构建应用并连同打包好的 tarball 起草一份 GitHub Release。Release 工作流 release.yml 由major/minorX.Y.0Tag 推送或对已存在 Tag 的手动调度触发。其执行步骤检出对应 Tagref: refs/tags/TAGfetch-depth: 0以便对比历史安装依赖并执行yarn build --mode production构建生产产物打包发布 tarball将dist、services、public、user-data、server.js、yarn.lock、src/utils/config/ConfigSchema.json以及去掉devDependencies的package.json打包为dashy-TAG.tar.gz——即构建产物运行所需服务端文件的完整可运行包生成SHA256 校验和sha256sum生成SLSA 构建来源认证actions/attest-build-provenance并将认证 bundle 重命名为tarball.intoto.jsonl作为附件查找上一个X.Y.0Tag用softprops/action-gh-release创建草稿 Release启用generate_release_notes: true自动生成 release notes与上一个 minor/major Tag 做 diffdraft: true表示只起草不发布prerelease: false将 tarball、SHA256 文件与 provenance 认证文件一并上传为 Release 资产。工作流文件release.yml触发条件major/minor Tag 推送*.*.0、手动调度输入参数Tag手动调度必填必须是已存在的 Git Tag输出Draft Release、发布 tarball、SHA256 校验和、SLSA 来源认证2.4 Tag版本 bump 与 Tag 推送目标bump 版本号并推送新的 Git Tag。这是整条发布链路的发动机。Tag 工作流 tag.yml 是流程中逻辑最复杂的一环其内部实现值得仔细拆解触发方式PR 合入masterpull_request_targettypes: [closed]且要求merged true或手动调度。工作流使用concurrency组auto-version-and-tag且cancel-in-progress: false避免并发打 Tag 冲突。代码变更检测check_pr job通过 GitHub API 分页拉取 PR 的文件列表用正则模式/^src\//、/^services\//、/^public\//、/^Dockerfile$/、/^yarn.lock$/、根目录.js文件判断 PR 是否包含代码变更若仅改动文档、测试等非代码文件则直接跳过needs_tagfalse。版本 bump 检测如果 PR 修改了package.json工作流会比较 PR 合并提交与其父提交两个 ref 上package.json中的version判断 PR 是否已自行 bump 版本。若代码有变更但版本未变则执行npm version patch --no-git-tag-version自动 bump patch 并提交 Bump version to v手动调度时若传入版本则执行npm version version --no-git-tag-version --allow-same-version且会先校验版本号必须匹配^[0-9]\.[0-9]\.[0-9]$的 semver 格式并限定只允许从master分支手动触发。Tag 创建以Liss-Bot身份liss-botd0h.co创建附注 Tagannotated tagTag 消息包含版本号、对应 PR 编号与标题、解析的 issue 编号、作者与 commit SHA若 Tag 已存在则跳过。随后git push origin version推送 Tag——正是这次推送触发了下游的 Docker 与 Release 工作流。Issue 标记与评论解析 PR 描述中的#数字issue 引用Dependabot 的 PR 除外为这些 issue 添加️ Released version与✅ Fixed标签并自动评论告知 issue 提交者该需求已在 # 实现将随 v 发布评论带released-version标记避免重复评论。整个 job 还会在 step summary 中输出详细的执行报告表。工作流文件tag.yml触发条件PR 合入master、手动调度输入参数版本号可选留空则自动 bump patch输出版本 bump 提交、Git Tag、issue 标签与评论2.5 Mirror仓库镜像同步目标将仓库完整镜像到 Codeberg避免项目被单一平台绑定。Mirror 工作流 mirror.yml 每周cron30 3 * * 0即周日 03:30 UTC通过镜像 action 将仓库完整推送至 Codeberg 镜像force_push: false同时支持手动调度。该工作流也承担代码托管去中心化的韧性目标。工作流文件mirror.yml触发条件每周定时任务、手动调度输入参数无输出无保持镜像仓库同步2.6 Docs文档站点同步目标保持文档站点与 GitHub Wiki 与/docs目录同步。文档同步工作流 update-docs-site.yml 将 master 分支上的 docs 目录镜像到WEBSITE/docs-site-source分支在那里通过 Python 脚本do-doc-updaty-magic.py处理后由 Docusaurus 站点重建并部署。触发条件是docs/**路径的推送、每周定时任务或手动调度。也就是说你在 docs 目录中看到的这篇 release-workflow.md正是该流水线的输入源。工作流文件update-docs-site.yml触发条件master 上docs/**推送、每周定时任务、手动调度输入参数无输出更新后的WEBSITE/docs-site-source分支文档三、六套工作流的联动时序将上述工作流串联起来一次典型的 minor 版本发布在时间轴上大致如下开发者将功能 PR 合入masterCIci.yml已在 PR 打开/更新时完成 lint、typecheck、test、build、docker-smoke 等全部检查Tagtag.yml在 PR 合并后检测到代码变更但版本未变自动npm version patch或识别 PR 自带的版本 bump如4.6.5→4.7.0创建并推送 Git TagTag 推送触发Dockerdocker.yml构建多架构镜像并发布到 GHCR / Docker Hub自动带4.7.0、4.7、4.x等 Tag若 Tag 符合X.Y.0模式同时触发Releaserelease.yml打包 tarball、生成 SHA256 与 SLSA 认证起草 Draft ReleaseTag 工作流同时为 PR 中引用的 issue 打标签、评论并触发文档站点重建Mirrormirror.yml与Docsupdate-docs-site.yml则分别在每周与每次文档变更时保持镜像与文档站点的同步维护者进入 Releases 页审核草稿点击Publish完成发布。值得注意的是这一链路的设计刻意将自动打 Tag/构建镜像与人工发布 Release分离——Tag 与镜像发布是全自动的但 Release 的正式公开始终保留一道人工审核闸门兼顾了自动化效率与发布质量。四、Git 协作策略4.1 Commit 规范gitmojiDashy 使用 gitmoji 作为提交信息约定每条 commit message 以表示变更类型的 emoji 开头。这一约定在 Tag 工作流的自动化提交中也能看到如 Bump version to v保持了人工与机器人提交风格的一致性。4.2 分支命名规范大多数分支以类型简短描述命名例如feat/adds-awesome-feature—— 新功能ref/language-deduplication—— 重构fix/resolves-missing-icons—— 缺陷修复。4.3 Pull Request 流程GitHub FlowDashy 遵循 GitHub Flow 标准协作模型创建分支无写权限的贡献者先 fork编写代码add 与 commit 变更创建 Pull Request填写 PR 模板模板见 .github/pull_request_template.md跟进评审意见并修改合并完成。值得强调的是PR 模板与 issue 模板.github/ISSUE_TEMPLATE的规范填写并非形式主义——Tag 工作流会解析 PR 描述中的#issue引用来自动标记已解决的 issue模板的规范性直接决定了这套自动化能否正确运行。五、总结与可借鉴要点Dashy 的发布体系可以提炼为几个清晰的设计决策非常适合自托管/开源项目参考以 Git Tag 为单一事实源single source of truth版本号只维护在package.jsonTag 推送统一驱动 Docker 与 Release 两个下游流水线避免多处重复配置版本信息CI 按变更范围分级运行通过路径过滤只运行受影响的检查既保证质量又控制成本自动化的边界清晰打 Tag、构建镜像、起草 Release 全部自动化但正式发布保留人工审核供应链安全SBOM、provenance、Trivy、依赖审计、密钥扫描贯穿始终机器人身份与会话安全自动化提交统一使用Liss-Bot身份工作流通过 zizmor 审计如pull_request_target触发器的使用规避权限提升风险去中心化与文档联动定期镜像到 Codeberg、文档目录即文档站点的数据源形成代码-文档-发布三位一体的维护闭环。对于希望复刻这套体系的读者可直接以 tag.yml、ci.yml、docker.yml 与 release.yml 四个文件为起点结合 docs/release-workflow.md 的流程说明与 Dockerfile 的多阶段构建实践按自身项目的规模裁剪检查项与触发条件即可落地。【免费下载链接】dashy A self-hostable personal dashboard built for you. Includes status-checking, widgets, themes, icon packs, a UI editor and tons more!项目地址: https://gitcode.com/GitHub_Trending/da/dashy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Dashy 发布工作流与 CI/CD 自动化全解：版本管理、GitHub Actions 与 Git 协作规范

相关推荐

Upscayl 完整指南：免费 AI 图片放大，3 分钟上手

Python轻量级股票舆情监控系统：爬取+情感分析+PDF报告

CopilotKit CrewAI Conversational Flows 多模态附件 QA 指南：图片与 PDF 的端到端验证

更多资讯

欧美一氧化碳报警器市场准入与合规指南

Zulip 开发环境 WSL 重建指南：从注销发行版到快速重建数据库

三菱PLC与触摸屏构建智能停车场管理系统

Data-Science-For-Beginners 实战：用 Vue.js 与 D3 构建《危险关系》书信社交网络可视化

Android开发中常见安全问题和解决方案

core-js 中的 RegExp.escape 完全指南：TC39 正则转义提案的 API 签名、源码实现与工程实践

今日更新

SpacetimeDB C++ 模块库实战：用 C++20 在数据库内构建 WebAssembly 模块

别踩雷！不是所有 AI 写作工具都靠谱，2026 高校认可工具精选

SSM+MySQL幼儿园管理系统源码解析：从部署到优化

本周精选

超人会飞不算本事：系统稳定依赖清晰规则与边界设计

超人VS蜘蛛侠：拆解超级IP的影响力与传播方法论

基于CNN的调制信号识别：MATLAB实现时频图分类实战

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？