完整指南action-wordpress-plugin-deploy核心腳本deploy.sh深度解析——SVN檢出、rsync同步與Tag提交【免費(fèi)下載鏈接】action-wordpress-plugin-deployDeploy your plugin to the WordPress.org repository using GitHub Actions項(xiàng)目地址: https://gitcode.com/gh_mirrors/ac/action-wordpress-plugin-deployaction-wordpress-plugin-deploy是一個(gè)面向 WordPress 插件部署的 GitHub Actions 工具它能把你的 Git 標(biāo)簽內(nèi)容自動(dòng)提交到 WordPress.org 插件倉(cāng)庫(kù)。本文帶你完整剖析它的核心腳本deploy.sh看懂 SVN 檢出、rsync 同步與 Tag 提交三大關(guān)鍵環(huán)節(jié)讓你像老手一樣掌控整個(gè)自動(dòng)發(fā)布流程。它到底解決什么問題WordPress.org 的插件倉(cāng)庫(kù)使用的是SVN而絕大多數(shù)插件開發(fā)都在Git里進(jìn)行。兩套版本管理系統(tǒng)如何銜接一直是 WordPress 插件開發(fā)者的痛點(diǎn)。這個(gè)項(xiàng)目用一段不到 240 行的 Bash 腳本 deploy.sh 把整件事自動(dòng)化了環(huán)節(jié)工具作用拉取遠(yuǎn)程倉(cāng)庫(kù)SVN檢出 WordPress.org 插件倉(cāng)庫(kù)同步文件rsync把插件文件干凈地拷入trunk發(fā)布版本SVN復(fù)制trunk為tags/版本號(hào)并提交第 1 步環(huán)境準(zhǔn)備與參數(shù)解析腳本開頭deploy.sh#L7使用set -eo保證出錯(cuò)即停。隨后它會(huì)檢查并自動(dòng)安裝 SVNdeploy.sh#L15-L33校驗(yàn)SVN_USERNAME/SVN_PASSWORD兩個(gè)密鑰非 dry-run 模式下缺失則直接退出解析常用變量SLUG默認(rèn)取倉(cāng)庫(kù)名deploy.sh#L65-L67VERSION默認(rèn)從refs/tags/中提取并去掉v前綴deploy.sh#L71-L74BUILD_DIR指定構(gòu)建產(chǎn)物目錄deploy.sh#L82-L93 版本號(hào)直接來自 Git 標(biāo)簽名所以打 tag 就是發(fā)版——這是理解整個(gè)流程的鑰匙。第 2 步SVN 檢出 WordPress.org 倉(cāng)庫(kù)核心代碼在 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這里用了一個(gè)非常巧妙的分層檢出策略assets和trunk完整下載infinity因?yàn)槲募竭M(jìn)去tags只下載目錄層級(jí)immediates只為檢查某個(gè)版本是否已存在這樣既省流量又保留完整判斷能力。如果tags/$VERSION已存在腳本會(huì)提前退出deploy.sh#L121-L127避免重復(fù)發(fā)布——同一個(gè)版本號(hào)只會(huì)成功部署一次這是天然的冪等保護(hù)。第 3 步rsync 同步文件到 trunk這是腳本最精華的部分分三種情況情況一存在 .distignore 文件直接用 rsync 按排除規(guī)則同步deploy.sh#L131-L135rsync -rc --exclude-from$GITHUB_WORKSPACE/.distignore \ $GITHUB_WORKSPACE/ trunk/ --delete --delete-excluded情況二沒有 .distignore走 Git 導(dǎo)出路線腳本會(huì)用git archive HEAD導(dǎo)出一份干凈副本deploy.sh#L176再 rsync 到trunk。如果倉(cāng)庫(kù)連.gitattributes都沒有還會(huì)自動(dòng)寫入一份默認(rèn)配置把.github、.gitignore等文件排除在外deploy.sh#L161-L173。情況三設(shè)置了 BUILD_DIR直接同步構(gòu)建產(chǎn)物目錄忽略所有排除規(guī)則deploy.sh#L184-L187——適合有獨(dú)立構(gòu)建步驟的插件。關(guān)鍵參數(shù)--delete --delete-excluded它不僅復(fù)制新文件還會(huì)刪除trunk中源目錄已不存在的文件。這保證了 SVN 里的內(nèi)容與你的標(biāo)簽內(nèi)容完全一致而不會(huì)殘留歷史垃圾。第 4 步同步 assets 資源目錄.wordpress-org目錄可用ASSETS_DIR自定義會(huì)被同步到倉(cāng)庫(kù)頂層的assets目錄deploy.sh#L190-L194。這正是 WordPress.org 要求的橫幅、圖標(biāo)、截圖的存放位置——與trunk平級(jí)。第 5 步Tag 提交——一次搞定版本發(fā)布準(zhǔn)備提交前腳本做了幾件關(guān)鍵的事添加新文件svn add . --force遞歸登記所有新增文件deploy.sh#L200刪除失效文件通過svn status找出標(biāo)記為!的刪除項(xiàng)并執(zhí)行svn rmdeploy.sh#L204復(fù)制標(biāo)簽svn cp trunk tags/$VERSION把本次發(fā)布固化為一個(gè)獨(dú)立版本deploy.sh#L208修正圖片 MIME 類型給assets里的 png/jpg/gif/svg 設(shè)置svn:mime-type防止截圖在插件詳情頁(yè)點(diǎn)擊時(shí)被迫下載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 這類沖突錯(cuò)誤是很好的防御性編程習(xí)慣。兩個(gè)實(shí)用開關(guān)generate-zip 與 dry-run這兩個(gè)輸入定義在 action.yml 中g(shù)enerate-zip: true部署完成后從trunk打包生成${SLUG}.zip并通過zip-path輸出deploy.sh#L106-L118供后續(xù)步驟使用比如掛到 Release 里dry-run: true完整走一遍流程但跳過最終提交deploy.sh#L230-L235還能省略 SVN 密鑰非常適合調(diào)試 官方提供的三個(gè)工作流示例都在 examples/ 目錄下例如 examples/deploy-on-pushing-a-new-tag.yml 演示了推送 tag 即自動(dòng)部署的典型用法?？焖偕鲜智鍐? 在倉(cāng)庫(kù)設(shè)置中配置SVN_USERNAME和SVN_PASSWORD兩個(gè)密鑰? 放入一個(gè)示例工作流到.github/workflows/目錄? 準(zhǔn)備.distignore或.gitattributes聲明需要排除的文件? 先開dry-run: true跑一遍確認(rèn)文件清單無誤? 打一個(gè) tag如v1.2.0觀察自動(dòng)部署完成 總結(jié)deploy.sh之所以值得學(xué)習(xí)在于它用極簡(jiǎn)的代碼展示了成熟的自動(dòng)化思維冪等檢查版本已存在即退出、分層檢出按深度控制 SVN 流量、鏡像同步rsync--delete、防御性提交先 update 再 commit。讀懂這一個(gè)腳本你就能把它改造成適合自己團(tuán)隊(duì)發(fā)布的 WordPress 插件部署流水線?！久赓M(fèi)下載鏈接】action-wordpress-plugin-deployDeploy your plugin to the WordPress.org repository using GitHub Actions項(xiàng)目地址: https://gitcode.com/gh_mirrors/ac/action-wordpress-plugin-deploy創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考