Mmilind-soniCI: Linux shards run four test files at once
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
fix(browser): suppress Windows consoles for Chrome children | 21 天前 | |
CI: a merged PR no longer cancels main's CI run (#2240) ci-stop-closed.yml joined the group ci-${{ github.ref }} to stop a closed PR's run. For a merged PR the closed event reports the base branch as github.ref, so the stop run joined main's group with cancel-in-progress and cancelled main's CI in the same second, on every merge. Every main run since 07:55 UTC on Oct 3 was cancelled this way. PR runs now share a group named by the PR number (ci-pr-<n>) in both workflows; main and merge-queue groups are unchanged. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> | 1 个月前 | |
CI: Linux shards run four test files at once Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> | 1 天前 | |
MausBot connector: run a Cloud home on its owner's own server, over one outbound connection (#3732) A new connector/ folder, published with every release as ghcr.io/milind-soni/mausbot-connector for linux/amd64 and linux/arm64. - install.sh (curl ... | sudo sh -s -- <code>) checks the server, and says how to fix each failure in plain words: operating system, x86-64, Docker 24+ (offering to install it), AppArmor, user namespaces, CPU, memory, disk, network and clock. It installs the bot box's AppArmor and seccomp profiles, starts the connector, runs the box probe and enrols with the one-time code. Running it again repairs. uninstall never deletes the data unless --delete-data is typed. - The connector enrols once, then holds one WebSocket to the Admin, re-opened with backoff. Every 30 s it sends a heartbeat: host health, and the home's state, image and signed health. It runs only the protocol's jobs: start, stop, restart, update, status, backup, restore, export-disk, import-disk, host-health and self-update. - There is no shell, arguments are checked, and images must be our registry's, by digest. - Replies are sent again on each connection until the Admin acknowledges them. - update copies /data aside, swaps the container, and waits up to 10 minutes for the new image's signed health. Otherwise it puts back the previous image and the copy. - A home that stopped on its own is started again. Until the image clears it itself, the connector first clears the data-directory lease a killed home leaves. - self-update keeps the running connector until the new one has connected; one atomic rename settles which one won. - The agent token and the home's environment are kept 0600 in the state volume and never logged. - connector/src/protocol.ts holds the message types and checks, for the Admin side to copy. Tests: unit tests with a fake Docker, and a fake Admin over a real WebSocket. An end-to-end run on a stock Ubuntu 24.04 runner (connector-e2e.yml) covers install, start with the box at 32/32, update, an unclean kill, a forced rollback and uninstall. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> | 8 天前 | |
MausBot connector: run a Cloud home on its owner's own server, over one outbound connection (#3732) A new connector/ folder, published with every release as ghcr.io/milind-soni/mausbot-connector for linux/amd64 and linux/arm64. - install.sh (curl ... | sudo sh -s -- <code>) checks the server, and says how to fix each failure in plain words: operating system, x86-64, Docker 24+ (offering to install it), AppArmor, user namespaces, CPU, memory, disk, network and clock. It installs the bot box's AppArmor and seccomp profiles, starts the connector, runs the box probe and enrols with the one-time code. Running it again repairs. uninstall never deletes the data unless --delete-data is typed. - The connector enrols once, then holds one WebSocket to the Admin, re-opened with backoff. Every 30 s it sends a heartbeat: host health, and the home's state, image and signed health. It runs only the protocol's jobs: start, stop, restart, update, status, backup, restore, export-disk, import-disk, host-health and self-update. - There is no shell, arguments are checked, and images must be our registry's, by digest. - Replies are sent again on each connection until the Admin acknowledges them. - update copies /data aside, swaps the container, and waits up to 10 minutes for the new image's signed health. Otherwise it puts back the previous image and the copy. - A home that stopped on its own is started again. Until the image clears it itself, the connector first clears the data-directory lease a killed home leaves. - self-update keeps the running connector until the new one has connected; one atomic rename settles which one won. - The agent token and the home's environment are kept 0600 in the state volume and never logged. - connector/src/protocol.ts holds the message types and checks, for the Admin side to copy. Tests: unit tests with a fake Docker, and a fake Admin over a real WebSocket. An end-to-end run on a stock Ubuntu 24.04 runner (connector-e2e.yml) covers install, start with the box at 32/32, update, an unclean kill, a forced rollback and uninstall. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> | 8 天前 | |
chore(contributors): remove mandatory DCO sign-off (#1029) | 1 个月前 | |
Say what stays behind when the bots move to My Cloud, and carry uvx connectors A connector that stays on the person's computer after a move to My Cloud was told only to the bots' prompt. The move's line said "Everything from this computer is here". - The move's line lists each connector that stayed, with why. - When the move ends, one bot says it in its own chat, with a notification; the first conversation with each other bot that could have used it says it once, as a notice row. - The bots' prompt says why it stayed, that it worked there before, and not to call it "never set up" or write a replacement. - The Cloud image carries uv and uvx, so a uvx connector moves as an npx one does, and a package runner's first start check waits for its download. - A mail connector (mcp-email-server, imap-mcp and the like) stays, and says why: its accounts are on the computer it was set up on, and a bot's box has no route to a mail server. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> | 1 天前 | |
fix(ci): verify docs when shared source assets change | 1 个月前 | |
fix(packaging): ship DuckDB and resvg with the npm package and Podman image The server loads @duckdb/node-api and @resvg/resvg-js at runtime through nativeRequire, outside the bundle. The npm package declared only the 1Password SDK, and the Podman image copied only dist-server and dist, so on both paths Data queries and chart PNG export failed with MODULE_NOT_FOUND. Declare both packages at the root package.json pins in the generated npm manifest. In the Podman Containerfile, stage the native tree with prepare-duckdb, copy it to /app/duckdb and set OMB_DUCKDB_DIR, as the main Dockerfile does. This also brings the 1Password SDK into the image. A test assembles the npm manifest from a synthetic checkout and checks the Containerfile staging. The npm-package workflow now installs the packed tarball's dependencies and runs a DuckDB query and a resvg render. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> | 10 天前 | |
Ship browser-ready desktop packages and verified self-hosting launch fixes (#899) * fix(server): harden remote requests and config event projections * fix(browser): unblock fresh installs and preserve configured Chrome path * docs(self-hosting): document verified Hetzner setup and recovery * feat(desktop): ship a verified browser-ready automation runtime * test(browser): reject unsandboxed container smoke environments * test(browser): retain bounded cold-start failure diagnostics * fix(linux): read procfs sandbox settings without premature EOF | 1 个月前 | |
fix(release): the Windows cloudflared check reads its digest from the pin file #3658 moved cloudflared to 2026.10.3 but release.yml and package-win.yml still compared the packaged cloudflared.exe with the old build's digest, so 0.1.130's Windows build failed its packaged-tree check. Both workflows now read the digest from scripts/prepare-cloudflared.mjs, the third-party README is regenerated from the same pins (it still listed the old build's digests, and lacked Linux arm64), and a test keeps workflows free of hard-coded digests and the README in step with the pins. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> | 8 天前 | |
ci: record locale source hashes at release, not in every PR A translated key without a recorded hash now counts as current, so a PR that adds keys with their translations no longer touches src/locales/source-hashes.json. A recorded hash that no longer matches today's English still fails `pnpm i18n:check`, and hashes left behind by removed keys or languages are ignored. `node scripts/generate-locale.mjs --record-hashes` fills in the hash of every translated key that has none and drops removed ones. It never replaces an existing hash, so a stale translation stays stale. The release bump runs it next to tighten-ratchets and commits the file. The drafting tool agrees with the check: an unhashed translation is not re-drafted, and a newly drafted key gets its hash at release; a refreshed stale key still gets its new hash. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> | 9 天前 | |
Release: staple up to six times before failing the Mac build (#4043) Apple's ticket server dropped the connection during 0.1.136's staple (stapler error 68) after notarization had already been accepted, which cost the whole 20-minute Mac job. Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> | 4 天前 | |
ci: select relevant checks and consolidate merge gate (#1964) | 1 个月前 | |
fix(release): build and verify the Windows browser startup backport (#913) * build(browser): verify a pinned Windows-only vendor backport * fix(browser): propagate WebMCP opt-out to CLI children * fix(release): publish Docker after explicit release-tag dispatch * fix(release): keep dependency prereleases out of updater mirroring * build(browser): reproduce reviewed Windows stdio fix and gate daemon restart * fix(build): preserve exact browser vendor bytes on Windows | 1 个月前 | |
Windows: lend a PC's apps and screen, say plainly when it can't, and let a Cloud's bot ask to turn it on (#3950) * ci(windows): start computer control as the installed app does and lend it A Windows smoke that runs electron/cua.mjs's packaged branch unchanged, in Electron's main process, then takes a Cloud's first look at the PC through the lend path (computer_tools, get_screen_size, list_apps). It reports the driver's mode and whether apps and screen would be lent, and sends no input. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * ci(windows): settle each answer with a statement in the lend smoke Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(windows): lend a PC's apps and screen, say plainly when it can't, and let a Cloud's bot ask to turn it on Computer control on Windows starts once, at launch. When it didn't (a helper Windows Security stopped, or a slow first start), nothing tried again, nothing was recorded (the driver's error carried only its kind, and console output is lost in the packaged app), the app showed nothing and reported Windows as unsupported, and a Cloud's bot was told to have the person "check computer control", which no Windows screen offers, then offered its own cloud computer. - Computer control keeps the reason Windows gave and logs every change to the app's log. On Windows a start that failed for a passing reason is tried again by itself, twice; a blocked or missing helper waits for the person. - The taskbar or menu-bar icon says what the Clouds can't use and why, with the one fix ("Screen control isn't running on this PC", Start screen control). The Computer panel on a PC says the same with a Start button. - A Cloud's bot that needs the person's computer and can't use it calls ask_for_computer: one card with what it wants and why, the reason, and a one-tap Turn on (resume, start screen control, ask macOS, or run commands after the computer's own confirmation), or Get MausBot when the app there is closed, missing or too old. The app on that computer, paused or not, hears the ask and shows its own prompt once, one at a time; the first answer wins. Once the computer lends what was needed the bot's waiting call returns, or its request goes on by itself. Only on the person's own Cloud. - Every "not available" answer a bot gets there points it at the card, and the Cloud prompt says never to switch to its cloud computer unless asked. - The person can keep writing while a Turn on card waits. - CI's Windows CUA job runs for changes to the modules it starts. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test(lending): a neutral computer name in the ask tests Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs(lending): the help names the PC's screen-control status and the Turn on card, in the app's words Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(windows): the lent screen's driver gets Windows' own folders cua-driver 0.28.2 keeps its settings, history and cursor themes under LOCALAPPDATA and APPDATA; the lend path started its proxy without them. They hold no secret, and the app's keys still never reach it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * ci(windows): the lend smoke reports the lending decision the app makes, with why and the fix Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * ci(windows): on a pull request the lend smoke runs the base branch first, so one run shows the change Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs(lending): screenshots of the PC's status and the Turn on card, light and dark Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(lending): the ask's internal route answers from its own module, so server/index.ts gains no route Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Windows Defender check: build the real installer, install it like a download, and report what Windows Security does A hand-run job on a fresh GitHub Windows machine (workflow_dispatch, or the "defender-check" label on a pull request while the workflow isn't on main): builds the NSIS installer the way the release's Windows job does, turns Defender's protection on the way a home PC has it (GitHub's image turns most of it off and excludes every drive), saves the installer to Downloads with a browser's Zone.Identifier (ZoneId=3), scans it, installs it silently (first the way a double-click starts it), opens the app for two minutes and presses Start screen control through the app's DevTools port. The summary and the defender-check artifact say what the machine allowed, Defender's detections and Operational events 1116, 1117, 1006-1008 and 1015, whether cua-driver-background.exe runs, the app log's computer-control lines and whether Start screen control worked. The run fails when Windows Security flagged the app or screen control doesn't run. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Windows Defender check: show what holds a downloaded installer, and check Defender's cloud When the double-click start of the downloaded installer is still waiting after 30 s with no installer running, the check records the windows on screen, whether SmartScreen runs and a screenshot, then stops waiting instead of sitting out five minutes. It also records Defender's cloud connection (MpCmdRun -ValidateMapsConnection), the signatures' age, what GitHub's passive-mode policy means on a machine Defender reports in Normal mode, and a screenshot of the app after two minutes. A workflow test keeps the check's build step for step the same as the release's Windows job. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Windows lend smoke: read electron-builder.yml the same with CRLF line endings git checks electron-builder.yml out with CRLF on a Windows runner, so the smoke found none of the CUA resources it places and stopped before starting anything (the first CI run that reached the Windows CUA job). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> | 5 天前 |