okooooooo/magpie

0 Fork 0

Files

T

History

yetone c91529f9aa ci: the UI preview scrolls to what a PR changes further down a page (owner: 录屏的时候，有时候需要录制的功能区需要滚动到下面才能看到，但是现在并不会滚动，导致录制的内容里完全没有 PR 所修改的功能) — the recorder reached an element with Playwright's scrollIntoViewIfNeeded, a scroll no reader asked for, which magpie puts back (scrollOnPurpose / backToReader in app.js), so the page stayed at its top; a shot's target was only a clip of the screen, never scrolled to, so a close-up of something below the fold showed the window's foot instead; and a scroll step turned the wheel wherever the mouse was. bringIntoView now wheels each view that hides the element, innermost first, in small notches with the drawn mouse over it, until it is in the middle (or at the top when taller): click, hover, type and a shot's target use it, and a scroll step takes "to" (a selector to bring into view). The planner's outlines mark elements past the fold of their view "(below the fold)" and its guide says a shot without a target shows only the screen. PLAN_FILE walks a given plan instead of asking DeepSeek. Tried against a sandbox magpie web with six providers and a fixed plan (a shot of Hermes Agent's models button, clicking it, scrolling to a Gateway row): the old recorder's close-up showed the list's foot without Hermes and its Gateway shot the page's top; the new one centres both, the menu opens at Hermes, and the video shows each scroll.

2026-10-03 15:18:01 +08:00

..

.gitignore

ci: a pull request that changes the UI shows it — the real app built from the PR, run with a real DeepSeek key, screenshots and, when the change spans pages or needs clicking, an mp4 recording with the pointer, its trail and every click drawn in, in a fixed block at the foot of the PR's description (the user: 如果某个PR涉及了UI/UX改动，那么就把这个PR中的Magpie真实的运行起来…录屏中一定要画出鼠标指针的位置，以及鼠标的轨迹，以及鼠标的点击; 一定要贴在原始的PR Description的下面的固定区域).

2026-09-30 14:22:13 +08:00

cursor.js

ci: a pull request that changes the UI shows it — the real app built from the PR, run with a real DeepSeek key, screenshots and, when the change spans pages or needs clicking, an mp4 recording with the pointer, its trail and every click drawn in, in a fixed block at the foot of the PR's description (the user: 如果某个PR涉及了UI/UX改动，那么就把这个PR中的Magpie真实的运行起来…录屏中一定要画出鼠标指针的位置，以及鼠标的轨迹，以及鼠标的点击; 一定要贴在原始的PR Description的下面的固定区域).

2026-09-30 14:22:13 +08:00

package.json

ci: a pull request that changes the UI shows it — the real app built from the PR, run with a real DeepSeek key, screenshots and, when the change spans pages or needs clicking, an mp4 recording with the pointer, its trail and every click drawn in, in a fixed block at the foot of the PR's description (the user: 如果某个PR涉及了UI/UX改动，那么就把这个PR中的Magpie真实的运行起来…录屏中一定要画出鼠标指针的位置，以及鼠标的轨迹，以及鼠标的点击; 一定要贴在原始的PR Description的下面的固定区域).

2026-09-30 14:22:13 +08:00

publish.mjs

ci: a UI preview goes by the diff, not the PR's description — on #287 the description (out of date) promised a 用量小数位 setting the code doesn't have, and the preview repeated it as the change, captioned a screenshot "默认 0 位" of a setting that wasn't there. The planner is told the description may be wrong, to plan and summarise from the diff, and what the sandbox lacks (subscription quotas above all); the preview now says, apart from the summary (改动（按代码）), where the description and the code disagree (描述与代码不符) and what the sandbox can't show (沙盒里看不到). Tested locally with run.sh on #287 's code: it names the missing setting, says the sandbox has only a DeepSeek balance and no percentage windows, and shows the two places the change would be.

2026-09-30 15:45:23 +08:00

README.md

ci: the UI preview records without waiting for approval (the user: 去掉批准吧) — the ui-preview environment keeps the DeepSeek key but no longer names a reviewer; the comments and the "recording" note stop mentioning one.

2026-09-30 15:07:06 +08:00

record.mjs

ci: the UI preview scrolls to what a PR changes further down a page (owner: 录屏的时候，有时候需要录制的功能区需要滚动到下面才能看到，但是现在并不会滚动，导致录制的内容里完全没有 PR 所修改的功能) — the recorder reached an element with Playwright's scrollIntoViewIfNeeded, a scroll no reader asked for, which magpie puts back (scrollOnPurpose / backToReader in app.js), so the page stayed at its top; a shot's target was only a clip of the screen, never scrolled to, so a close-up of something below the fold showed the window's foot instead; and a scroll step turned the wheel wherever the mouse was. bringIntoView now wheels each view that hides the element, innermost first, in small notches with the drawn mouse over it, until it is in the middle (or at the top when taller): click, hover, type and a shot's target use it, and a scroll step takes "to" (a selector to bring into view). The planner's outlines mark elements past the fold of their view "(below the fold)" and its guide says a shot without a target shows only the screen. PLAN_FILE walks a given plan instead of asking DeepSeek. Tried against a sandbox magpie web with six providers and a fixed plan (a shot of Hermes Agent's models button, clicking it, scrolling to a Gateway row): the old recorder's close-up showed the list's foot without Hermes and its Gateway shot the page's top; the new one centres both, the menu opens at Hermes, and the video shows each scroll.

2026-10-03 15:18:01 +08:00

run.sh

ui-preview: the sandbox has Claude Desktop, on magpie (#400 ) — the preview's home had Claude Code, Codex, Gemini and OpenCode but no Claude Desktop, so a PR changing Desktop's row (#399 : tier menu, model picker, gateway notice) recorded "not available". run.sh now makes $XDG_CONFIG_HOME/Claude, where magpie looks for Desktop on Linux (the runner), and runs magpie claude-desktop provider magpie, which writes Claude/ and Claude-3p/configLibrary in that home as the Agents page would; no Desktop app is installed. The CLI writes the folders where the OS keeps them, so a local run on macOS gets Desktop under ~/Library/Application Support too. Checked in a sandbox HOME (darwin): Desktop absent from magpie ls before, "provider magpie" after, its profile pointing at MAGPIE_ADDR 127.0.0.1:3430; the Linux path is TestDesktopDirs's. bash -n run.sh, go test -tags nogui ./internal/agent -run Desktop pass.

2026-10-01 15:51:54 +08:00

README.md

UI preview

.github/workflows/ui-preview.yml shows reviewers what a pull request does to the UI. When a PR touches internal/gui/assets/ or the GUI's Go code, or carries the ui-preview label, the workflow does this:

publish.mjs detect decides whether the PR is a UI change. It puts a "recording…" note in a fixed block at the foot of the PR description, between  and .
run.sh builds the PR's magpie (nogui) and runs magpie web in a fresh home, with DeepSeek added as a real provider. It sends a few requests through the gateway so Routing and Usage aren't empty, then runs:
record.mjs, which:
- gives DeepSeek the diff and outlines of the real pages;
- has it plan scenes: what to click, hover, type and capture;
- walks the plan in Chromium at 2x, with cursor.js drawing the pointer, its trail and each click. It always takes screenshots. When the change spans pages or needs interaction, it also records an mp4, never a GIF. If the key shows up on screen at any point, everything is thrown away.
publish.mjs publish puts the files under pr-<n>/<sha>/ on the ui-previews branch, which GitHub Pages serves, and rewrites the block in the description:
- the video's poster links to the player page, since GitHub won't embed a video it didn't host;
- the screenshots are shown inline.

Security: the recording job runs the PR's code without asking anyone. Any PR's code can therefore read DEEPSEEK_API_KEY (environment ui-preview), so the key there should have a low spending limit. That job has no write access, and the job that writes never runs the PR's code.

To run it locally (run.sh builds and starts magpie itself):

cd .github/ui-preview && npm install && npx playwright install chromium
DEEPSEEK_API_KEY=… DIFF_FILE=pr.diff PR_TITLE=… ./run.sh ../.. /tmp/out

To re-run it for a PR, use gh workflow run ui-preview.yml -f pr=<n>.