Repository navigation
fix(scripts): report the Ghostty commit in getNativeInfo - #53
Conversation
…metadata Change-Id: If7f5fc46e537b53ad51e8f9e835e1eabf7e0c2a0 Signed-off-by: Thomas Kosiewski <tk@coder.com>
Change-Id: I841b1a0cb9e8045476ba4b64efc251a9520d5e37 Signed-off-by: Thomas Kosiewski <tk@coder.com>
Change-Id: Id8f3288c9d7a669f6050edcf12baf0971fc0b05a Signed-off-by: Thomas Kosiewski <tk@coder.com>
Change-Id: I4747f017191717165409d5e9e78494dca97f095c Signed-off-by: Thomas Kosiewski <tk@coder.com>
Change-Id: If400eb84b3afd75e42ff7ddda6599d398c1b5a07 Signed-off-by: Thomas Kosiewski <tk@coder.com>
|
@codex review |
|
@codex security review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Codex Review: Didn't find any major issues. Keep them coming! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
🛡️ Codex Security ReviewSecurity review completed. No security issues were found in this pull request. Reviewed commit: Only the user who started this review can view the report in Codex. ℹ️ About Codex security reviews in GitHubThis is an experimental Codex feature. Security reviews are triggered when:
Once complete, Codex will leave suggestions, or a comment if no findings are found. |
## Why Ship the fixes merged since `v0.1.0-beta.3` to npm, so downstream projects such as agent-tty can update. The consumer-visible change is #53: `getNativeInfo()` now reports the Ghostty commit the addon was built from (`ghosttyCommit`), and `ghosttyVersion` reads `0.1.0-dev+<commit>`. ## What changed - `package.json` and `package-lock.json` go from `0.1.0-beta.3` to `0.1.0-beta.4`. The branch name matches the version, so `publish.yml` creates `v0.1.0-beta.4` after merge. - The `release-changelog` workflow adds the CHANGELOG entry to this branch. ## Scope - Included since beta.3: #53 (Ghostty commit in `getNativeInfo()`), #51 (7-day `min-release-age` for this repo's own npm installs, `devEngines` npm >= 11.10), #52 (verify skill scripts, not in the npm tarball), #50 (skill sync, not in the tarball). ## Blast Radius The merge publishes `0.1.0-beta.4` to npm under the `beta` dist-tag. `latest` stays on `0.1.0-beta.0`. The tarball's `package.json` now carries `devEngines`. npm checks it only for the project it runs in, and the #51 verifier installed a packed tarball with npm 9.9.4, 10.8.2, 10.9.8 and 11.20.0 (all exit 0). `.npmrc` is not in the tarball. ## Verification - `prepare-release-changelog.mjs` prints `should_generate=true` and `version-changed`. `resolve-npm-publish-tag.mjs` prints `beta`. - Local gate on this branch with Node 26.12.1: results posted as a PR comment. --- _Generated with [`xum`](https://github.com/coder/xum) • Model: `anthropic:claude-opus-5-5` • Thinking: `high`_
Why
The goal is that every open issue on this repo is fixed and lands on main. Issue #45:
getNativeInfo()cannot tell a consumer which Ghostty commit the addon was built from. It returnsghosttyVersion: "0.1.0-dev"and noghosttyCommit. The build script already knows the commit, so it now passes the commit to Ghostty's build as libghostty-vt version metadata. The addon already reads that metadata intoghosttyCommit.Closes #45
What changed
scripts/build-libghostty-vt.shpasses-Dlib-version-string=<lib_version>+<commit>tozig build.lib_versioncomes from the checked-out Ghosttybuild.zig. The script exits 1 beforezigruns when it cannot read that value.<commit>isgit rev-parse HEADafter the checkout, andghostty-source.jsonrecords the same value.getNativeInfo()now returnsghosttyCommit: "83fb95624b0439ee660c2679b43b38c8b63769cd"andghosttyVersion: "0.1.0-dev+83fb95624b0439ee660c2679b43b38c8b63769cd". The native code does not change.test/load.test.tschecksghosttyCommitagainstghostty-source.json. The docs andNativeInfoTSDoc describe both fields.Scope
ghosttyVersionstays libghostty-vt's own version, now with the commit as build metadata. It is not the Ghostty release (1.4.0). The docs say so, andghosttyCommitis the field that names the Ghostty source.Tradeoffs
-Dlib-version-string=1.4.0+<commit>. Then libghostty-vt would report a version that is not its own, and most pins are not release tags.binding.gypread fromghostty-source.json. That needs a native change and a second source of truth. The build option keeps the commit inside the static library, which is how Ghostty's ownnix/libghostty-vt.nixsets it.Blast Radius
Every build through
npm run build:libghostty, CI prebuilds included, now reports the commit. The installed.pcfiles also showVersion: 0.1.0-dev+<commit>. Nothing here reads them. A local checkout built before this change fails the new test until you rerunnpm run build:libghostty && npm run build:native. The test's failure message says so.Verification
npm run build:libghosttyandnpm run build:native, thengetNativeInfo()throughsrc/:ghosttyCommitequalscommitinvendor/libghostty-vt/ghostty-source.json. Before the change, main returned{"napiVersion":10,"ghosttyVersion":"0.1.0-dev",...}with no commit.npm ci,build:libghostty,build:native,build,typecheck,npm test,smoke. The new test fails whenghostty-source.jsonnames another commit and skips without that file.zigruns when Ghostty'sbuild.zighas nolib_versionline, has two, or has a value with build metadata. Theinfo-fieldsjourney of the verify skill passed on the packed tarball.Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:xhigh