Adds a manual test_signing dispatch that uses GitHub-hosted runners, test-signing policy, signer verification, and run-summary request links without publishing a release.
* fix(server): 保留候选文本中的逗号和私用字符
* fix(server): render candidate frame from one snapshot
* fix(server): use captured preedit for sticky card key
* fix(server): dedup candidate frames by item-aware signature
Candidate text now keeps raw commas, so the comma-joined candidate_string
could make ["a,b","c"] and ["a","b,c"] share one frame signature and drop
a real page change as a duplicate repaint. Length-prefix each item instead.
Also serialize the WebView candidate items with the replace error handler
so an invalid UTF-8 translation gloss cannot throw on the UI thread, and
let CandidateWindowContent own its preedit and page snapshot rather than
referencing caller locals.
---------
Co-authored-by: fanlusky <1730976608@qq.com>
* ci: cache Engine compilation with sccache
* ci: verify Engine cache across commits
* ci: harden Engine sccache setup
- Fall back to plain cl.exe when the sccache server is unreachable
- Only report sccache stats when sccache was actually installed
- Also launch C compiles through sccache, matching the Server job
- Note why the Engine job must stay on Ninja Multi-Config
---------
Co-authored-by: fanlusky <1730976608@qq.com>
* ci(release): run the SignPath path on GitHub-hosted runners
SignPath's open-source plan accepts a signing request only when every job leading up to it ran on a GitHub-hosted runner, and tsf, server and package all ran on the self-hosted release machine. With WINDOWS_SIGNING_PROVIDER=signpath they now run on windows-2025, restoring vcpkg binaries and (for the Server) sccache the way ci.yml does; the certificate path keeps the self-hosted runner unchanged.
The org secret holding the SignPath API token is SIGNPATH_TOKEN, so the workflow and detect-release-signing.ps1 read that name instead of SIGNPATH_API_TOKEN.
AGENTS.md lists what SignPath needs configured, and the code signing policy records the accepted application and the hosted-runner rule.
* fix(ci): let the SignPath action read the run's artifacts
* fix(installer): drop authenticode-sign attributes SignPath Foundation rejects
* fix(ci): fail the hosted SignPath release before signatures are spent
- Probe ISCC with WizardStyle=modern dynamic and run that probe at the start of the hosted package job, so an image ISCC older than 6.6 fails before the payload signing request instead of after it.
- Verify the TSF vcpkg root before installing into it or saving its archives under the -complete key.
- Check the Server job's C:\vcpkg override against the vcpkg the hosted image puts on PATH.
- Code signing policy: drop the stale "once approved" wording and state that the hosted-runner rule applies to SignPath-signed releases.
* docs: list only the configured SignPath approver
---------
Co-authored-by: fanlusky <1730976608@qq.com>
The release job can now sign through SignPath instead of the certificate in the repository secrets. It only does so when the WINDOWS_SIGNING_PROVIDER repository variable is set to signpath, which nothing sets yet, so every release keeps taking the existing certificate path until a maintainer switches it.
On the SignPath path, scripts/ci/signpath-files.ps1 stages only the project's own binaries (the seven Server executables and both TSF DLLs) as the signing request's artifact, because SignPath Foundation does not allow signing the third-party DLLs vcpkg builds for the Server. The signed files are checked for a valid Authenticode signature before they replace the originals, and staging fails if a MetasequoiaIme* binary is missing from the list. The installer goes through a second request after it is compiled. installer/signpath/ holds the reviewed copies of the two artifact configurations to paste into SignPath.
detect-release-signing.ps1 fails the release when the provider is signpath but a SignPath setting is missing, or when the provider value is unknown, instead of falling back to the certificate or to an unsigned build.
The step that dispatches to MSIME-Web was gated on `github.event_name == 'workflow_dispatch'`. This workflow's own header documents workflow_dispatch as the repair path and a push to main as the normal one, so the notification only fired on the branch that almost never runs. MSIME-Web has received zero repository_dispatch events; its most recent twenty sync runs are all `schedule`.
That left the site waiting on a cron GitHub delivers about seven times a day instead of the forty-eight the schedule asks for, with measured gaps of two to five hours. Windows 0.8.0 published on 2026-09-20 and msime.app still offered 0.7.1 a day later.
The enclosing job already runs only when a release is being published, so the step needs no event condition at all.
The Server job's Build step dominates the pipeline (~6m37s of a ~9.5m job;
the dictionary/integration test is only ~43s). sccache caches individual
MSVC compiles across runs so an incremental change rebuilds only what it
touched instead of the whole server + engine tree.
sccache only caches an MSVC compile whose debug info is embedded in the
object, so switch the Server build's Release debug info from /Zi to /Z7.
The linker's /DEBUG still emits the beside-the-executable PDB the release
job validates, so the symbol layout is unchanged.
Its compiler-launcher hook is honoured only by the Ninja and Makefile
generators, so configure the Server build with Ninja Multi-Config (keeping
the --config Release / bin/Release layout the later steps depend on) and
add an MSVC-environment step, since Ninja does not locate cl.exe on its own.
The three self-hosted release jobs are separate runner instances on one
machine, so they share C:\Users\runner\.gitconfig and all reach "Trust the
runner workspace" in the same second. Two win the config lock and the third
dies with "could not lock config file ...: File exists", taking Build TSF x64
down before it compiles anything and skipping the installer job.
Retry the write, and re-read safe.directory before each attempt so a peer
instance having already trusted this path counts as success.
Two independent failures kept the v0.6.5 installer from being built after
the pipe probe was fixed.
The package job died in "Verify the release commit is on main" with git
exiting 128 on dubious ownership: runner instance 2 leaves _work owned by
SYSTEM while the job runs as `runner`. actions/checkout is unaffected, so
the first plain git call is what fails, and only jobs scheduled onto that
instance see it. Mark the workspace as safe in the three self-hosted jobs.
Neither vcpkg manifest carried a builtin-baseline, so vcpkg resolved ports
against the registry at HEAD and every build depended on a live fetch of
microsoft/vcpkg. When that fetch degraded, the ports simply vanished:
Fetching registry information from https://github.com/microsoft/vcpkg (HEAD)...
fmt does not exist
utfcpp does not exist
Build TSF x64 failed this way twice and passed twice on the same runner,
which is what an unpinned registry looks like. Pin both manifests to
04a9d8e5, the commit vcpkg-lock.json already records as resolved.
