Use the PoB Codes corpus in the existing build-diff tests - #15
Merged
Merged
Conversation
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.
This connects your existing build-diff tests to the PoB Codes API. The API manages the rolling collection of up to 500 builds. CI downloads it when there isn't a calculated base cache, then keeps the input list, downloaded XML, and calculated base results together. Later runs reuse that same collection and base results.
This keeps your existing batches of 50, runtime comparison, full saved-XML comparison, and stat comparison. It uses the official PoB test image, with the dependencies your existing scripts need installed at startup. Decoding stays in Lua. There are no Dockerfile changes, Python dependency, or downloaded builds committed to Git. The old scheduled build-list collector is removed because PoB Codes handles that now.
There are a few small fixes alongside the API connection. Test files are preserved when switching revisions, and the stat comparison handles XML attributes in either order. Failed commands stop the run.
I tested this locally against the actual API with 500 builds and the five existing fixtures. Both sides calculated all 505 inputs. A second run reused the base cache and detected an intentional +1 Life change in every input, without downloading the collection or recalculating the base. The unchanged-revision comparison still reports calculation differences; no calculation fixes are included here.
I tested locally using PoB v2.67.2 and the live PoB Codes API. Coverage tracking was temporarily disabled during those tests because it slowed things down substantially, but the PR doesn't change this. I haven’t repeated the full run with coverage enabled or tested the workflow through GitHub Actions yet.