test: assert the v1 import never writes to plugins/SetHomes/ - #61
Merged
Conversation
The migration is reversible only because v2 never writes, renames or deletes anything under plugins/SetHomes/. Put the old jar back and the server is as it was. That guarantee is why taking the name SetHomes was rejected, but nothing in the suite held the importer to it. Fingerprints every path under the v1 folder as SHA-256 before and after, for the dry run and for confirm, and compares the whole map so an edit, an addition and a deletion all fail alike. Directories are recorded in their own right, or an added empty folder would contribute no entries and pass unnoticed. No changeset: src/test is exempt from the gate and nothing here ships.
The push job chose its target from the branch name alone, so merging the base branch into a branch that already had an open pull request reported the issue as in progress. The Todo and unset guard could not help: it stops an issue being pulled out of In review, but an issue that never reached In review is not protected by it. The job now asks whether the branch has an open pull request and aims for In review when it does, advancing from In progress as well as Todo and unset. Neither plan names Ready for release or Done, so a push still cannot disturb a shipped issue. The decision lives in push_plan so it is covered by the suite.
… into issue-57-import-never-writes-to-v1
…om/Blockframe-Studios/SetHomesTwo into issue-57-import-never-writes-to-v1
4 tasks
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.
Closes #57. Third of the five sub-issues split out of #41, and it closes the last acceptance criterion there that was resting on a by-hand observation rather than an assertion.
Why
The whole migration is reversible only because v2 never writes, renames or deletes anything under
plugins/SetHomes/. Put the old jar back and the server is exactly as it was. That guarantee is the reason taking the nameSetHomeswas rejected on #41, and the reason the README can tell admins to keep the old jar.It held in the 2026-08-16 rehearsal, where the folder was byte-for-byte identical to its pre-import checksums after a full
confirmand a play session. Nothing in the suite held the importer to it, so a future change could quietly break it and every test would still pass.What the test does
Fingerprints every path under the v1 folder as SHA-256 before and after the import, and compares the whole map, so an edited file, an added one and a deleted one all fail alike. One test for the dry run, one for
confirm.Directories are recorded as entries in their own right. Without that, an added empty folder contributes no map entries and slips through, which matters because "move v1's files into an
imported/subfolder once consumed" is one of the designs #41 explicitly rejected.The fixture carries the cases that make the importer work hardest, so this is not proving read-only behavior on a file the importer barely looks at: a home in a world that no longer exists, a case-only duplicate name, an unnamed home, a player the server has never seen, plus
world_blacklist.ymlandconfig.yml, since the importer reads all three files.Verification
387 tests,
Failures: 0, Errors: 0, Skipped: 0, up from 385.This is a characterization test for behavior that already holds, so passing on the first run proves nothing. It was run red-first against a deliberately broken importer, using the three ways the guarantee could actually be lost:
imported/folder after a confirmhomes.ymlon both pathsworld_blacklist.ymlonce consumedThe importer was restored byte-identical after each.
The confirm test also asserts
imported > 0,renamed > 0andskippedWorldMissing > 0before comparing fingerprints. Without that it would pass just as happily for an importer that did nothing at all.No changeset
scripts/require-changeset.shexemptssrc/test/, and the gate was run against the new path to confirm: "No shippable files changed - no changeset needed." Nothing here reaches a server, so there is nothing to tell an owner.