update-screenshots

作者: microsoft

从最新的CI运行中下载截图基线并提交。当被要求更新、接受或刷新来自CI的组件截图基线时使用,或…

npx skills add https://github.com/microsoft/vscode --skill update-screenshots

Update Component Screenshots from CI

Screenshot images are not stored in the repository — they live in an external service (hediet-screenshots.azurewebsites.net), keyed by commit SHA. But a subset of fixtures is pinned by hash in test/componentFixtures/blocks-ci-screenshots.md, and that file is committed. When those hashes change, CI fails and you must update the file.

Two different outcomes, only one of which blocks

The Screenshots & Tests job in .github/workflows/component-fixtures.yml produces two independent results:

ResultBlocking?Action
Screenshot diff report (PR comment with before/after images)No — informationalReview the visuals. Nothing to commit.
blocks-ci hash mismatchYes — fails the checkUpdate blocks-ci-screenshots.md and commit.

A fixture opts into the blocking gate with labels: { kind: 'screenshot', blocksCi: true }. Only those fixtures appear in blocks-ci-screenshots.md.

The failure looks like this:

##[error]blocks-ci screenshot hashes do not match committed file. See PR comment or job summary for the updated content.

Step 1: Get the expected hashes from CI

Never regenerate the hashes locally. They are hashes of the rendered PNG bytes, produced on ubuntu-latest. Rendering on macOS or Windows yields different bytes and therefore different hashes, so locally generated values will fail CI. Always copy the values from the CI job.

Three surfaces carry the same content — use whichever is handy:

  • The PR comment titled "blocks-ci screenshots changed" (non-fork PRs only) — contains the full updated file plus a patch.
  • The job summary, which gets the identical body and is the only surface fork PRs receive.
  • The job log, whose final step prints a unified diff:
gh api repos/microsoft/vscode/actions/jobs/<JOB_ID>/logs > "$TMPDIR/ci-job-log.txt"
grep -n '##\[error\]' "$TMPDIR/ci-job-log.txt"

Find the failed job id with:

gh pr checks <PR> --json name,link,bucket --jq '.[] | select(.name == "Screenshots & Tests")'

Step 2: Verify the change is intentional before accepting it

This gate exists to catch unintended layout regressions, so accepting new hashes without looking at the images defeats its purpose. The images are publicly fetchable by hash, so pull both the old (committed) and new (from CI) versions and compare:

curl -sL -o old.png "https://hediet-screenshots.azurewebsites.net/images/<OLD_HASH>"
curl -sL -o new.png "https://hediet-screenshots.azurewebsites.net/images/<NEW_HASH>"

Then view them, and localize the change rather than eyeballing full screenshots — the delta is often only a pixel or two:

python3 -c "
from PIL import Image, ImageChops
a = Image.open('old.png').convert('RGB'); b = Image.open('new.png').convert('RGB')
print('diff bbox:', ImageChops.difference(a, b).getbbox())
"

Confirm the delta matches what the PR intends. If the fixture is unrelated to the change, or the shift is larger than expected, treat it as a regression and fix the code instead of the hashes.

Step 3: Apply and commit

Edit only the changed lines in test/componentFixtures/blocks-ci-screenshots.md, replacing the old hash in the image URL with the new one:

#### editor/inlineChatZoneWidget/InlineChatZoneWidget/Dark
![screenshot](https://hediet-screenshots.azurewebsites.net/images/<NEW_HASH>)

The file is generated by build/lib/screenshotBlocksCi.ts and compared byte-for-byte, so keep the <!-- auto-generated by CI — do not edit manually --> header, the #### <fixtureId> / image-link pairing, the blank line between entries, and the fixtureId sort order intact. Verify your edit is the exact inverse of the diff CI reported:

git diff test/componentFixtures/blocks-ci-screenshots.md

Then commit and push. The check re-runs and should pass; hashes on main become the new baseline after merge.

Investigating further

Raw captured images and the manifest for a run are uploaded as an artifact:

gh run download <RUN_ID> --name screenshots --dir .tmp/screenshots

manifest.json maps each fixtureId to its imageHash and any render errors.

Related failures from the same job

The check also fails if a fixture failed to render (Fail if fixtures had errors) or if the Playwright fixture tests failed. Those are genuine bugs — updating hashes will not help. Look for ::error::<fixtureId>: in the log, and download the playwright-test-results artifact for test failures.

来自 microsoft 的更多技能

oss-growth
microsoft
OSS增长黑客角色
agent-framework-azure-ai-py
microsoft
使用Microsoft Agent Framework Python SDK(agent-framework-azure-ai)构建Azure AI Foundry代理。在创建使用AzureAIAgentsProvider的持久化代理、使用托管工具(代码解释器、文件搜索、网络搜索)、集成MCP服务器、管理对话线程或实现流式响应时使用。涵盖函数工具、结构化输出和多工具代理。
development
airunway-aks-setup
microsoft
在AKS上设置AI Runway——从裸集群到运行模型。涵盖集群验证、控制器安装、GPU评估、提供商设置和首次部署。适用场景:“设置AI Runway”、“接入AKS集群”、“安装AI Runway”、“airunway设置”、“将模型部署到AKS”、“在AKS上进行GPU推理”、“在AKS上配置KAITO”、“在AKS上运行LLM”、“在AKS上使用vLLM”、“在AKS上设置模型服务”、“AI Runway控制器”。
devops
appinsights-instrumentation
microsoft
使用Azure Application Insights对Web应用进行插桩的指南。提供遥测模式、SDK设置和配置参考。适用场景:如何对应用进行插桩、App Insights SDK、遥测模式、什么是App Insights、Application Insights指南、插桩示例、APM最佳实践。
devops
applicationinsights-web-ts
microsoft
使用Application Insights JavaScript SDK(@microsoft/applicationinsights-web)为浏览器/Web应用添加检测。用于真实用户监控(RUM)——页面视图、点击、AJAX/fetch依赖项、异常、自定义事件,以及与后端OpenTelemetry追踪关联的浏览器端GenAI代理追踪。涵盖SDK加载器脚本和npm设置、框架扩展(React、React Native、Angular)、点击分析、遥测初始化器,以及从浏览器发出的代理/工具/模型跨度所遵循的OTel GenAI语义约定。
devops
azure-ai-anomalydetector-java
microsoft
使用适用于 Java 的 Azure AI 异常检测器 SDK 构建异常检测应用程序。在实现单变量/多变量异常检测、时间序列分析或 AI 驱动的监控时使用。
development
azure-ai-language-conversations-py
microsoft
使用azure-ai-language-conversations Python SDK实现对话语言理解(CLU)。当使用ConversationAnalysisClient分析对话意图和实体、构建NLP功能或将语言理解集成到应用程序中时使用。
development
azure-ai-ml-py
microsoft
Azure Machine Learning SDK v2 for Python。用于机器学习工作区、作业、模型、数据集、计算资源和管道。 触发词:“azure-ai-ml”、“MLClient”、“工作区”、“模型注册表”、“训练作业”、“数据集”。
development