Report a finding as unverified when its declaring assembly is outside the closure - #5
Merged
Merged
Conversation
…utside the closure
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.
Commit 1 of the suspended PR #1, cherry-picked onto current
develop. Commit 2 of that PR is dropped: #4 landed the altConfigs build properly, through the shared script rather than the inline copy with the org/repo filter.ProbeDeclaringTypetakes its verdict from whichever loaded assembly yields the declaring type, which is not necessarily the one the dataset recorded. When the recorded assembly is absent and another answered instead, the probe describes code the dataset was never talking about, and the finding is counted as a genuine regression. This reports those as unverified, split intoForeignDeclaringAssemblyandConfigurationNotBuiltso the reason is legible.It stays real where it should. When nothing answered for the type the path is
DeclaringTypeNotLoaded, which is how a genuine removal presents, and when the family is the repo's own but no configuration of it is loaded. An earlier draft lacked the first guard and would have silenced real removals; a runner-planted removal confirmed it, and a mutation holds it.Measured effect on
BHoM/Revit_Toolkit: of the two findings it reports today,Create.ProjectParameteris already resolved by #4 building the alternate configurations, so onlyCompute.TryGetValueFromSourceremains. That one is declared byRevit_ModelQA_Engine_2022, an assembly outside this repository's closure, and it is the false red currently on the check. This clears it.Scope note: this narrows what gets reported, it does not fix attribution. Namespace attribution still misassigns a finding whose declaring assembly is present but foreign, which is the larger direction of CI_Toolkit#161 and is untouched here.
13 tests, four mutations each caught by the intended one. 108 in the suite with the branch composed against the load-order change already on
develop.