[pull] main from daijro:main - #26
Merged
Merged
Conversation
… every launch (#808) * fix(juggler): pace a humanized move on its own schedule sendTrajectoryAcked waited each point's full pause after the previous point's ack, so every ack's round trip was added to the move: it took its plan plus one round trip per point. On a page whose main thread is busy 19ms in every 20, moves capped at 0.5s took 0.54-0.71s. Each point is now due at its planned offset from the start of the move, so a late ack delays only its own point and the move ends on its planned time. tests/patches/humanize-pacing.py times eleven capped moves on such a page and checks their median against the cap. It failed 3/3 before (medians 587-607ms) and passes after (484-487ms). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * fix(launch): write toggle prefs on every launch, on or off block_webrtc, block_images and disable_coop wrote their pref only when switched on. A persistent profile keeps a user.js pref in prefs.js, so removing the flag later left the setting in force. A real profile launched once with block_webrtc still had media.peerconnection.enabled false long after, and BrowserScan reported WebRTC disabled. Each pref is now written every launch, with the stock value when its flag is off. A caller's own firefox_user_prefs entry still wins. The same change is made in the TypeScript launcher, with its tests. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…ry release with its browser (#810) * Pair each library release with the browser build it was tested with Nothing tied a library release to a browser build: `camoufox fetch` took the newest build in a channel, and a launch used whatever config.json marked active, so an upgraded library could run a browser it was never tested with, and an old library would pick up a newer, incompatible browser. A released package now carries browser-pin.json, naming the browser release built from the same sources. With it, and no explicit choice by the user: - fetch installs exactly that build (no prerelease prompt: it is the build this release was tested with, prerelease or not); - a launch uses exactly that build, whatever else is installed or active, and reports it as not installed rather than falling back to another; - the fetcher's automatic install (TypeScript's first run) takes only it. An explicit `camoufox set` still wins, with a one-time warning at launch; `camoufox set --release` returns to the paired build, and `camoufox active` says which is in use. The checked-in pin is `{}`, so development checkouts follow their channel as before. Also: prerelease library versions (0.5.8b1, 0.5.8-beta.1) parse as their release; they were read as 0.5.0. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Release a prerelease on every tested merge; promote to stable by tag Every merge to main whose tests pass now publishes a prerelease of all three artifacts, and pushing vX.Y.Z on a tested main commit promotes it. - Build and Release runs after Tests on main. It builds the browser only when its sources changed (ci.browser_inputs.source_digest: every browser input, not counting the release number). Each build gets the next unused beta.N on a release commit beside main -- main is protected -- and is published as a GitHub prerelease, not a draft, with its source digest in the notes. - Publish to pypi follows it: <next>bN on PyPI, then Publish to npm puts <next>-beta.N under the `next` dist-tag. Both are stamped with the browser release built from the same sources. - A vX.Y.Z tag is refused unless the commit is on main and `All tests passed` succeeded on it. The paired browser prerelease then becomes the stable, latest release (no rebuild, so users get the tested binaries), and X.Y.Z goes to PyPI and npm `latest`. The tested commit travels between workflows as an artifact: a workflow_run is told main's head, so two quick merges would otherwise publish the second, untested one. ci/release.py holds the planning, stamping and promotion, unit-tested in ci/tests/test_release.py. Also fixes two checks that failed the manual release already: vermin targeted Python 3.8 exactly, against a package that declares ^3.10 and a code base that needs 3.9, and check-pack compared npm and PyPI prerelease versions as strings, although each registry spells them differently. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Test driver-only pull requests against the release paired with their sources The scope step matched the release tag named by upstream.sh. With release numbers now allocated per build, that number is a floor, not a release, so driver-only pull requests would nearly always rebuild, or fetch a build other than the one their sources produce. It now asks `ci.release paired` for the release built from exactly this tree's browser sources, and fetch-browser installs it through the same pin a released package carries. Documents the release flow in ci/README.md. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * pythonlib: replace asyncio.to_thread so the 3.8 vermin gate passes publish-pypi.yml checks the package with `vermin . --eval-annotations --target=3.8 --violations camoufox/`, and asyncio.to_thread (Python 3.9+) in _resolve_proxy_geo failed it, stopping the 0.5.7 release. loop.run_in_executor does the same off-loop lookup. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Pair with releases cut before the digest marker, and test the pairing against the step The scope step now asks ci.release paired, which only knew releases whose notes carry a source digest. None does yet: v156.0.1-beta.32, the release built from main's sources, predates the marker. So every driver-only pull request would have rebuilt the browser, the first merge would have cut a duplicate beta.33, and the two scope tests in ci/tests/test_ci.py -- which ran the step in a scratch repo where ci.release did not import -- failed. find_paired falls back to the tag upstream.sh names when that release is published (a prerelease counts; a draft does not) and no browser source changed since, listing the files that did when they have. browser-plan and promote use the same lookup. paired takes --root and --releases so the tests run the workflow's own step against a scratch repo and a fixed release list. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Release from one workflow, with trusted publishing The release chain was four workflows linked by workflow_run, with the tested commit carried between them as an artifact; a browser release number committed beside main; pairing data in HTML comments in release notes; a stored PyPI token; and packages rebuilt at each publish. release.yml now does all of it with `needs`: - On a push to main it calls tests.yml on the pushed commit (tests.yml loses its own push trigger), then builds the browser only when its sources changed, and publishes a library prerelease only when something a package ships changed. Docs- and CI-only merges publish nothing. - A browser release's number lives only in its tag, which points at the tested main commit; `ci.release set-build` writes it into the build's working tree. Nothing is committed. - Each browser release carries a manifest.json asset (source digest, commit), which is what a library pairs by. Builds are attested with actions/attest-build-provenance. - Both packages are built once, in build-library, and the publish jobs upload exactly those files. PyPI and npm use trusted publishing; no credential is stored. - A vX.Y.Z tag builds and checks both packages before promoting the paired browser and publishing. - Every published library version is tagged (vX.Y.ZbN for a prerelease), which is how the next merge tells whether the library changed. - A failed publish is retried with "Re-run failed jobs"; the retry-only workflow_dispatch path is gone. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )