fix(ci): exclude the versioning test sets and upgrade maps from the dataset compliance pathspec

[sakanni]

ci-dataset-compliance asserts that every file it selects deserialises into a BH.oM.Data.Library.Dataset. Two shapes in scope are not Dataset documents, and this repository holds one of them.

Measured with git ls-files against this checkout:

pathspec	files
:(icase)*datasets*.json	80
+ :(exclude,icase)*Versioning_Test/Datasets/*	0
+ :(exclude,glob,icase)**/Versioning_[0-9]*.json	0

All 80 are under .ci/code/Versioning_Test/Datasets. Nothing else in this repository matches the selector, so nothing legitimate is lost.

Measured behaviour of the runner, for the record: DatasetComplianceRunner built from CI_Toolkit 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 genuine library dataset in the same environment.

Why there are two exclusions

The first token covers this repository's test corpus: JSON Lines of oM objects whose filenames are Objects.json, Methods.json and Adapters.json. The filename carries no signal, so only a path exclusion reaches them.

The second token covers a different shape, and it is not for this repository's benefit. BHoM versioning upgrade maps are named Versioning_<version-without-the-dot>.json and hold {"Dataset":{"ToNew":..,"ToOld":..}}, read by BHoM_Engine Versioning_Engine/Query/DatasetToNewPaths.cs. They carry no _t and can never be Dataset documents. Swept over 309 repositories on their default branches: 15 such files in 11 repositories, each at a project root next to its .csproj. None is currently selected, because the base selector needs a datasets substring in the path. The exception is a repository whose project folder supplies that substring, which is the *_Datasets repositories, and one such file is failing on an open pull request today.

This repository holds zero files of that shape, so the second token is a no-op here. It is included so the pathspec does not diverge from the template.

Both :(glob) and the [0-9] gate are load-bearing, and each is pinned by an assertion in the CI_Toolkit pull request:

• A bare :(exclude,icase)*Versioning_*.json reads as a filename rule but is not one. Without :(glob) the * crosses /, so it drops every .json under any directory containing Versioning_, including this repository's test corpus and any real dataset under a Versioning_Engine folder.
• Without :(glob) the trailing * also crosses /, so a directory named Versioning_<digits> would take its whole contents out of scope.
• Without [0-9] the token would drop a genuine dataset named Versioning_Rules.json. Gating on the current BHoM version instead does not work: repositories keep the map for whatever version they last needed one at, and six of the 15 are Versioning_33.json.

Why this repository needs its own edit

The identical change is in BHoM/CI_Toolkit templates/BHoM/ci-beta.yml and templates/BHE/ci-beta.yml (that pull request also carries the fixtures and assertions that pin it). Per BHoM/internal-tickets#39 nothing propagates a template change to onboarded repositories, so the template edit fixes no repository and this one is what takes effect here.

The patterns: value here is character-for-character the same as the template's, so the two cannot drift on the thing that determines behaviour. The surrounding comment is deliberately shorter than the template's: the fuller derivation, including which element of the token each control run pins, is kept in CI_Toolkit next to the assertions that prove it.

What this does not fix

Measured over the same 309 repositories: on default branches the second token removes nothing, because no upgrade map currently sits in a selected path on any default branch. Its effect is on pull requests, and the one live instance is in another repository that holds its own copy of this workflow and has no pull request open against it. This pull request does not clear that failure. The route that would clear it without a per-repository edit is to have ci-compliance append the dataset exclusions itself, which is a separate change and not proposed here.

What CI did and did not check

• ci-dataset-compliance will self-skip on this pull request. It changes one workflow file, which the dataset pathspec does not match, so the job reports success having examined nothing. That is expected and is not evidence the change works. The evidence is the git ls-files measurement above and the fixture assertions in the CI_Toolkit pull request, which go from 83 to 92 and include control runs confirming each element of the new token is independently required.
• ci-versioning is expected to be red, per BHoM/internal-tickets#34, on every pull request against this repository and for reasons unrelated to this change.

Refs BHoM/internal-tickets#36, BHoM/internal-tickets#43.

---

Supersedes #349, which was closed as a side effect of renaming this branch to the documented convention. Same head commit, 867150f. The only content lost was BHoMBot check-queue chatter; there were no reviews.

[sakanni]

@BHoMBot check required

[bhombot-ci]

@sakanni to confirm, the following actions are now queued:

• check code-compliance
• check documentation-compliance
• check project-compliance
• check core
• check null-handling
• check serialisation
• check versioning
• check installer

There are 23 requests in the queue ahead of you.

[bhombot-ci]

@sakanni to confirm, the following actions are now queued:

• check code-compliance
• check documentation-compliance
• check project-compliance
• check core
• check null-handling
• check serialisation
• check versioning
• check installer

There are 24 requests in the queue ahead of you.

[bhombot-ci]

The check installer has already been run previously and recorded as a successful check. This check has not been run again at this time.

[sakanni]

@BHoMBot check copyright-compliance

[bhombot-ci]

@sakanni to confirm, the following actions are now queued:

• check copyright-compliance

There are 24 requests in the queue ahead of you.