Run the suite against each new chdb-core release - #76
Merged
Conversation
The test job builds against the engine pinned in update_libchdb.sh, so it stays green through anything chdb-core changes after that pin. The addon's C++ does get a compile error out of a changed signature, but only against the header it was handed; a struct that changes layout without changing its declaration produces no error at all. Either way nobody finds out until the pin moves. chdb-core now dispatches here when it publishes a release. This runs the suite against that engine on all four platforms and opens an issue with the verdict, closing it again when green. A red result does not mean the pinned engine broke — update_libchdb.sh is untouched — it means adopting the new one needs addon work first. One Node version rather than three: what is under test is the C ABI, and that does not vary by Node version. Platform does, so all four stay. CHDB_ENGINE_VERSION is deliberately not CHDB_LIB_VERSION, which already means the npm subpackage version and is read from LIBCHDB_NPM_VERSION. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The pinned engine moves to CHDB_ENGINE_PIN, a literal line of its own, so the release check can find and rewrite it. The value and the behaviour are unchanged. When the check passes it opens a pull request moving that line, which is the only edit adopting an engine requires. Green says the engine can be adopted, not that it has been; that stays a review. LIBCHDB_NPM_VERSION is deliberately left alone. It names the @chdb/lib-<platform> subpackages, which are decoupled from the engine on purpose, and publishing new ones carrying a new engine is a separate decision from testing against it. Those pull requests carry no checks. GitHub does not start workflow runs for commits a workflow pushed with GITHUB_TOKEN, and re-running CI on the branch would exercise the same suites against the same engine the check just finished with. The body says so rather than leaving a reviewer to wonder. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The report job checks nothing out, and gh does not fall back to GITHUB_REPOSITORY. Every run would have failed at gh issue create, before reaching the close, so the whole reporting path was dead — and it never showed up in CI, because this workflow only runs from a dispatch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
$GITHUB_REF_NAME is the default branch for a repository_dispatch, but a manual run from another branch would root the bump commit there and open the pull request against it, and a run from a tag would fail outright. Both the checkout and the base now name the default branch explicitly. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
A bump PR closed without merging leaves engine-pin-<version> on the remote. The next run creates the branch fresh from the default branch, so pushing it is a non-fast-forward and is rejected — costing the adoption PR while the verdict issue still reports a pass, which reads as though nothing needed adopting. Two dispatches for the same version race the same way. The push replaces the branch when it already exists. No open PR uses it, which the check above already established, and its only content is one generated line. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The version arrives from a dispatch payload or a typed input and is interpolated into a sed replacement, a branch name, a URL and a commit message. sed is the sharp edge: an & in a replacement expands to the whole match, so a tag like v9&evil rewrites the pin line to CHDB_ENGINE_PIN=v9CHDB_ENGINE_PIN=v26.5.0evil and the bump PR carries it, while a | ends the substitution early and fails with "bad flag in substitute command". Escaping for sed would fix sed alone. Restricting the value to what a chdb-core tag actually contains covers every place it is used at once, and rejects rather than mangles. Verified that v26.5.0, v26.5.1-rc.1 and v26.7.1.882-stable pass while &, |, backslash, spaces and semicolons are refused. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The verdict and the close both came from needs.test.result, so a green suite whose propose_bump failed filed as "passes", linked no adoption PR, and closed itself. That reads as "nothing needed adopting" — the one reading that is wrong. It is also the state every repository starts in: without "Allow GitHub Actions to create and approve pull requests" the bump job gets a 403 on the first real run. needs.propose_bump.result now feeds in. A bump that failed or was cancelled keeps the issue open and says which of the two usual causes to look at. A bump that succeeded without opening anything — already pinned, or a PR already open — still closes, because nothing is wrong in that case. Exercised all three outcomes against a stubbed gh: green closes and links the PR, a failed bump stays open with the explanation, a failed suite stays open with the ABI pointer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
propose_bump checked out the default branch tip at bump time, not the tree the test job ran against. The four-platform matrix takes tens of minutes; a default branch that advances meanwhile puts the new engine pin on binding code nothing tested, while the pull request body says the suite passed. github.sha is fixed for the whole run, so checking that out makes the claim true. Rooting the branch there means it can be behind the default branch, which is honest and what GitHub already shows. It also reintroduces the case the previous commit removed — a manual run from a branch that is not the default one would carry that branch;s other changes into the bump — so the compare API decides: identical or behind means the tested commit is on the default branch, anything else declines to propose. Verified the three statuses against real refs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Accepting a "behind" compare status rooted the bump at the tested commit but still opened it against the default branch, so merging adopted the engine together with whatever landed while the matrix ran — commits no run exercised against that engine. Nothing would catch it either: the bump carries no CI by design, so the pull request would be merged on the strength of a body describing a run that never saw that code. The check now requires "identical". When the default branch has moved it declines and reports why, and the verdict issue stays open saying the engine is fine, the pin is unchanged, and the check wants a rerun. Given how rarely these repositories take a commit during a release, declining costs a rerun; the alternative costs a claim that is not true. Exercised all four report outcomes against a stubbed gh: green closes and links the PR; a failed bump job, an unproposed bump and a failed suite each stay open with their own explanation. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Author
|
@wudidapaopao, please review this PR |
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The test job builds against the engine pinned in
update_libchdb.sh, so it staysgreen through anything chdb-core changes after that pin. The addon's C++ does get
a compile error out of a changed signature, but only against the header it was
handed; a struct that changes layout without changing its declaration produces no
error at all. Either way nobody finds out until the pin moves, which can be
months after the change landed.
chdb-core will dispatch here when it publishes a release. This runs the suite
against that engine on all four platforms, opens an issue with the verdict and
closes it again when green. A red result does not mean the pinned engine broke —
update_libchdb.shis untouched — it means adopting the new one needs addon workfirst.
One Node version rather than three: what is under test is the C ABI, and that
does not vary by Node version. Platform does, so all four stay.
CHDB_ENGINE_VERSIONis deliberately notCHDB_LIB_VERSION, which already meansthe npm subpackage version and is read from
LIBCHDB_NPM_VERSION.Nothing here runs until it is on main;
repository_dispatchonly ever executesthe default branch's copy of a workflow.
🤖 Generated with Claude Code
Note
Add CI workflow to test and pin each new chdb-core release
repository_dispatch(typechdb-core-release) or manual dispatch with anengine_versioninput.CHDB_ENGINE_PINin update_libchdb.sh if tests pass and the tested commit matches the default branch tip.CHDB_ENGINE_PINas an explicit named variable inupdate_libchdb.sh, withLATEST_RELEASEfalling back to it whenCHDB_ENGINE_VERSIONis not set.Macroscope summarized 9cf9988.