前端【免費下載鏈接】BilibiliSponsorBlock一款跳過小電視視頻中恰飯片段的瀏覽器插件移植自 SponsorBlock。A browser extension to skip sponsored segments in videos, ported from the SponsorBlock項目地址https://gitcode.com/gh_mirrors/bi/BilibiliSponsorBlock點擊查看免費下載本篇技術(shù)指南面向需要為 BilibiliSponsorBlock小電視空降助手執(zhí)行版本發(fā)布、商店提審或發(fā)布狀態(tài)核查的開發(fā)者與 CI 維護者。全文以倉庫.agents/skills/browser-extension-release技能文檔為核心骨架結(jié)合 .github/workflows 下的真實工作流與 manifest/manifest.json 等配置展開覆蓋發(fā)版前盤點、版本號 bump、本地與 CI 驗證、Release 文案規(guī)范、商店憑據(jù)管理、we pub 提交與失敗排查的完整鏈路。讀完本文你將能按倉庫慣例安全地發(fā)布一個新版本并能準確區(qū)分上傳成功 / 已提交審核 / 審核通過 / 公開上線這四檔狀態(tài)。一、發(fā)版技能文檔的定位與核心約束.agents/skills/browser-extension-release/SKILL.md是倉庫內(nèi)置的 Agent 發(fā)版技能聲明了明確的適用范圍只針對當前BilibiliSponsorBlock倉庫本身的版本發(fā)布以倉庫當前配置和 Git 歷史為準不把服務端倉庫的版本或流程混進來。技能按任務粒度拆分為兩份參考文檔references/release-process.md負責版本號、commit、tag、GitHub Release、Release 文案與附件references/store-publishing.md負責商店憑據(jù)、Chrome/Firefox/Edge 提交、審核狀態(tài)與失敗排查。完整發(fā)版必須依次讀取兩份 reference如果只做狀態(tài)查詢則只需讀取對應的一份。該技能定義了七條不可破壞的約束是發(fā)版操作的安全邊界先確認工作倉庫是BilibiliSponsorBlock讀取 AGENTS.md檢查git status、遠端分支和最新 tag版本號唯一來源是 manifest/manifest.json歷史上不隨擴展版本修改 package.json 的version當前倉庫中package.json的 version 仍停留在0.1.10而 manifest 已是0.16.0恰好印證了這一約定保留用戶已有改動遠端前進時先 fetch 再 rebase禁止 force push 和覆蓋遠端提交構(gòu)建、查詢和校驗不代表允許發(fā)布——執(zhí)行g(shù)it push、創(chuàng)建 tag/Release、上傳商店或重新提交商店前必須確認用戶已授權(quán)對應外部變更不讀取、打印或要求用戶在聊天中發(fā)送 Secret 值只檢查 GitHub Secret 名稱與更新時間Actions 日志中若意外出現(xiàn)未遮罩的敏感值應停止展示日志并提醒輪換商店發(fā)布可能部分成功重試時只開啟失敗的商店絕不為讓總 workflow 變綠而重復提交已成功的商店正式發(fā)布必須從固定版本 tag運行而不是從會繼續(xù)變化的master運行只做構(gòu)建驗證才可以從master運行并關(guān)閉全部商店開關(guān)。二、發(fā)版前盤點只讀檢查與變更核實發(fā)版的第一步是在倉庫根目錄執(zhí)行只讀盤點技能文檔給出了完整命令組git status --short --branch git fetch origin master --tags git log --oneline --decorate -20 git tag --sort-version:refname | head -15 gh api repos/hanydd/BilibiliSponsorBlock/releases?per_page10 \ --jq .[] | {tag_name,name,published_at,html_url,assets:[.assets[].name]}要點版本沖突檢查確認目標版本高于 GitHub Release 和三個商店的已有版本。商店不接受重復或降低的版本號這是發(fā)布工作流的一條硬性前提見 docs/publishing.md。版本決策若用戶未指定版本可根據(jù)變更兼容性建議 patch/minor/major但在動手修改前必須讓用戶確認。真實變更核查不要只依據(jù) commit 標題判斷變更內(nèi)容git log PREVIOUS_TAG..HEAD --reverse --format%h%x09%an%x09%s git diff --stat PREVIOUS_TAG..HEAD對標題模糊的重構(gòu)或修復應進一步查看實際 diff 后再寫進 Release 文案。三、版本號 bump 與版本 commit倉庫的歷史約定是只修改manifest/manifest.json一個文件把version字段改為目標版本不修改package.json。當前 manifest/manifest.json 的版本為0.16.0其中的name、short_name、description均使用__MSG_*__國際化占位符真正的文案在 public/_locales 中按語言分發(fā)。版本提交信息固定為Bump Version X.Y.Z提交命令git add manifest/manifest.json git commit -m Bump Version X.Y.Z關(guān)鍵慣例Release tag 應直接指向這個 bump commit。為保持這種關(guān)系通常先完成普通代碼、CI 和文檔變更最后再做 bump commit 和 tag。需要創(chuàng)建 Release 時記錄其 SHAversionX.Y.Z bump_commit$(git rev-parse HEAD)提交前運行g(shù)it diff --check檢查空白錯誤。若遠端master已前進fetch 后審查新增提交并 rebase解決沖突時既要保留遠端的新行為也要保留目標版本號。從構(gòu)建插件 webpack/webpack.manifest.js 的實現(xiàn)看manifest.json是所有瀏覽器構(gòu)建的公共底座構(gòu)建時會讀取manifest/manifest.json再按chrome/firefox/safari分別與 manifest/chrome-manifest-extra.json、manifest/firefox-manifest-extra.json、manifest/safari-manifest-extra.json 做深度合并后寫入dist/manifest.json。這也解釋了為什么版本號只落在manifest/manifest.json一處就能同時控制三個商店包與 Safari 構(gòu)建的版本。四、本地與 GitHub CI 驗證發(fā)布前至少運行以下本地驗證僅當config.json不存在時才拷貝且按 AGENTS.md 的提醒config.json必須存在才能構(gòu)建cp config.json.example config.json # 僅當 config.json 不存在 npm ci npm run lint npm run testnpm run lint執(zhí)行eslint srcnpm run test會先執(zhí)行一次完整的 Chrome 構(gòu)建再跑 Jest跳過構(gòu)建可用npm run test-without-building這正是 package.json 中test: npm run build:chrome npx jest的定義。推送后等待倉庫原有的兩個工作流.github/workflows/ci.ymlCI執(zhí)行npx ts-node scripts/validate-ota.ts校驗 OTA 配置、lint并構(gòu)建 Chrome/Firefox/Safari 三套產(chǎn)物.github/workflows/tests.ymlTests運行 Jest 單測并安裝 Playwright Chromium 后執(zhí)行npm run test:e2e集成測試。不要在CI或Tests失敗時創(chuàng)建 Release除非用戶明確接受并說明原因。需要驗證發(fā)布流水線本身、但不觸碰商店時可從master觸發(fā)商店工作流并關(guān)閉全部商店開關(guān)gh workflow run publish-stores.yml --ref master \ -f chromefalse -f firefoxfalse -f edgefalse然后等待Test and packagejob 完成確認三種 ZIP 版本一致且 artifact 上傳成功。五、Release 文案風格與創(chuàng)建5.1 文案風格先查看最近幾個 Release 的正文作為風格參照for tag in 0.13.1 0.13.0 0.12.1; do gh api repos/hanydd/BilibiliSponsorBlock/releases/tags/$tag \ --jq {tag_name,body} done本倉庫使用簡短中文無序列表- 修復……的問題 - 添加……功能 #123 contributor - 優(yōu)化……寫作規(guī)則要點不加更新內(nèi)容Whats Changed等標題不保留只有Full Changelog的自動生成正文每條描述一個用戶能理解的修復、功能、兼容性變化、重要測試能力或發(fā)布能力合并相近的內(nèi)部提交不逐條復制 commit log破壞性變化、移除的功能和默認行為變化必須明確寫出有外部貢獻者時沿用歷史格式標記usernameissue/PR 編號確有幫助時再添加不夸大上傳成功為已上線。創(chuàng)建 Release 前用臨時 notes 文件復查文字和版本范圍。5.2 創(chuàng)建 Release先推送版本 commit 并等待 CI 通過再創(chuàng)建同名 ReleaseversionX.Y.Z bump_commit$(git rev-parse HEAD) git push origin master gh release create $version \ --target $bump_commit \ --title $version \ --notes-file /path/to/release-notes.md注意gh release create會在 tag 不存在時自動創(chuàng)建同名 tag因此創(chuàng)建前必須確認 tag 和 Release 均不存在不要移動已公開的 tag。創(chuàng)建后可核對 tag 與 bump commit 的 SHA 是否一致git fetch origin tag $version tag_commit$(git rev-parse $version^{commit}) echo bump$bump_commit tag$tag_commit5.3 Release 附件由工作流自動上傳發(fā)布 Release 會觸發(fā) .github/workflows/release.yml 的Upload Release Buildjob該 workflow 依次構(gòu)建并上傳四個附件ChromeExtension.zip FirefoxExtension.zip EdgeExtension.zip SafariExtension.zip從源碼看buildjob 使用 Node 20先cp config.json.example config.json、npm ci然后按順序執(zhí)行npm run build:chrome/build:firefox/build:edge/build:safari每次換瀏覽器前rm -rf ./dist清理用zip -r打包dist目錄后通過Shopify/upload-to-releasev2.0.0上傳另有獨立的safari-macosjob 通過 .github/workflows/safari-macos.yml 在 macOS runner 上構(gòu)建 Safari 原生 app 并上傳。等待附件上傳gh run list --workflow release.yml --limit 3 gh run watch RUN_ID --exit-status最后通過 Releases API 核對正文、tag、目標 commit、附件名稱和大小。若 Release 已創(chuàng)建但文案需要修正使用gh release edit X.Y.Z --notes-file ...修改正文不會重新觸發(fā)附件構(gòu)建。六、商店提交publish-stores 工作流與憑據(jù)環(huán)境6.1 發(fā)布入口與觸發(fā)方式商店發(fā)布入口是 .github/workflows/publish-stores.ymlPublish extension stores它構(gòu)建并校驗 Chrome、Firefox、Edge 三個包然后用wepub調(diào)用各商店 API。工作流只支持更新已有商店項目不創(chuàng)建新的商店條目。正式發(fā)布必須從不可變 tag 運行g(shù)h workflow run publish-stores.yml --ref X.Y.Z \ -f chrometrue -f firefoxtrue -f edgetrue三個布爾輸入默認全為true。若某個商店已成功重試時把它設為false例如只重試 Edgegh workflow run publish-stores.yml --ref X.Y.Z \ -f chromefalse -f firefoxfalse -f edgetrue從 workflow 定義看buildjobTest and package包含完整的流水線npm ci、拷貝配置、讀取 manifest 版本、lint、test、分別用npm run build:{chrome,firefox,edge}npx web-ext build打包三個 ZIPFirefox 額外用git archive生成源碼歸檔firefox-source.zip隨后校驗三個包內(nèi)manifest.json的 version 是否與倉庫 manifest 一致生成certification-notes.txt版本 source commit 最新提交說明后以extension-store-packages-version為名上傳 artifact保留 14 天。三個發(fā)布 jobchrome/firefox/edge并行運行均使用browser-storesGitHub Environment。6.2 GitHub Environment 配置首次配置時在倉庫的Settings Environments中創(chuàng)建browser-stores環(huán)境對應文檔 docs/publishing.md 的首節(jié)。Variables普通標識公開可見Variable用途CHROME_PUBLISHER_IDChrome Web Store Developer Dashboard 的 Publisher Settings 中的 Publisher IDCHROME_ITEM_IDChrome 擴展 ID未配置時 workflow 使用默認值eaoelafamejbnggahofapllmfhlhajddpublish-stores.ymlEDGE_PRODUCT_IDPartner Center 中 Edge extension overview 的 Product IDFIREFOX_ADDON_IDAMO Add-on ID未配置時 workflow 使用默認值{f10c197e-c2a4-43b6-a982-7e186f7c63d9}publish-stores.ymlSecrets憑據(jù)必須用 GitHub 加密存儲Secret獲取位置CHROME_CLIENT_IDGoogle Cloud 中啟用 Chrome Web Store API 后創(chuàng)建的 Web application OAuth clientCHROME_CLIENT_SECRET同上 OAuth client 的 secretCHROME_REFRESH_TOKEN使用 Chrome Web Store scope 生成的 OAuth refresh token不是 access tokenFIREFOX_API_KEYAMO API Credentials 頁面中的 JWT issuerFIREFOX_API_SECRETAMO API Credentials 頁面中的 JWT secretEDGE_CLIENT_IDPartner Center 的 Microsoft Edge Publish API 頁面EDGE_API_KEYPartner Center 的 Publish API 頁面憑據(jù)檢查只用名稱與更新時間不輸出值gh api repos/hanydd/BilibiliSponsorBlock/environments/browser-stores/variables \ --jq .variables[] | {name,updated_at} gh api repos/hanydd/BilibiliSponsorBlock/environments/browser-stores/secrets \ --jq .secrets[] | {name,updated_at}不要把憑據(jù)寫進倉庫文件、Issue、Actions 日志或聊天記錄。同時注意GitHub 會遮罩 Secrets但Variables 會明文顯示在日志中因此 Variables 不得存放任何敏感值。6.3 Chrome 憑據(jù)的生成要點Chrome 使用 OAuth 訪問 Chrome Web Store API憑據(jù)細節(jié)來自 references/store-publishing.mdCHROME_PUBLISHER_ID來自 Chrome Web Store Developer Dashboard 的Publisher SettingsCHROME_CLIENT_ID/CHROME_CLIENT_SECRETGoogle Cloud 中啟用 Chrome Web Store API 后創(chuàng)建的Web applicationOAuth clientAuthorized redirect URI 必須精確為https://developers.google.com/oauthplayground放在redirect URIs不是 JavaScript origins且末尾沒有/OAuth Playground 使用 scopehttps://www.googleapis.com/auth/chromewebstore并勾選 offline access保存響應中的refresh_token不是一小時過期的access_tokenOAuth 應用應為In production管理自己的 Chrome 擴展不需要申請 Google 驗證Testing 狀態(tài)簽發(fā)的 refresh token 通常 7 天過期切換正式版后需重新完整授權(quán)并替換CHROME_REFRESH_TOKEN常見錯誤redirect_uri_mismatch表示 redirect URI 或 Client ID 不匹配403 access_denied且提示 testing表示登錄賬號不在 Test users或應用仍未切換正式版。6.4 Chrome 憑據(jù)的定期自檢倉庫提供了獨立工作流 .github/workflows/check-chrome-credentials.ymlCheck Chrome credentials每周一北京時間 09:23cron23 1 * * 1UTC8定時運行也可手動觸發(fā)。它復用browser-stores中的 Chrome 憑據(jù)先用 refresh token 換取臨時 access token再調(diào)用只讀的fetchStatus查詢當前擴展不構(gòu)建、不上傳、不發(fā)布也不修改 GitHub Secrets。其底層邏輯在 scripts/check-chrome-credentials.mjs 中校驗CHROME_PUBLISHER_ID、CHROME_ITEM_ID、CHROME_CLIENT_ID、CHROME_CLIENT_SECRET、CHROME_REFRESH_TOKEN五項是否齊全POST 到https://oauth2.googleapis.com/tokengrant_type: refresh_token換取 access token用 Bearer token 請求https://chromewebstore.googleapis.com/v2/publishers/{id}/items/{itemId}:fetchStatus并校驗響應中的itemId與配置一致出錯時絕不輸出響應體響應體可能含憑據(jù)只給出針對性建議invalid_grant→ 重新授權(quán)并替換CHROME_REFRESH_TOKENinvalid_client→ 檢查 Client ID / Client Secret401/403 → 檢查 OAuth scope、開發(fā)者賬號訪問與 publisher/item ID429/5xx → 服務限流或不可用稍后重試。該腳本的本地測試不需要真實憑據(jù)node --test scripts/check-chrome-credentials.test.mjs注意兩個限制見 docs/publishing.md定時檢查不能保證 refresh token 永不失效公開倉庫連續(xù) 60 天沒有活動時 GitHub 會自動停用定時工作流需要到 Actions 頁面重新啟用。6.5 Firefox 與 Edge 憑據(jù)要點Firefox在https://addons.mozilla.org/developers/addon/api/key/獲取 JWT issuer→FIREFOX_API_KEY與 JWT secret→FIREFOX_API_SECRET。workflow 以listed渠道創(chuàng)建版本并上傳可構(gòu)建的源碼歸檔不要把unlisted簽名誤當商店更新。對應命令為wepub firefox artifacts/firefox-extension.zip \ --channel listed \ --compatibility firefox,android \ --source artifacts/firefox-source.zipEdgePartner Center 的Microsoft Edge Publish API使用 v1.1 新體驗Client ID →EDGE_CLIENT_IDAPI key →EDGE_API_KEY。EDGE_PRODUCT_ID必須是 Partner Center GUID形如xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx不要填 32 位 Chromium Extension ID填錯時上傳端點通常返回 404。API key 有過期日期需要輪換。七、運行與日志檢查觸發(fā)商店工作流后記錄 run ID 并等待gh run list --workflow publish-stores.yml --limit 3 gh run watch RUN_ID --exit-status即使總 workflow 失敗也要分別檢查每個 job——其他商店可能已經(jīng)成功gh api repos/hanydd/BilibiliSponsorBlock/actions/runs/RUN_ID/jobs \ --jq .jobs[] | {id,name,status,conclusion} gh run view RUN_ID --job JOB_ID --log只展示與結(jié)論有關(guān)的日志片段避免在輸出中保留可能泄露敏感信息的完整日志。八、成功判據(jù)四檔狀態(tài)嚴格區(qū)分技能文檔要求最終報告必須分別列出 GitHub Release、Chrome、Firefox 和 Edge 的狀態(tài)并區(qū)分上傳成功 / 已提交審核 / 審核通過 / 公開上線。Chrome日志應依次出現(xiàn)the access token fetched the package archive uploaded, upload_stateSUCCEEDED the draft submitted, item_statePENDING_REVIEWPENDING_REVIEW表示已提交審核不是已上線公開商店仍顯示舊版本屬于正?，F(xiàn)象。不要用相同版本重復上傳來測試新的 refresh token。Firefox日志應出現(xiàn) new version created 和 source archive uploaded?？捎霉_ API 驗證https://addons.mozilla.org/api/v5/addons/addon/bilisponsorblock/只有當current_version為目標版本且status為public時才能報告公開上線。Edge日志應出現(xiàn) package archive uploaded、upload processed、draft submitted、submission processed。最后一項表示已交給 Edge 認證流程不代表商店已公開。九、常見失敗與停止條件技能文檔給出了一套先停后查、按狀態(tài)修復的排查表現(xiàn)象處理缺少變量/Secret停止在憑據(jù)檢查不調(diào)用商店讓用戶在 GitHub Environment 中補齊Chrome 401 /invalid_grantrefresh token 無效、過期或與 Client 不匹配重新授權(quán)并只替換 refresh tokenChrome 已有相同版本或正在審核不要重復發(fā)布查詢后臺狀態(tài)Firefoxversion already exists不要刪除已創(chuàng)建版本確認第一次提交是否已成功Edge 404先檢查 Product ID 是否為 Partner Center GUIDEdge 401/403檢查 Publish API v1.1 的 Client ID、API key 與過期日期任一商店已成功、另一個失敗僅重跑失敗商店把成功商店的輸入設為false連續(xù)失敗時讀取一次完整 job 日志根據(jù) HTTP 狀態(tài)修復不要盲目反復提交。審核中的商店應說明需等待且不承諾審核時間。十、完成標準與最終報告一次完整發(fā)版需要留下可核驗結(jié)果SKILL.md 的完成標準manifest/manifest.json 是目標版本版本 commit 已推送按倉庫慣例版本 tag 指向該 bump commit普通 CI、單元測試和 Playwright 測試通過同名 GitHub Release 已發(fā)布中文說明符合歷史風格Release 的 Chrome、Firefox、Edge、Safari 四個附件上傳成功商店 workflow 的每個啟用 job 都有明確結(jié)果成功時記錄審核狀態(tài)失敗時記錄 HTTP 狀態(tài)和可執(zhí)行修復工作樹干凈且本地分支與遠端同步。最終向用戶分別報告 GitHub Release、Chrome、Firefox 和 Edge 的狀態(tài)附 Actions run 鏈接并嚴格區(qū)分四檔狀態(tài)絕不把上傳成功說成已上線。附與本文相關(guān)的倉庫文件索引發(fā)版技能.agents/skills/browser-extension-release/SKILL.md、references/release-process.md、references/store-publishing.md工作流release.yml、publish-stores.yml、check-chrome-credentials.yml、ci.yml、tests.yml、safari-macos.yml版本與構(gòu)建manifest/manifest.json、webpack/webpack.manifest.js、package.json其他docs/publishing.md、scripts/check-chrome-credentials.mjs、config.json.example、AGENTS.md贊分享前端【免費下載鏈接】BilibiliSponsorBlock一款跳過小電視視頻中恰飯片段的瀏覽器插件移植自 SponsorBlock。A browser extension to skip sponsored segments in videos, ported from the SponsorBlock項目地址https://gitcode.com/gh_mirrors/bi/BilibiliSponsorBlock點擊查看免費下載相關(guān)推薦BiliNote 發(fā)版全流程從 develop 分支到 Chrome / Edge / Firefox 商店上架BiliNote 發(fā)版全流程從 develop 分支到 Chrome / Edge / Firefox 商店上架 本篇是 BiliNote 開源倉庫的發(fā)版執(zhí)行AI 應用大模型RAG語音后端前端桌面應用Doorkeeper gem 版本發(fā)布全流程指南從 bump 版本號到 GitHub ReleaseDoorkeeper gem 版本發(fā)布全流程指南從 bump 版本號到 GitHub Release 本指南面向 DoorkeeperRuby on Rai后端認證鑒權(quán)如何高效完成Rnote發(fā)布流程從版本號bump到GitHub Release全指南如何高效完成Rnote發(fā)布流程從版本號bump到GitHub Release全指南 Rnote是一款功能強大的手繪筆記應用本文將詳細介紹如何從版本號更新到G桌面應用圖形學上一篇Torba錢包開發(fā)常見問題解答新手必看的完整手冊下一篇Realtek 8192FU Linux USB無線網(wǎng)卡驅(qū)動完整安裝指南創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考