Azure Pipeline中Storybook构建产物上传至PR工件的可行性问询

答案是不行——主流代码托管平台（比如GitHub、GitLab）的PR系统根本没设计用来托管完整静态站点的能力。

为什么覆盖率报告看起来像是在PR里？ #

你提到的覆盖率报告，其实大多是把**摘要数据（比如覆盖率百分比、关键文件的覆盖情况）**内嵌到PR评论里，或者通过平台集成的工具提供一个内嵌的精简视图，但完整的HTML报告本质上还是托管在第三方服务或平台的专属存储里，并非直接存在PR本身。PR的附件/上传功能有严格的大小限制，而且不支持解析多文件依赖的HTML结构（比如Storybook需要的CSS、JS、静态资源），就算你硬传几个文件，也没法正常打开预览。

可行的替代方案（达到类似预览效果） #

• 用平台内置的分支预览服务：比如GitHub Pages可以为每个PR分支单独部署Storybook，通过GitHub Actions自动完成构建+部署，然后在PR评论里自动发布预览链接；GitLab Pages也支持类似的分支预览配置。
• 借助CI的Artifact功能：把Storybook构建产物作为CI运行的Artifact上传（比如GitHub Actions Artifacts、GitLab CI Artifacts），团队成员可以从PR的CI记录里下载产物本地打开预览，或者配合一些工具把Artifact转成临时在线预览链接（需要额外配置）。
• 自动化第三方静态托管：用Vercel、Cloudflare Pages这类工具的分支预览功能，CI触发后自动部署Storybook，然后在PR评论里插入生成的预览链接——这和你提到的Blob存储思路类似，但流程更自动化。

如果只是需要快速展示单个组件的静态效果，也可以把Storybook里的组件渲染成图片，作为PR附件上传，但没法交互。

内容的提问来源于stack exchange，提问作者Mor Shemesh