前端网络安全【免费下载链接】AdguardBrowserExtensionAdGuard browser extension项目地址https://gitcode.com/gh_mirrors/ad/AdguardBrowserExtension点击查看免费下载AdGuard Browser Extension 是一个同时面向 Chrome、Edge、Firefox、Opera 等浏览器分发的开源扩展其构建产物既要发布到各浏览器官方商店Chrome Web Store、Mozilla Add-ons、Edge Add-ons又要自托管到官方静态服务器用于自分发更新还要附带 Chrome 的 CRX 自更新通道与 GitHub Release 附件。为了支撑如此复杂的多渠道发布项目在 DEPLOYMENT.md 中系统性地定义了以Atlassian Bamboo为核心的构建/部署管道体系。本文以该文档为主体结合仓库内真实的 Bamboo 配置、Dockerfile 多阶段构建与工具脚本完整讲解 beta、release 以及两条 Firefox beta 管道的设计思路、部署目标、手动发布步骤与故障排查方法帮助读者掌握从版本提升、本地校验到云端签名、多渠道部署的完整链路。管道总览四类构建与部署计划DEPLOYMENT.md 用一张表格概括了整个仓库的 CI/CD 拓扑每一类产物都由独立的Build plan构建计划和Deploy plan部署计划组成二者通过 Bamboo 的source-plan字段关联。类型Build planDeploy plan部署目标BetaADGEXT-BEBETASPECSdeploy betastatic.adtidy.org、Chrome WebStore MV3、GitHubReleaseADGEXT-BERELEASESPECSdeploy releasestatic.adtidy.org、Chrome WebStore MV2、Chrome WebStore MV3、Addons Mozilla、Edge Add-ons、GitHubFirefox standalone betaADGEXT-BEFIREFOXSTANDALONEBETASPECSdeploy firefox standalone betastatic.adtidy.org、GitHubFirefox AMO betaADGEXT-BEFIREFOXAMOBETASPECSdeploy firefox amo betaAddons Mozilla所有计划定义在bamboo-specs/目录中并通过 bamboo-specs/bamboo.yaml 统一注册。该文件本身并不包含计划内容而是通过 YAML 的!include指令按顺序导入各计划构建计划build-beta.yaml、build-release.yaml、build-firefox-standalone-beta.yaml、build-firefox-amo-beta.yaml部署计划deploy-beta.yaml、deploy-release.yaml、deploy-firefox-standalone-beta.yaml、deploy-firefox-amo-beta.yaml权限计划permissions-beta.yaml、permissions-release.yaml、permissions-firefox-standalone-beta.yaml、permissions-firefox-amo-beta.yaml配套计划tests.yaml、e2e-tests.yaml、increment.yaml版本自增、auto-build.yaml、auto-publish.yaml及其权限文件。由此可以看出AdGuard 的发布体系遵循“一个发布渠道 一个构建计划 一个部署计划 一份权限声明”的三件套模式四个渠道互不干扰。Beta 管道构建与部署的完整生命周期构建计划两阶段校验Beta 的构建计划ADGEXT-BEBETASPECS定义于 bamboo-specs/build-beta.yaml包含两个 stageSize and locales check尺寸与语言包校验并行执行两个 job——Check Bundle Size通过 Docker 目标bundle-size-check-output运行pnpm ${BUILD_TYPE} --zip与pnpm check-bundle-size betaCheck translations通过 Docker 目标locales-check-output运行pnpm locales validate --min。Build构建通过 Docker 目标beta-build-output执行pnpm beta --zip产出build.txt、chrome.zip、chrome-mv3.zip、edge.zip随后再通过beta-chrome-crx-output目标执行pnpm beta chrome-crx额外产出chrome.crx与update.xml用于 Chrome 的自更新通道。构建完成后计划还会执行 VCS 打标签任务生成v${bamboo.inject.version}-beta标签并将构建号注入到后续部署步骤中。所有产物声明为shared: true的共享产物供部署计划下载。部署计划三个环境Beta 的部署计划定义于 bamboo-specs/deploy-beta.yamlsource-plan: ADGEXT-BEBETASPECSrelease-naming: ${bamboo.inject.version}-beta包含三个 environmentstatic.adtidy.org下载chrome.zip、chrome-mv3.zip、build.txt、chrome.crx、update.xml然后执行./bamboo-deploy-publisher/deploy.sh chrome-extension-beta发布 Chrome beta 扩展包Chrome WebStore MV3仅下载chrome-mv3.zip执行deploy.sh browser-extension-webstore-beta将 MV3 beta 发布到 Chrome Web Store 的Experimental实验性MV3 条目GitHub下载chrome.zip、chrome-mv3.zip、edge.zip、chrome.crx、build.txt使用 Bamboo 变量bamboo.githubPublicRepoPassword作为 GitHub Token执行deploy.sh browser-extension-github-beta将各浏览器 bundle 附件到 GitHub beta Release。每个环境的任务模板高度一致clean→checkout部署发布器仓库bamboo-deploy-publisher→artifact-download按需拉取产物 → 执行deploy.sh子命令。这种“一次构建、按环境挑产物”的写法是整组部署 YAML 的通用模式。Release 管道覆盖全部商店渠道构建计划Release 构建计划ADGEXT-BERELEASESPECSbamboo-specs/build-release.yaml与 beta 结构相同Size check Build 两个 stage但构建覆盖所有浏览器目标Chrome MV2、Chrome MV3、Edge、Opera、Opera MV3、Firefox AMO、Firefox standalone。构建产物包括chrome.zip、chrome-mv3.zip、edge.zip、opera.zip、opera-mv3.zip、firefox.zip由firefox-amo.zip重命名而来、source.zip与approval-notes.txt。同样会执行inject-variables与 VCS 打标签v${bamboo.inject.version}。部署计划六个环境Release 部署计划定义于 bamboo-specs/deploy-release.yamlrelease-naming不再带-beta后缀环境清单static.adtidy.org同时执行deploy.sh chrome-extension-release与deploy.sh firefox-extension-release。DEPLOYMENT.md 特别强调此位置必须同时保留chrome.zip和chrome-mv3.zip因为不同浏览器例如 Brave会从这里拉取静态构建包使用Chrome WebStore MV2下载chrome.zip执行deploy.sh browser-extension-webstore-release-mv2Chrome WebStore MV3下载chrome-mv3.zip执行deploy.sh browser-extension-webstore-releaseAddons Mozilla下载firefox.zip、source.zip、approval-notes.txt执行deploy.sh browser-extension-amo向 AMO 提交Edge Addons下载edge.zip执行deploy.sh browser-extension-edge向微软 Edge 插件商店提交GitHub下载全部 bundle 与build.txt执行deploy.sh browser-extension-github-release发布 GitHub Release。注意 Chrome WebStore 的 MV2 与 MV3 是两个独立环境、独立执行脚本而 AMO 渠道之所以需要source.zip与approval-notes.txt是因为 Mozilla 的审核流程要求附带源码包与构建复现说明详见后文“源码归档”小节。Firefox Beta 双管道为什么必须拆分Firefox beta 存在两种彼此独立的分发形态Standalone独立签名版由 Mozilla 通过go-webext签名后自分发用户通过update.json更新通道自行安装AMO商店托管版提交到 Mozilla Add-ons 审核列表由 AMO 在审核期间完成签名。DEPLOYMENT.md 用专门一节解释了“Why two Firefox beta pipelines”standalone 版需要等待 Mozilla 的签名服务go-webext在等待期间最长可阻塞到20 分钟的 CI 超时此前两种形态共用同一套构建/部署计划一次缓慢或失败的签名会连带阻塞 AMO 的提交。拆分后AMO 的构建与提交完全不受 standalone 签名状态影响反之亦然。Standalone Firefox Beta 管道构建计划ADGEXT-BEFIREFOXSTANDALONEBETASPECSbamboo-specs/build-firefox-standalone-beta.yaml只有一个 jobBuild and Sign Standalone通过两次docker build完成先构建firefox.zipDocker 目标firefox-beta-build-output对应 Dockerfile 中pnpm beta firefox-standalone --zip再用adguard/extension-builder:22.22--0.4.1--0镜像预装了go-webext执行签名Docker 目标firefox-beta-sign-output产出firefox.xpi与update.json。签名阶段通过--build-context firefox-artifactsoutput/artifacts复用第一步的产物AMO 凭据通过--build-arg FIREFOX_CLIENT_ID与--secret idFIREFOX_CLIENT_SECRET传入。签名命令为go-webext -v sign firefox -f firefox.zip -s source.zip -o firefox.xpi -n $(cat approval-notes.txt)共享产物为build.txt、firefox.zip、firefox.xpi、update.json。当 Mozilla 签名缓慢触发 20 分钟超时时重跑同一次构建即可——重跑是安全的因为幂等性位于go-webext而非 Bamboo第二次运行时它会检测到该版本已上传至 Mozilla跳过重复上传、轮询签名状态并下载已签名的.xpi。管道层面没有任何需要重试的逻辑。部署计划browser extension - deploy firefox standalone betabamboo-specs/deploy-firefox-standalone-beta.yamlstatic.adtidy.org→deploy.sh firefox-extension-beta更新通道产物为firefox.zip、firefox.xpi、update.json、build.txtGitHub→deploy.sh browser-extension-github-beta-firefox将firefox.zip、firefox.xpi追加到 GitHub beta Release。AMO Firefox Beta 管道构建计划ADGEXT-BEFIREFOXAMOBETASPECSbamboo-specs/build-firefox-amo-beta.yaml只有一个 jobBuild AMO通过 Docker 目标firefox-amo-beta-build-output执行pnpm beta firefox-amo --zip产出未签名的firefox-amo.zip。AMO 托管的附加组件不在本地签名由 Mozilla 在审核时签名因此该管道完全不受go-webext阻塞。共享产物为build.txt、firefox-amo.zip、source.zip、approval-notes.txt。部署计划browser extension - deploy firefox amo betabamboo-specs/deploy-firefox-amo-beta.yaml只有Addons Mozilla一个环境执行deploy.sh browser-extension-amo-beta将firefox-amo.zip source.zip approval-notes.txt一并提交给 AMO 审核。如何发布一个 Firefox Beta两个 build plan 都声明了triggers: []与branches.create: manually意味着只能由人在 Bamboo 上手动触发。DEPLOYMENT.md 给出的操作顺序同时运行standalone与AMO两个构建计划二者独立、可并行各自完成后运行对应的部署计划两个部署计划相互独立可按任意顺序单独或同时执行若 standalone 签名超时不要阻塞 AMO让 AMO 照常提交待 Mozilla 签名完成后重跑 standalone 构建以取回签名后的.xpi。准备一次新发布七个关键步骤DEPLOYMENT.md 指出以下步骤对 beta 与 release 均适用差异点会分别标注。下面结合 package.json 中真实存在的脚本逐一展开。在package.json中提升依赖库版本。需要更新的通常是adguard/tsurlfilter、adguard/tswebextension、adguard/scriptlets等近期发布过的库。当前仓库中的依赖版本可作参照adguard/tsurlfilter: 6.0.3、adguard/tswebextension: 5.0.3、adguard/scriptlets: 2.5.1。命名规则beta 使用-beta后缀如5.5.0-betarelease 使用正式版本如5.5.0。设置TSURLFILTER_REF以禁用本地链接。仓库内的 bamboo-specs/scripts/clone-tsurlfilter.sh 默认TSURLFILTER_REF此时不会克隆 tsurlfilter 源码、直接使用 npm 版本只有当该变量指向某个分支、commit 或 tag 时才会用git archive克隆干净的源码目录并通过 bamboo-specs/scripts/link-tsurlfilter.sh 以pnpm link的方式链接本地构建的tswebextension可选附带agtree、tsurlfilter、dnr-converter、css-tokenizer。发布前必须置空因为库已发布到 npm。clone-tsurlfilter.sh的注释还解释了为什么用git archive而非裸 cloneDocker 会对--build-context中每个文件做 checksum 以决定缓存是否命中而裸 clone 的.git元数据每次克隆都不同、必然击穿缓存git archive则能产出字节一致的输出从而让 tsurlfilter 构建阶段命中缓存、耗时趋近于 0。运行pnpm dev确保 scriptlets 脚本是最新的对应 package.json 中dev: cross-env BUILD_ENVdev tsx tools/bundle.ts。运行pnpm resources pnpm resources:mv3更新过滤规则、公共后缀列表与 DNR ruleset。resources:mv3脚本会先pnpm remove adguard/dnr-rulesets、再pnpm add -D adguard/dnr-rulesets~5.0最后执行 tools/resources-mv3.ts产物落入Extension/filters/下的各浏览器目录如Extension/filters/chromium-mv3/declarative/的各个ruleset_*JSON。构建并检查包体积Betapnpm beta --zip然后pnpm check-bundle-size betaReleasepnpm release --zip然后pnpm check-bundle-size release。若尺寸差异在可接受范围内运行pnpm update-bundle-size beta或release更新基准否则需排查体积增长原因。体积检查的实现见 tools/bundle-size/check.ts 与 tools/bundle-size/constants.ts常量值含义DEFAULT_SIZE_THRESHOLD_PERCENTAGE10默认允许的体积增长阈值百分比可由 CLI--threshold覆盖MAX_MV3_SIZE_BYTES30 MBChrome MV3 构建的硬性上限MAX_FIREFOX_AMO_SIZE_BYTES200 MBAMO 提交整体大小上限MAX_FIREFOX_SIZE_BYTES4 MBAMO 对 zip 内单个文件的限制Firefox 浏览器本身并不强制检查工具同时还会检测 MV3 bundle 是否超限、通过pnpm why检测重复的包版本并把历史数据写入.bundle-sizes.jsontools/bundle-size/update.ts 负责用最新构建统计刷新该基准文件。运行pnpm locales validate校验翻译文件如发现问题则创建翻译任务分发给译者。Bamboo 构建中对应的自动化校验是 Docker 目标locales-check-output内的pnpm locales validate --min。合并 PR 并在 Bamboo 中触发构建。此外仓库还通过increment.yamlbamboo-specs/increment.yaml在每次构建后自动递增版本号构建产物increment-output会把修改后的package.json复制回工作树并执行 VCS commit提交信息为skipci: Automatic increment build number。package.json中的版本号5.5.23.build.20260825090125正是该机制的产物。部署权限控制每个部署计划都配有对应的permissions-*.yaml遵循“部署计划name必须与权限文件中的deployment.name完全一致”的约束。以 bamboo-specs/permissions-firefox-standalone-beta.yaml 为例部署级权限extensions-developers与adguard-qa两个组拥有view权限环境级权限static.adtidy.org与GitHub环境仅对extensions-developers开放viewdeploy。permissions-firefox-amo-beta.yaml 采用相同模式仅环境改为Addons Mozilla。因此当某个部署计划报权限错误时应优先核对部署 YAML 的deployment.name与权限 YAML 的deployment.name是否逐字符一致这是 Troubleshooting 一节明确给出的排查方向之一。源码归档与 AMO 审核配套产物Firefox 渠道AMO 与 standalone 签名都要求提交source.zip和approval-notes.txt二者由 bamboo-specs/scripts/archive-source.sh 在 Docker 构建阶段生成。该脚本的要点打包全部源码文件排除.git/、.gitignore命中的模式以及Extension/filters/目录但保留Extension/filters/firefox的过滤规则因为 Firefox 构建需要它们在source.zip内的README.md末尾追加“Building Instructions for Firefox Add-ons Review Team”章节给出仅依赖 Docker 的构建复现命令例如docker run --rm \ -v $(pwd):/workspace \ -w /workspace \ adguard/extension-builder:22.22--0.4.1--0 \ bash -c pnpm install pnpm release firefox-amo并分别列出 AMO beta扩展 IDadguardadblockeramobetaadguard.com与 standalone beta扩展 IDadguardadblockerbetaadguard.com对应的pnpm beta firefox-amo/pnpm beta firefox-standalone命令同步生成纯文本的approval-notes.txt通过 AMO API 的approval_notes字段提交让审核员无需解包源码即可看到构建说明。archive-source.sh依赖同目录下的 bamboo-specs/scripts/generate-find-excludes.sh在宿主机上、.git可用时生成gitignore-excludes.txt与parse-gitignore.sh容器内.git不可用时的回退方案。Docker 多阶段构建管道背后的构建矩阵所有构建产物都来自仓库根目录的 Dockerfile采用多阶段构建配合 Bamboo YAML 中docker build --target ...的调用方式。以下 stage 与 DEPLOYMENT.md 描述的管道一一对应Docker 目标对应计划/阶段主要产物bundle-size-check-outputbeta/release 的 Size check体积检查标记文件locales-check-outputbeta/release 的 Check translations语言包校验标记文件beta-build-outputBeta Buildbuild.txt、chrome.zip、chrome-mv3.zip、edge.zipbeta-chrome-crx-outputBeta Build第二阶段chrome.crx、update.xmlfirefox-beta-build-outputFirefox standalone beta 构建firefox.zip由firefox-standalone.zip重命名、update.json、source.zip、approval-notes.txtfirefox-beta-sign-outputFirefox standalone beta 签名firefox.xpi依赖--build-context firefox-artifactsfirefox-amo-beta-build-outputFirefox AMO beta 构建firefox-amo.zip、source.zip、approval-notes.txtrelease-build-outputRelease Build全部浏览器 zip source.zipapproval-notes.txtincrement-outputincrement 计划修改后的package.jsonDockerfile 还包含tsurlfilter-buildstage当TSURLFILTER_REF非空时从命名构建上下文复制 tsurlfilter 源码并执行pnpm installlerna run build构建adguard/tswebextension与adguard/dnr-rulesets为空时则跳过直接使用package.json声明的 npm 版本对应发布流程步骤 2。Troubleshooting常见故障与处理DEPENDENCY.md 的 Troubleshooting 一节针对四个高频问题给出明确处理路径Standalone 签名超时20 分钟Mozilla 响应慢时的预期行为不影响 AMO。等 Mozilla 完成签名后重跑同一构建计划即可取回.xpi。幂等性在go-webext侧第二次运行会识别出版本已上传、跳过重复上传、轮询签名状态并下载签名产物Bamboo 只是再次调用同一个签名步骤管道层面无需任何重试逻辑。部署失败、缺少产物多半是部署计划在源构建计划完成之前被触发或构建本身失败。确认源构建计划已产出全部共享产物后重跑部署。AMO 与 standalone 相互干扰理论上不应发生——它们是独立的计划与独立产物。若出现串扰逐个核对每个部署计划的source-plan是否指向正确的构建计划并确认两个构建计划基于同一 commit/版本运行。部署计划权限错误部署 YAML 中的name必须与对应权限 YAMLpermissions-firefox-standalone-beta.yaml/permissions-firefox-amo-beta.yaml中的deployment.name完全一致。小结AdGuard Browser Extension 的发布体系是“Bamboo 计划编排 Docker 多阶段构建 部署发布器脚本”三层结构的典型实践构建阶段统一在 Docker 内完成、产出可共享的制品部署阶段按渠道挑取产物、分发到自托管静态服务器、各浏览器商店与 GitHub ReleaseFirefox 特有的“独立签名”与“AMO 审核”双管道通过彻底解耦来规避签名阻塞。对于希望理解该项目发布机制、或参考其 CI/CD 设计的读者建议从 DEPLOYMENT.md 入手对照本文涉及的 bamboo-specs/bamboo.yaml、bamboo-specs/build-*.yaml、bamboo-specs/deploy-*.yaml、Dockerfile 与 tools/bundle-size/ 逐一阅读即可还原整条从“提交代码”到“商店上架”的完整链路。赞分享前端网络安全【免费下载链接】AdguardBrowserExtensionAdGuard browser extension项目地址https://gitcode.com/gh_mirrors/ad/AdguardBrowserExtension点击查看免费下载相关推荐Bitwarden 浏览器扩展Browser Extension开发与构建指南基于 Web Extension API 与 Angular 的多浏览器实现Bitwarden 浏览器扩展Browser Extension开发与构建指南基于 Web Extension API 与 Angular 的多浏览器实现前端桌面应用CLI应用安全AdGuard Browser Extension 危险规则检测工具深度解析基于 OpenAI API 的过滤器安全审查AdGuard Browser Extension 危险规则检测工具深度解析基于 OpenAI API 的过滤器安全审查 导读 本文聚焦 AdGuard Br前端网络安全基于 Builder.io 插件体系构建 Campaign Builder 应用从零开发到发布部署全指南基于 Builder.io 插件体系构建 Campaign Builder 应用从零开发到发布部署全指南 导读 本文围绕仓库中 plugins/example前端低代码CMS上一篇7个核心技巧掌握Temporal工作流设计从异步通信到状态管理的实战指南下一篇Node.js CORS中间件终极指南从零到实战配置创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考