完整指南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 提交三大關鍵環(huán)節(jié)讓你像老手一樣掌控整個自動發(fā)布流程。它到底解決什么問題WordPress.org 的插件倉庫使用的是SVN而絕大多數(shù)插件開發(fā)都在Git里進行。兩套版本管理系統(tǒng)如何銜接一直是 WordPress 插件開發(fā)者的痛點。這個項目用一段不到 240 行的 Bash 腳本 deploy.sh 把整件事自動化了環(huán)節(jié)工具作用拉取遠程倉庫SVN檢出 WordPress.org 插件倉庫同步文件rsync把插件文件干凈地拷入trunk發(fā)布版本SVN復制trunk為tags/版本號并提交第 1 步環(huán)境準備與參數(shù)解析腳本開頭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指定構建產(chǎn)物目錄deploy.sh#L82-L93 版本號直接來自 Git 標簽名所以打 tag 就是發(fā)版——這是理解整個流程的鑰匙。第 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避免重復發(fā)布——同一個版本號只會成功部署一次這是天然的冪等保護。第 3 步rsync 同步文件到 trunk這是腳本最精華的部分分三種情況情況一存在 .distignore 文件直接用 rsync 按排除規(guī)則同步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直接同步構建產(chǎn)物目錄忽略所有排除規(guī)則deploy.sh#L184-L187——適合有獨立構建步驟的插件。關鍵參數(shù)--delete --delete-excluded它不僅復制新文件還會刪除trunk中源目錄已不存在的文件。這保證了 SVN 里的內容與你的標簽內容完全一致而不會殘留歷史垃圾。第 4 步同步 assets 資源目錄.wordpress-org目錄可用ASSETS_DIR自定義會被同步到倉庫頂層的assets目錄deploy.sh#L190-L194。這正是 WordPress.org 要求的橫幅、圖標、截圖的存放位置——與trunk平級。第 5 步Tag 提交——一次搞定版本發(fā)布準備提交前腳本做了幾件關鍵的事添加新文件svn add . --force遞歸登記所有新增文件deploy.sh#L200刪除失效文件通過svn status找出標記為!的刪除項并執(zhí)行svn rmdeploy.sh#L204復制標簽svn cp trunk tags/$VERSION把本次發(fā)布固化為一個獨立版本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它在提交前再做一次更新專門規(guī)避 Directory out of date 這類沖突錯誤是很好的防御性編程習慣。兩個實用開關generate-zip 與 dry-run這兩個輸入定義在 action.yml 中generate-zip: true部署完成后從trunk打包生成${SLUG}.zip并通過zip-path輸出deploy.sh#L106-L118供后續(xù)步驟使用比如掛到 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。讀懂這一個腳本你就能把它改造成適合自己團隊發(fā)布的 WordPress 插件部署流水線?！久赓M下載鏈接】action-wordpress-plugin-deployDeploy your plugin to the WordPress.org repository using GitHub Actions項目地址: https://gitcode.com/gh_mirrors/ac/action-wordpress-plugin-deploy創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 完整指南：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 提交三大關鍵環(huán)節(jié)讓你像老手一樣掌控整個自動發(fā)布流程。它到底解決什么問題WordPress.org 的插件倉庫使用的是SVN而絕大多數(shù)插件開發(fā)都在Git里進行。兩套版本管理系統(tǒng)如何銜接一直是 WordPress 插件開發(fā)者的痛點。這個項目用一段不到 240 行的 Bash 腳本 deploy.sh 把整件事自動化了環(huán)節(jié)工具作用拉取遠程倉庫SVN檢出 WordPress.org 插件倉庫同步文件rsync把插件文件干凈地拷入trunk發(fā)布版本SVN復制trunk為tags/版本號并提交第 1 步環(huán)境準備與參數(shù)解析腳本開頭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指定構建產(chǎn)物目錄deploy.sh#L82-L93 版本號直接來自 Git 標簽名所以打 tag 就是發(fā)版——這是理解整個流程的鑰匙。第 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避免重復發(fā)布——同一個版本號只會成功部署一次這是天然的冪等保護。第 3 步rsync 同步文件到 trunk這是腳本最精華的部分分三種情況情況一存在 .distignore 文件直接用 rsync 按排除規(guī)則同步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直接同步構建產(chǎn)物目錄忽略所有排除規(guī)則deploy.sh#L184-L187——適合有獨立構建步驟的插件。關鍵參數(shù)--delete --delete-excluded它不僅復制新文件還會刪除trunk中源目錄已不存在的文件。這保證了 SVN 里的內容與你的標簽內容完全一致而不會殘留歷史垃圾。第 4 步同步 assets 資源目錄.wordpress-org目錄可用ASSETS_DIR自定義會被同步到倉庫頂層的assets目錄deploy.sh#L190-L194。這正是 WordPress.org 要求的橫幅、圖標、截圖的存放位置——與trunk平級。第 5 步Tag 提交——一次搞定版本發(fā)布準備提交前腳本做了幾件關鍵的事添加新文件svn add . --force遞歸登記所有新增文件deploy.sh#L200刪除失效文件通過svn status找出標記為!的刪除項并執(zhí)行svn rmdeploy.sh#L204復制標簽svn cp trunk tags/$VERSION把本次發(fā)布固化為一個獨立版本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它在提交前再做一次更新專門規(guī)避 Directory out of date 這類沖突錯誤是很好的防御性編程習慣。兩個實用開關generate-zip 與 dry-run這兩個輸入定義在 action.yml 中generate-zip: true部署完成后從trunk打包生成${SLUG}.zip并通過zip-path輸出deploy.sh#L106-L118供后續(xù)步驟使用比如掛到 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。讀懂這一個腳本你就能把它改造成適合自己團隊發(fā)布的 WordPress 插件部署流水線?！久赓M下載鏈接】action-wordpress-plugin-deployDeploy your plugin to the WordPress.org repository using GitHub Actions項目地址: https://gitcode.com/gh_mirrors/ac/action-wordpress-plugin-deploy創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考