前端【免费下载链接】BilibiliSponsorBlock一款跳过小电视视频中恰饭片段的浏览器插件移植自 SponsorBlock。A browser extension to skip sponsored segments in videos, ported from the SponsorBlock项目地址https://gitcode.com/gh_mirrors/bi/BilibiliSponsorBlock点击查看免费下载本篇技术指南面向需要为 BilibiliSponsorBlock小电视空降助手执行版本发布、商店提审或发布状态核查的开发者与 CI 维护者。全文以仓库.agents/skills/browser-extension-release技能文档为核心骨架结合 .github/workflows 下的真实工作流与 manifest/manifest.json 等配置展开覆盖发版前盘点、版本号 bump、本地与 CI 验证、Release 文案规范、商店凭据管理、we pub 提交与失败排查的完整链路。读完本文你将能按仓库惯例安全地发布一个新版本并能准确区分上传成功 / 已提交审核 / 审核通过 / 公开上线这四档状态。一、发版技能文档的定位与核心约束.agents/skills/browser-extension-release/SKILL.md是仓库内置的 Agent 发版技能声明了明确的适用范围只针对当前BilibiliSponsorBlock仓库本身的版本发布以仓库当前配置和 Git 历史为准不把服务端仓库的版本或流程混进来。技能按任务粒度拆分为两份参考文档references/release-process.md负责版本号、commit、tag、GitHub Release、Release 文案与附件references/store-publishing.md负责商店凭据、Chrome/Firefox/Edge 提交、审核状态与失败排查。完整发版必须依次读取两份 reference如果只做状态查询则只需读取对应的一份。该技能定义了七条不可破坏的约束是发版操作的安全边界先确认工作仓库是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 和覆盖远端提交构建、查询和校验不代表允许发布——执行git push、创建 tag/Release、上传商店或重新提交商店前必须确认用户已授权对应外部变更不读取、打印或要求用户在聊天中发送 Secret 值只检查 GitHub Secret 名称与更新时间Actions 日志中若意外出现未遮罩的敏感值应停止展示日志并提醒轮换商店发布可能部分成功重试时只开启失败的商店绝不为让总 workflow 变绿而重复提交已成功的商店正式发布必须从固定版本 tag运行而不是从会继续变化的master运行只做构建验证才可以从master运行并关闭全部商店开关。二、发版前盘点只读检查与变更核实发版的第一步是在仓库根目录执行只读盘点技能文档给出了完整命令组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 和三个商店的已有版本。商店不接受重复或降低的版本号这是发布工作流的一条硬性前提见 docs/publishing.md。版本决策若用户未指定版本可根据变更兼容性建议 patch/minor/major但在动手修改前必须让用户确认。真实变更核查不要只依据 commit 标题判断变更内容git log PREVIOUS_TAG..HEAD --reverse --format%h%x09%an%x09%s git diff --stat PREVIOUS_TAG..HEAD对标题模糊的重构或修复应进一步查看实际 diff 后再写进 Release 文案。三、版本号 bump 与版本 commit仓库的历史约定是只修改manifest/manifest.json一个文件把version字段改为目标版本不修改package.json。当前 manifest/manifest.json 的版本为0.16.0其中的name、short_name、description均使用__MSG_*__国际化占位符真正的文案在 public/_locales 中按语言分发。版本提交信息固定为Bump Version X.Y.Z提交命令git add manifest/manifest.json git commit -m Bump Version X.Y.Z关键惯例Release tag 应直接指向这个 bump commit。为保持这种关系通常先完成普通代码、CI 和文档变更最后再做 bump commit 和 tag。需要创建 Release 时记录其 SHAversionX.Y.Z bump_commit$(git rev-parse HEAD)提交前运行git diff --check检查空白错误。若远端master已前进fetch 后审查新增提交并 rebase解决冲突时既要保留远端的新行为也要保留目标版本号。从构建插件 webpack/webpack.manifest.js 的实现看manifest.json是所有浏览器构建的公共底座构建时会读取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 构建的版本。四、本地与 GitHub CI 验证发布前至少运行以下本地验证仅当config.json不存在时才拷贝且按 AGENTS.md 的提醒config.json必须存在才能构建cp config.json.example config.json # 仅当 config.json 不存在 npm ci npm run lint npm run testnpm run lint执行eslint srcnpm run test会先执行一次完整的 Chrome 构建再跑 Jest跳过构建可用npm run test-without-building这正是 package.json 中test: npm run build:chrome npx jest的定义。推送后等待仓库原有的两个工作流.github/workflows/ci.ymlCI执行npx ts-node scripts/validate-ota.ts校验 OTA 配置、lint并构建 Chrome/Firefox/Safari 三套产物.github/workflows/tests.ymlTests运行 Jest 单测并安装 Playwright Chromium 后执行npm run test:e2e集成测试。不要在CI或Tests失败时创建 Release除非用户明确接受并说明原因。需要验证发布流水线本身、但不触碰商店时可从master触发商店工作流并关闭全部商店开关gh workflow run publish-stores.yml --ref master \ -f chromefalse -f firefoxfalse -f edgefalse然后等待Test and packagejob 完成确认三种 ZIP 版本一致且 artifact 上传成功。五、Release 文案风格与创建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 - 优化……写作规则要点不加更新内容Whats Changed等标题不保留只有Full Changelog的自动生成正文每条描述一个用户能理解的修复、功能、兼容性变化、重要测试能力或发布能力合并相近的内部提交不逐条复制 commit log破坏性变化、移除的功能和默认行为变化必须明确写出有外部贡献者时沿用历史格式标记usernameissue/PR 编号确有帮助时再添加不夸大上传成功为已上线。创建 Release 前用临时 notes 文件复查文字和版本范围。5.2 创建 Release先推送版本 commit 并等待 CI 通过再创建同名 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 不存在时自动创建同名 tag因此创建前必须确认 tag 和 Release 均不存在不要移动已公开的 tag。创建后可核对 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 附件由工作流自动上传发布 Release 会触发 .github/workflows/release.yml 的Upload Release Buildjob该 workflow 依次构建并上传四个附件ChromeExtension.zip FirefoxExtension.zip EdgeExtension.zip SafariExtension.zip从源码看buildjob 使用 Node 20先cp config.json.example config.json、npm ci然后按顺序执行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 上构建 Safari 原生 app 并上传。等待附件上传gh run list --workflow release.yml --limit 3 gh run watch RUN_ID --exit-status最后通过 Releases API 核对正文、tag、目标 commit、附件名称和大小。若 Release 已创建但文案需要修正使用gh release edit X.Y.Z --notes-file ...修改正文不会重新触发附件构建。六、商店提交publish-stores 工作流与凭据环境6.1 发布入口与触发方式商店发布入口是 .github/workflows/publish-stores.ymlPublish extension stores它构建并校验 Chrome、Firefox、Edge 三个包然后用wepub调用各商店 API。工作流只支持更新已有商店项目不创建新的商店条目。正式发布必须从不可变 tag 运行gh 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随后校验三个包内manifest.json的 version 是否与仓库 manifest 一致生成certification-notes.txt版本 source commit 最新提交说明后以extension-store-packages-version为名上传 artifact保留 14 天。三个发布 jobchrome/firefox/edge并行运行均使用browser-storesGitHub Environment。6.2 GitHub Environment 配置首次配置时在仓库的Settings Environments中创建browser-stores环境对应文档 docs/publishing.md 的首节。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凭据必须用 GitHub 加密存储Secret获取位置CHROME_CLIENT_IDGoogle Cloud 中启用 Chrome Web Store API 后创建的 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 页面凭据检查只用名称与更新时间不输出值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}不要把凭据写进仓库文件、Issue、Actions 日志或聊天记录。同时注意GitHub 会遮罩 Secrets但Variables 会明文显示在日志中因此 Variables 不得存放任何敏感值。6.3 Chrome 凭据的生成要点Chrome 使用 OAuth 访问 Chrome Web Store API凭据细节来自 references/store-publishing.mdCHROME_PUBLISHER_ID来自 Chrome Web Store Developer Dashboard 的Publisher SettingsCHROME_CLIENT_ID/CHROME_CLIENT_SECRETGoogle Cloud 中启用 Chrome Web Store API 后创建的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 状态签发的 refresh token 通常 7 天过期切换正式版后需重新完整授权并替换CHROME_REFRESH_TOKEN常见错误redirect_uri_mismatch表示 redirect URI 或 Client ID 不匹配403 access_denied且提示 testing表示登录账号不在 Test users或应用仍未切换正式版。6.4 Chrome 凭据的定期自检仓库提供了独立工作流 .github/workflows/check-chrome-credentials.ymlCheck Chrome credentials每周一北京时间 09:23cron23 1 * * 1UTC8定时运行也可手动触发。它复用browser-stores中的 Chrome 凭据先用 refresh token 换取临时 access token再调用只读的fetchStatus查询当前扩展不构建、不上传、不发布也不修改 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与配置一致出错时绝不输出响应体响应体可能含凭据只给出针对性建议invalid_grant→ 重新授权并替换CHROME_REFRESH_TOKENinvalid_client→ 检查 Client ID / Client Secret401/403 → 检查 OAuth scope、开发者账号访问与 publisher/item ID429/5xx → 服务限流或不可用稍后重试。该脚本的本地测试不需要真实凭据node --test scripts/check-chrome-credentials.test.mjs注意两个限制见 docs/publishing.md定时检查不能保证 refresh token 永不失效公开仓库连续 60 天没有活动时 GitHub 会自动停用定时工作流需要到 Actions 页面重新启用。6.5 Firefox 与 Edge 凭据要点Firefox在https://addons.mozilla.org/developers/addon/api/key/获取 JWT issuer→FIREFOX_API_KEY与 JWT secret→FIREFOX_API_SECRET。workflow 以listed渠道创建版本并上传可构建的源码归档不要把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 有过期日期需要轮换。七、运行与日志检查触发商店工作流后记录 run ID 并等待gh run list --workflow publish-stores.yml --limit 3 gh run watch RUN_ID --exit-status即使总 workflow 失败也要分别检查每个 job——其他商店可能已经成功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只展示与结论有关的日志片段避免在输出中保留可能泄露敏感信息的完整日志。八、成功判据四档状态严格区分技能文档要求最终报告必须分别列出 GitHub Release、Chrome、Firefox 和 Edge 的状态并区分上传成功 / 已提交审核 / 审核通过 / 公开上线。Chrome日志应依次出现the access token fetched the package archive uploaded, upload_stateSUCCEEDED the draft submitted, item_statePENDING_REVIEWPENDING_REVIEW表示已提交审核不是已上线公开商店仍显示旧版本属于正常现象。不要用相同版本重复上传来测试新的 refresh token。Firefox日志应出现 new version created 和 source archive uploaded。可用公开 API 验证https://addons.mozilla.org/api/v5/addons/addon/bilisponsorblock/只有当current_version为目标版本且status为public时才能报告公开上线。Edge日志应出现 package archive uploaded、upload processed、draft submitted、submission processed。最后一项表示已交给 Edge 认证流程不代表商店已公开。九、常见失败与停止条件技能文档给出了一套先停后查、按状态修复的排查表现象处理缺少变量/Secret停止在凭据检查不调用商店让用户在 GitHub Environment 中补齐Chrome 401 /invalid_grantrefresh token 无效、过期或与 Client 不匹配重新授权并只替换 refresh tokenChrome 已有相同版本或正在审核不要重复发布查询后台状态Firefoxversion already exists不要删除已创建版本确认第一次提交是否已成功Edge 404先检查 Product ID 是否为 Partner Center GUIDEdge 401/403检查 Publish API v1.1 的 Client ID、API key 与过期日期任一商店已成功、另一个失败仅重跑失败商店把成功商店的输入设为false连续失败时读取一次完整 job 日志根据 HTTP 状态修复不要盲目反复提交。审核中的商店应说明需等待且不承诺审核时间。十、完成标准与最终报告一次完整发版需要留下可核验结果SKILL.md 的完成标准manifest/manifest.json 是目标版本版本 commit 已推送按仓库惯例版本 tag 指向该 bump commit普通 CI、单元测试和 Playwright 测试通过同名 GitHub Release 已发布中文说明符合历史风格Release 的 Chrome、Firefox、Edge、Safari 四个附件上传成功商店 workflow 的每个启用 job 都有明确结果成功时记录审核状态失败时记录 HTTP 状态和可执行修复工作树干净且本地分支与远端同步。最终向用户分别报告 GitHub Release、Chrome、Firefox 和 Edge 的状态附 Actions run 链接并严格区分四档状态绝不把上传成功说成已上线。附与本文相关的仓库文件索引发版技能.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版本与构建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点击查看免费下载相关推荐BiliNote 发版全流程从 develop 分支到 Chrome / Edge / Firefox 商店上架BiliNote 发版全流程从 develop 分支到 Chrome / Edge / Firefox 商店上架 本篇是 BiliNote 开源仓库的发版执行AI 应用大模型RAG语音后端前端桌面应用Doorkeeper gem 版本发布全流程指南从 bump 版本号到 GitHub ReleaseDoorkeeper gem 版本发布全流程指南从 bump 版本号到 GitHub Release 本指南面向 DoorkeeperRuby on Rai后端认证鉴权如何高效完成Rnote发布流程从版本号bump到GitHub Release全指南如何高效完成Rnote发布流程从版本号bump到GitHub Release全指南 Rnote是一款功能强大的手绘笔记应用本文将详细介绍如何从版本号更新到G桌面应用图形学上一篇Torba钱包开发常见问题解答新手必看的完整手册下一篇Realtek 8192FU Linux USB无线网卡驱动完整安装指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考