Skip to content

fix(ci-compliance): exclude the versioning test sets from the dataset pathspec - #20

Merged
sakanni merged 1 commit into
developfrom
fix/ci-dataset-compliance-pathspec-exclusion
Sep 8, 2026
Merged

fix(ci-compliance): exclude the versioning test sets from the dataset pathspec#20
sakanni merged 1 commit into
developfrom
fix/ci-dataset-compliance-pathspec-exclusion

Conversation

@sakanni

@sakanni sakanni commented Sep 8, 2026

Copy link
Copy Markdown
Collaborator

ci-dataset-compliance asserts that every file it selects deserialises into a BH.oM.Data.Library.Dataset. Versioning_Toolkit's versioning test sets match the selector but are JSON Lines of oM objects, so all 80 fail by design.

Measured rather than inferred: DatasetComplianceRunner built from develop exits 1 on .ci/code/Versioning_Test/Datasets/9.2/Objects.json with Dataset file did not deserialise into a BH.oM.Data.Library.Dataset object successfully, and exits 0 on a real library dataset in the same environment.

The change

Both tier-bundle templates gain one exclusion token:

:(icase)*datasets*.json :(exclude,icase)*Versioning_Test/Datasets/*

compute-changed-files splits patterns with read -ra and passes the tokens to git diff as pathspecs (action.yml:123 and :125), so git exclusion syntax works, and the token contains no spaces.

Loss check

git ls-files against real checkouts, except the last row:

repo before after
Versioning_Toolkit 80 0
BHoM_Engine 208 208
Test_Toolkit 65 65
StructuralEngineering_Toolkit 27 27
CFD_Toolkit 2 2
Revit_Toolkit, XML_Toolkit, BHoM_Adapter 0 0
BuroHappold_Datasets 57 57

Nothing legitimate is lost. BHoM_Engine's 208 under .ci/Datasets/** are genuine Dataset documents; spot-checked .ci/Datasets/BHoM_Engine/Modify/RemoveAndSplitAtIndexes.json. The BuroHappold_Datasets row was measured from the git tree at a branch head rather than a checkout, and is a no-op there: that repo holds no path containing Versioning_Test/Datasets/.

Test coverage

The suite goes from 75 to 83 assertions and passes. extract_check_patterns reads patterns: straight out of the shipped YAML, so the new two-token value is picked up without being restated, and matched() mirrors the action's own read -ra plus git diff invocation.

Control run: reverting the pathspec alone fails exactly the two new assert_not_matches and nothing else, so those assertions test the exclusion rather than passing vacuously.

Two fixtures per case, not one: 9.2/Objects.json is the file the versioning dataset work edits, and 9.1/Methods.json proves the exclusion is version- and filename-agnostic rather than accidentally passing on one path.

The fixture also pins the project-directory case as still selected. The selector is substring-based, not dataset-aware: without :(glob) a * crosses /, so the substring can come from a filename, a data directory, or a project directory named *_Datasets. This exclusion covers one directory layout and deliberately not that case, which is live and failing today in a *_Datasets repo. Asserting it positively means a later re-anchoring has to flip a visible assertion instead of changing fleet-wide scope silently. Tracked in BHoM/internal-tickets#43.

What this does not do

Per BHoM/internal-tickets#39, onboarded repos hold their own copy of ci-beta.yml with the pathspec inline and nothing propagates a template change. This fixes no repository. It stops the old pathspec reaching future onboardings. The edit that unblocks the versioning dataset work is the same one-line change to Versioning_Toolkit's own workflow file, and that is a separate PR.

Refs BHoM/internal-tickets#36.

… pathspec

The dataset compliance check asserts that every file it selects deserialises
into a BH.oM.Data.Library.Dataset. Versioning_Toolkit's versioning test sets
match the selector but are JSON Lines of oM objects, so all 80 fail by design.

Measured: DatasetComplianceRunner built from develop exits 1 on
.ci/code/Versioning_Test/Datasets/9.2/Objects.json and 0 on a real library
dataset in the same environment.

Adds the exclusion to both tier-bundle templates and pins it in the
changed-file-patterns suite, which goes from 75 to 83 assertions. The suite
also pins the project-directory case as still selected, because the selector
is substring-based rather than dataset-aware and this exclusion covers one
directory layout rather than a class of file.

Refs BHoM/internal-tickets#36
@sakanni
sakanni merged commit 901bedb into develop Sep 8, 2026
3 checks passed
sakanni added a commit that referenced this pull request Sep 9, 2026
…taset pathspec

Follow-up to #20. That exclusion was path-based and covered one directory
layout. Versioning_<digits>.json are versioning upgrade maps holding
{"Dataset":{"ToNew":..,"ToOld":..}}, read by BHoM_Engine
Versioning_Engine/Query/DatasetToNewPaths.cs. They carry no _t, can never be
BH.oM.Data.Library.Dataset documents, and sit at a project root in any repo,
so a path-scoped rule cannot reach them.

Add ':(exclude,glob,icase)**/Versioning_[0-9]*.json' to both tier-bundle
templates. Each element is required and is pinned by an assertion: :(glob)
keeps the token a filename match rather than a path-substring match, the **
anchor keeps it depth-agnostic, and the [0-9] gate keeps a genuine dataset
named Versioning_Rules.json in scope.

Flip the two characterisation assertions #20 left as assert_matches, which its
own comment recorded as the intended outcome of a widening. Add five fixtures
covering the depth-2 case, a real dataset inside a Versioning_<digits>
directory, a real dataset under a Versioning_Engine project, and one path that
the base selector never reaches.

Refine the structural invariant to permit ** only under :(glob). Defect 3 is a
property of git's default matcher, where '**' is not special; :(glob) switches
on WM_PATHNAME and there '**/' matches zero or more leading components. The
invariant previously rejected the only correct way to write a basename match.
It still fails ** without :(glob).

Suite 83 to 92 assertions. Fleet measurement over 309 repositories on their
default branches: no repository loses a file, because no upgrade map currently
sits in a selected path on a default branch.

Refs BHoM/internal-tickets#36, BHoM/internal-tickets#43.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant