check-dictionary-contract.py compares scripts/dictionary_product.py against the engine's own copy, so the job needs the submodule's contents and not just its gitlink. The reusable workflow this job replaced checked out submodules; the rewrite dropped that.
The script reported a missing file as "differs from the pinned Engine contract", which describes a drift that had not happened and sends the reader looking for a content change. It now says the file is missing and how to get it.
The product lock existed because five repositories had to be pinned to reproduce one product. Four of them are directories now, so a commit of this repository already pins them and there is nothing left for the lock to say about them. What it still records is what the product consumes from outside: the engine submodule, the helpcodes and the dictionary release.
CI gains a job per component instead of a reusable workflow that checked out locked commits and rebuilt them. The release workflow no longer stages five sibling checkouts under historical names and no longer carries a second sparse checkout for its own scripts; Prepare-PackageFiles.ps1 already took the source directory names as parameters, so it is told the new ones, plus where the product-wide notice now lives.
Two checks the removed cross-repository pins used to provide are replaced in kind: the pages are verified against the engine submodule's web contract in CI rather than by locking UiHtml and Engine together, and the engine bump triage that Server carried moves here and now also says so when a bump leaves the lock behind.
Every other piece of shell in these workflows lives in scripts/ci and the workflow only wires it up. The language probe went in inline, so it did not: twenty lines of PowerShell building an .iss heredoc inside a YAML block scalar, which is the least reviewable and least runnable place to put it.
Same check, now in check-inno-language.ps1, and runnable by hand on a Windows machine. It falls back to the system temp directory when RUNNER_TEMP is unset so that running it outside CI works.
Every release build since the packaging pipeline landed has failed at "Compile the installer", which is why the last eight versions are still unpublished drafts:
Error on line 63 in msime_setup.iss: Couldn't open include file
"c:\program files (x86)\inno setup 6\Languages\ChineseSimplified.isl"
install-inno-language.ps1 derived the destination from `Get-Command ISCC.exe`. On the windows-2025 image Inno Setup comes from Chocolatey, so that resolves to the shim at C:\ProgramData\Chocolatey\bin\ISCC.exe and the file was written to C:\ProgramData\Chocolatey\bin\Languages\. ISPP resolves compiler: against the real installation. The step printed "Installed ... (21516 bytes)" and exited 0, and the build failed two steps later pointing at a path nothing had written to, which is why this survived eight releases.
The installation is now located by a file only it has -- ISPPBuiltins.iss or Default.isl, neither of which sits beside a shim -- checking the uninstall registry key, the two Program Files locations and any ISCC.exe on PATH, and failing with the list it tried rather than falling back to a guess.
ci.yml now compiles a throwaway script whose only content is a [Languages] entry pointing at compiler:Languages\ChineseSimplified.isl. Asserting the file exists at a path this script computed would only restate the script's own belief; compiling is what proves ISCC agrees. The URL and digest pin moved into the script so that check does not need a second copy of them.
Reverts the switch to calendar versioning, before it produced a release here.
release-please has no CalVer strategy, so the switch reset the version series by hand and pinned always-bump-patch. What that analysis missed is what release-please does to the changelog when the series it is walking no longer connects to the tag history: on MSIME-Apple it rewrote the whole file into a single 158-line 2026.9.1 entry that listed every feature since the first pull request as though it had just shipped. MSIME-Linux got a 64-line one. This repository had not released yet, so there is no changelog damage to undo and reverting now costs nothing.
Restores the 0.0.17 baseline across version.txt, .release-please-manifest.json and the version resource, drops always-bump-patch from the release-please config, and removes the monthly rollover workflow. The next release goes back to the previous series.
The three version lines the switch was meant to unify stay unaligned. That problem is real but wants a mechanism that does not fight release-please.
The signing certificate allows a limited number of signatures, so a release costs something finite. It should not be spent by merging a pull request.
Until now a push to main was enough to spend one: release-please opened the release pull request, merge-release-pr.sh merged it, the merge commit came back through this workflow as release_created, and the build jobs signed two binaries and an installer and published the result. Nobody had to ask for any of that.
should_publish is now true only for workflow_dispatch, and the package job -- the only one that signs -- states that condition itself rather than inheriting it from four other jobs whose conditions a later edit could quietly change.
Auto-merging the release pull request goes with it, since that is the mechanism that turned a merge into a release, and leaving it would also mint a draft release and a tag on every merge to main that nobody intends to build. What remains automatic is getting a passing check onto that pull request, which is not optional: GITHUB_TOKEN cannot start a workflow run, so without the dispatch in check-release-pr.sh the release pull request has no checks at all and required_status_checks (#121) leaves it permanently unmergeable.
Releasing is now two deliberate steps. Merge the release pull request, which creates the draft release and its tag and builds nothing. Then run the Release workflow against that tag. Dispatching the same tag twice is already refused by validate-draft-release.sh, because a published release is no longer a draft, so a retry cannot quietly spend a second signature.
The three platform frontends of one product carried three unrelated version lines: Windows 0.0.17, Linux 0.6.0 and Apple 0.41.0, all built on the same engine. A user reporting a problem with "0.41" said nothing about which platform they were on, and the main product carried the lowest number of the three.
All three now start from 2026.9.0. Every platform moves up, so no update mechanism sees a downgrade: Sparkle compares components numerically, the Windows update manifest accepts any dot-separated digits, and 2026.9.0 is a valid and higher version for both dpkg and rpm.
release-please has no CalVer strategy — its only options are default, always-bump-patch, always-bump-minor, always-bump-major, service-pack and prerelease — so always-bump-patch is pinned to walk the last component within a month, and .github/workflows/calver-rollover.yml moves the year and the month. Without that workflow the date in the version would freeze and keeping it truthful would become a manual edit somebody has to remember, which is the failure this project has already been bitten by elsewhere.
The lock pins immutable commits, but nothing checked that anybody merged them. Today it pins server 40d85a4 and engine 9a4b0c6, both of which exist only on architecture/product-contracts branches, and a release built from this commit would have shipped and attested to a Server that never reached main. The release job's existing provenance check covers only the TSF commit being released, not the inputs the lock names.
verify-published compares each locked commit against its own repository's default branch and accepts only behind or identical, the two states that mean it is an ancestor. ahead and diverged both mean the commit sits on something nobody merged.
It runs in the release path and deliberately not in product-ci.yml. A pull request legitimately locks branch commits while one change lands across several repositories at once, which is exactly the situation this branch is in; enforcing reachability in pull request CI would deadlock the landing it exists to protect. At release time the judgement inverts, because an input that never reached its default branch is an input nobody reviewed.
The step ran only when release-please reported a pull request as created, which is once. It rewrites
that branch on every later push to main, and a release pull request that could not be merged the
first time is never retried -- main advancing during the build is the normal way that happens, and
the script deliberately leaves the pull request open in that case, so the two together meant it
would sit there forever.
Finding the branch through git/matching-refs and then its open pull request covers both: a rewritten
head gets a fresh build, and a pull request left open gets picked up on the next push. Taken from
MSIME-Linux#38, which caught the same mistake in the equivalent change there.
MSIME-Windows#121 records that CI cannot be made a required check here, because release-please's
pull request never gets one: GITHUB_TOKEN may not start workflows, so the pull_request run is
created in action_required and waits for a human forever.
I previously wrote on that issue that the only way out was a GitHub App or PAT. That was wrong.
workflow_dispatch is the exception GitHub allows GITHUB_TOKEN to fire, and MSIME-Apple's release
automation has been relying on it all along. Checked its release branch: workflow_dispatch runs
exist there and succeed, alongside pull_request runs that do not.
Also checked the two alternatives that looked cheaper, and neither works:
- A push trigger on release-please--** produces nothing. Every run on that branch in MSIME-Linux
is a pull_request event; a GITHUB_TOKEN push creates no run at all. MSIME-Linux#31 merged on
the belief that it does.
- The approval policy is not the cause. All six repositories are already on
first_time_contributors_new_to_github, the loosest setting, and bot-triggered runs are still
gated. Comparing runs, the gate tracks triggering_actor exactly: github-actions[bot] gives
action_required, houko gives success.
So merge-release-pr.sh now dispatches ci.yml on the release branch, polls for the run at that exact
head commit, and waits for it with --exit-status before merging. The checks land on the pull
request's head commit, which is what required_status_checks needs.
It also re-reads main and the pull request head afterwards: main can advance during a build, and
merging then would rebase the release commit onto something that was never tested.
ci.yml gains workflow_dispatch so it can be dispatched at all. The paths-ignore stays: it keeps the
unapprovable pull_request run out of the checks list, leaving only the dispatched run's results,
which avoids two check runs with the same name and different outcomes on one commit.
The prepare job gains actions: write, without which gh workflow run cannot dispatch.
MetasequoiaImeUiHtml and msime-installer are MSIME-UiHtml and MSIME-Installer;
both actions/checkout steps resolved only through GitHub's rename redirect.
The staging directory names are deliberately untouched. Lines 28 and 122 of
this file record why: msime-installer's Prepare-PackageFiles.ps1 expects
siblings called MetasequoiaImeServer, MetasequoiaImeUiHtml and so on, and
staging under those names is what lets it run unmodified in CI. Repository
names are current, checkout directory names stay historical.
The TSF jobs failed with:
The term './scripts/ci/check-tsf-dll.ps1' is not recognized as a name of a cmdlet, function,
script file, or executable program.
Those jobs check the product out at the draft release's target commit, and then ran scripts/ci
from that checkout. scripts/ci arrived later than the commit v0.0.12 points at, so the directory
simply was not there. The same trap applies to every script the packaging job runs: a workflow
change can always outrun the scripts present at the tag being built, and it means the commit being
released could substitute its own release automation.
Each job that runs a script now checks the automation out separately from the default branch, the
way MSIME-Apple's release workflow does. The product still comes from the release commit; only the
automation is pinned to the branch the workflow itself came from.
Also here, since they are all .github correctness:
The UiHtml checkout named metasequoiaime/MetasequoiaImeUiHtml, which now resolves only through the
rename redirect to MSIME-UiHtml. A release pipeline should not depend on that; if anyone ever
creates a repository at the old name the redirect stops. The MetasequoiaIme* paths elsewhere in the
file are staging directory names the installer scripts require, and a comment now says so, so they
do not get "fixed" later.
The issue templates offered components under the pre-rename names, and the QQ group contact link
pointed at the old repository URL while the documentation link pointed at MetasequoiaIME, which
redirects to MSIME-Docs.
ISSUE_TEMPLATE/config.yml was not valid YAML: the QQ group about text contains a bare "QQ Group: ",
and a colon followed by a space cannot appear in a plain scalar. It predates this change; quoting
the value fixes it.
Two checkout pins dependabot could not reach, because the steps did not exist on main when it ran,
are brought up to the version the rest of the file uses.
release.yml had grown thirteen inline shell and PowerShell blocks, some of them twenty lines, which made the workflow hard to read and impossible to lint or run outside Actions. Each one is now a file under scripts/ci and the workflow only wires them up.
Two things fall out of the move rather than being separate changes. The two signing steps were near-duplicates and are now one sign-binaries.ps1 taking a path list, used for both the packaged binaries and the finished installer. The pinned Inno Setup language file URL and checksum move to the packaging job's env, where they read as configuration instead of being buried mid-script.
The Server job now checks this repository out into automation/ for its two scripts. That checkout has to come after the MSIME-Server one, because checkout cleans its destination and the workspace root would take automation/ with it.
shellcheck is clean on all six shell scripts. The PowerShell is not syntax-checked here for lack of pwsh, but four of the seven are verbatim from steps that already ran green in run 33953797415.
Packaging got all the way to compiling and then aborted:
Error on line 61 in msime_setup.iss: Couldn't open include file
"c:\program files (x86)\inno setup 6\Languages\ChineseSimplified.isl"
msime_setup.iss declares a chinesesimplified language pointing at compiler:Languages\ChineseSimplified.isl, and the Inno Setup on the runner does not ship that file. A developer machine has it because it was installed by hand at some point.
The packaging job now fetches it into the Languages directory next to the resolved ISCC.exe before compiling, skipping the download when it is already there. Pinned to a jrsoftware/issrc commit and checked against its SHA-256, so the installer's Chinese text cannot change under a rebuild. The file was verified to be the 6.5.0+ message set, which matches the 6.7.1 on windows-2025.
Everything before this step passed in run 33953797415, including Prepare-PackageFiles.ps1 collecting the payload, so this is the last thing between the workflow and an actual exe.
release-please opens its pull request as github-actions[bot] using GITHUB_TOKEN, and GitHub does not let GITHUB_TOKEN start workflows, so CI on that pull request lands in action_required and waits for someone to press approve. That stalled the release: nothing moves until the pull request is merged, and the pull request looks unfinished until CI runs.
The prepare job now merges the pull request it just created. The resulting push runs this workflow again, release-please converts the release commit into the draft release, and the build jobs take over, so a conventional commit on main now reaches a published installer without anyone clicking through.
Merging without CI is safe here because the pull request only rewrites version.txt, CHANGELOG.md and .release-please-manifest.json. For the same reason the CI workflow now ignores those three paths on pull requests, which stops each release from parking an unapprovable run in the checks list.
This is the same shape as MSIME-Apple's merge-release-pr.sh step.
The Server job failed linking MetasequoiaImeSettings:
LINK : fatal error LNK1181: cannot open input file
'D:\a\MSIME-Windows\MSIME-Windows\build\vcpkg_installed\x64-windows\lib\WebView2Loader.dll.lib'
MSIME-Server's CMakeLists.txt hardcodes ${CMAKE_SOURCE_DIR}/build/vcpkg_installed at lines 257, 369 and 412, for the WebView2 loader and two include paths, so the binary directory has to be literally named build. Its own CI uses -B build and never hits this; this workflow used -B build-release to match the layout Prepare-PackageFiles.ps1 reads from.
The directory name here does not actually need to match, because the packaging job downloads the Server artifact into MetasequoiaImeServer/build-release/bin/Release itself. Building in build/ keeps this in step with MSIME-Server's own green CI and leaves the staged layout unchanged.
The release build failed at "Verify the stamped version" on both architectures. Stamping worked, the log shows "Stamped 0.0.10.0 into src\IME\MetasequoiaIME.rc (4 fields)", but reading the DLL back gave an empty string.
The VERSIONINFO block in src/IME/MetasequoiaIME.rc is named IDR_VERSION2, which is not defined in resource.h or anywhere else, rather than the VS_VERSION_INFO that GetFileVersionInfo looks for. So the DLL has never carried a version Windows can read, and the check asserted something the binary could never satisfy.
Stamping now runs apply_version.py followed by --check, which verifies the resource actually matches version.txt. The step on the built artifact is reduced to confirming the DLL the installer collects exists.
Making the version readable would mean renaming the resource to VS_VERSION_INFO, which changes what the shipped DLL exposes, so it is left alone here.
The Windows installer has been produced by hand: build the TSF DLLs and the Server locally, build the settings page, copy dictionaries out of a developer checkout, then run the msime-installer scripts against a self-signed certificate. This automates that end to end, keeping the same artifact name the releases have always carried, MetasequoiaIME_Setup_v<version>.exe.
The workflow follows the shape of MSIME-Apple's release.yml. release-please owns version.txt and opens a release PR; merging it creates a draft release, which the publish path then builds and fills in. A manual dispatch can rebuild an existing draft tag, and validates that the tag matches version.txt at an immutable commit SHA before anything is built.
Four jobs feed the packaging job: the TSF DLLs for x64 and Win32, the Server Release build, and the settings page. msime-installer needs no changes because the packaging job stages each checkout under the historical directory name its scripts already address, so Prepare-PackageFiles.ps1 and Compile-Installer.ps1 run unmodified. windows-2025 ships Inno Setup 6.7.1, above the 6.6 the scripts require.
Dictionaries are not rebuilt here. They are downloaded from a dict-* release of metasequoiaime/MSIME-Dict and checked against its SHA256SUMS.txt, with the Mozc IPAdic / ICOT / Okinawa notice placed where Prepare-PackageFiles.ps1 expects so it reaches the installed product.
Signing follows the pattern MSIME-Apple uses: sign when the certificate secrets are configured, otherwise publish with an -unsigned suffix and say in the release notes that uiAccess will not take effect. Sign-PackageBinaries-Local.ps1 mints a self-signed certificate for local testing and is never invoked here.
release-please cannot drive the VERSIONINFO block in the resource script, which spells the version both as a comma quad and as a dotted string, so scripts/apply_version.py stamps it from version.txt before the release build configures CMake. It also has a --check mode. The committed resource moves off the stale 1.0.0.1 placeholder to the current 0.0.9.
The manifest starts at 0.0.9 rather than the four-part 0.0.9.2 that semver cannot express, so the next release will be 0.0.10, which still sorts after every existing tag.
dependabot[bot]