test(release): derive suite simulation version - #313
Draft
davida-ps wants to merge 1 commit into
Draft
Conversation
![baz-reviewer[bot]](https://avatars.githubusercontent.com/in/933528?s=60&v=4){kind=small}
Comment on lines
+38
to
+41
| return { | ||
| expectedOriginal: version, | ||
| expectedSimulated: `${match[1]}.${match[2]}.${BigInt(match[3]) + 1n}`, | ||
| }; |
Contributor
There was a problem hiding this comment.
BigInt expectedSimulated diverges from simulator
stablePatchFixture() computes expectedSimulated with BigInt(match[3]) + 1n, but nextSimulatedReleaseVersion() turns match[3] into a Number, so large valid patch values can round and make simulated_version disagree with the test expectation. parseSemver() accepts arbitrarily long core digit sequences, so should we keep the patch increment in BigInt or avoid Number(match[3])?
Want Baz to fix this for you? Activate Fixer
Other fix methods
Prompt for AI Agents
Before applying, verify this suggestion against the current code. In
`scripts/test-skill-tag-release-simulation.mjs` around lines 38-41, in
`stablePatchFixture()`, `expectedSimulated` is computed with `BigInt(match[3]) + 1n`,
which will not match the simulator when it increments the patch via `Number(match[3])`
(precision loss for large digit sequences). Fix this by updating the simulator logic
`nextSimulatedReleaseVersion()` (and any related semver parsing used there) to compute
the patch bump using `BigInt` rather than `Number`, then convert back to a string in the
same `${major}.${minor}.${patch}` format. After refactoring, rerun the simulation tests
to confirm the expected and simulated versions match for large semver patch values.
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
1 participant
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.
User description
Summary
skill.jsonversionmajor.minor.patchversion before simulating a stable patch releaseBigInt, independent of production increment logicWhy
The shared release simulation hard-coded
clawsec-suiteas0.1.16 -> 0.1.17. Any legitimate Suite version bump made the shared test fail even though the production simulator correctly derived the next patch. This keeps the test meaningful without requiring version-specific churn in every changed-skill PR.Scope
This changes one shared test file only. It does not change a skill, release workflow, simulator, SemVer helper, tag, publication, or catalog.
Remote validation
ffe6281d809d980521a5375b7bf16777838cbe40e84d35ea1400b516e693b5e45bb4eaae588eb4a4a2a54beda5cada4027d16cb8node scripts/test-skill-release-semver.mjsnode scripts/test-skill-tag-release-simulation.mjsscripts/test-skill-*.mjsregression, using a narrowly scoped test-onlyzip -qr <archive> .wrapper because the remote host has7zbut nozipnpx eslint scripts/test-skill-tag-release-simulation.mjs --max-warnings 00.1.17candidate: all shared skill-release regressions passed and the simulator advanced it to0.1.18Generated description
Below is a concise technical summary of the changes proposed in this PR:
Derive the shared Suite tag-release simulation input from
skill.jsonso the release simulator validates the current stable version instead of a hard-coded patch. Add a test-local final-SemVer check and compute the next patch with regex plusBigIntbefore runningrunSimulation.Latest Contributors(2)