ARTICLE DETAIL

资讯详情

深耕商务建站与企业官网运营的一线实战洞察。

完整指南:action-wordpress-plugin-deploy核心脚本deploy.sh深度解析——SVN检出、rsync同步与Tag提交

完整指南:action-wordpress-plugin-deploy核心脚本deploy.sh深度解析——SVN检出、rsync同步与Tag提交 完整指南action-wordpress-plugin-deploy核心脚本deploy.sh深度解析——SVN检出、rsync同步与Tag提交【免费下载链接】action-wordpress-plugin-deployDeploy your plugin to the WordPress.org repository using GitHub Actions项目地址: https://gitcode.com/gh_mirrors/ac/action-wordpress-plugin-deployaction-wordpress-plugin-deploy是一个面向 WordPress 插件部署的 GitHub Actions 工具它能把你的 Git 标签内容自动提交到 WordPress.org 插件仓库。本文带你完整剖析它的核心脚本deploy.sh看懂 SVN 检出、rsync 同步与 Tag 提交三大关键环节让你像老手一样掌控整个自动发布流程。它到底解决什么问题WordPress.org 的插件仓库使用的是SVN而绝大多数插件开发都在Git里进行。两套版本管理系统如何衔接一直是 WordPress 插件开发者的痛点。这个项目用一段不到 240 行的 Bash 脚本 deploy.sh 把整件事自动化了环节工具作用拉取远程仓库SVN检出 WordPress.org 插件仓库同步文件rsync把插件文件干净地拷入trunk发布版本SVN复制trunk为tags/版本号并提交第 1 步环境准备与参数解析脚本开头deploy.sh#L7使用set -eo保证出错即停。随后它会检查并自动安装 SVNdeploy.sh#L15-L33校验SVN_USERNAME/SVN_PASSWORD两个密钥非 dry-run 模式下缺失则直接退出解析常用变量SLUG默认取仓库名deploy.sh#L65-L67VERSION默认从refs/tags/中提取并去掉v前缀deploy.sh#L71-L74BUILD_DIR指定构建产物目录deploy.sh#L82-L93 版本号直接来自 Git 标签名所以打 tag 就是发版——这是理解整个流程的钥匙。第 2 步SVN 检出 WordPress.org 仓库核心代码在 deploy.sh#L95-L104SVN_URLhttps://plugins.svn.wordpress.org/${SLUG}/ svn checkout --depth immediates $SVN_URL $SVN_DIR svn update --set-depth infinity assets svn update --set-depth infinity trunk svn update --set-depth immediates tags这里用了一个非常巧妙的分层检出策略assets和trunk完整下载infinity因为文件要同步进去tags只下载目录层级immediates只为检查某个版本是否已存在这样既省流量又保留完整判断能力。如果tags/$VERSION已存在脚本会提前退出deploy.sh#L121-L127避免重复发布——同一个版本号只会成功部署一次这是天然的幂等保护。第 3 步rsync 同步文件到 trunk这是脚本最精华的部分分三种情况情况一存在 .distignore 文件直接用 rsync 按排除规则同步deploy.sh#L131-L135rsync -rc --exclude-from$GITHUB_WORKSPACE/.distignore \ $GITHUB_WORKSPACE/ trunk/ --delete --delete-excluded情况二没有 .distignore走 Git 导出路线脚本会用git archive HEAD导出一份干净副本deploy.sh#L176再 rsync 到trunk。如果仓库连.gitattributes都没有还会自动写入一份默认配置把.github、.gitignore等文件排除在外deploy.sh#L161-L173。情况三设置了 BUILD_DIR直接同步构建产物目录忽略所有排除规则deploy.sh#L184-L187——适合有独立构建步骤的插件。关键参数--delete --delete-excluded它不仅复制新文件还会删除trunk中源目录已不存在的文件。这保证了 SVN 里的内容与你的标签内容完全一致而不会残留历史垃圾。第 4 步同步 assets 资源目录.wordpress-org目录可用ASSETS_DIR自定义会被同步到仓库顶层的assets目录deploy.sh#L190-L194。这正是 WordPress.org 要求的横幅、图标、截图的存放位置——与trunk平级。第 5 步Tag 提交——一次搞定版本发布准备提交前脚本做了几件关键的事添加新文件svn add . --force递归登记所有新增文件deploy.sh#L200删除失效文件通过svn status找出标记为!的删除项并执行svn rmdeploy.sh#L204复制标签svn cp trunk tags/$VERSION把本次发布固化为一个独立版本deploy.sh#L208修正图片 MIME 类型给assets里的 png/jpg/gif/svg 设置svn:mime-type防止截图在插件详情页点击时被迫下载deploy.sh#L212-L223提交svn commit -m Update to version $VERSION from GitHubdeploy.sh#L234⚠️ 注意 deploy.sh#L226 的svn update它在提交前再做一次更新专门规避 Directory out of date 这类冲突错误是很好的防御性编程习惯。两个实用开关generate-zip 与 dry-run这两个输入定义在 action.yml 中generate-zip: true部署完成后从trunk打包生成${SLUG}.zip并通过zip-path输出deploy.sh#L106-L118供后续步骤使用比如挂到 Release 里dry-run: true完整走一遍流程但跳过最终提交deploy.sh#L230-L235还能省略 SVN 密钥非常适合调试 官方提供的三个工作流示例都在 examples/ 目录下例如 examples/deploy-on-pushing-a-new-tag.yml 演示了推送 tag 即自动部署的典型用法。快速上手清单✅ 在仓库设置中配置SVN_USERNAME和SVN_PASSWORD两个密钥✅ 放入一个示例工作流到.github/workflows/目录✅ 准备.distignore或.gitattributes声明需要排除的文件✅ 先开dry-run: true跑一遍确认文件清单无误✅ 打一个 tag如v1.2.0观察自动部署完成 总结deploy.sh之所以值得学习在于它用极简的代码展示了成熟的自动化思维幂等检查版本已存在即退出、分层检出按深度控制 SVN 流量、镜像同步rsync--delete、防御性提交先 update 再 commit。读懂这一个脚本你就能把它改造成适合自己团队发布的 WordPress 插件部署流水线。【免费下载链接】action-wordpress-plugin-deployDeploy your plugin to the WordPress.org repository using GitHub Actions项目地址: https://gitcode.com/gh_mirrors/ac/action-wordpress-plugin-deploy创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表
PREV
查看更多资讯
NEXT
返回资讯列表