CI Clone Test Toolkit to be isolated further?

[al-fisher]

There have been a couple of instances where the CI test fails as a result of the Clone Test Toolkit steps - rather than than the actual PR'd branches. Will be good to isolate further/version the Test Toolkit such that we do not get incompatible branch versions, giving I think false negative failures.

One to discuss @FraserGreenroyd

Recent example:

Failing Commit to oM here

can see state here:

Azure Job failing to build as part of Clone Test toolkit here

[al-fisher]

@alelom FYI

[FraserGreenroyd]

@al-fisher I think BHoM did not receive the same updates to CI isolation that BHoM_Engine did when we were having difficulties there. I see the milestone is MVP of 3.2 so I presume there isn't anything holding up current work for close of this milestone?

[al-fisher]

@al-fisher I think BHoM did not receive the same updates to CI isolation that BHoM_Engine did when we were having difficulties there. I see the milestone is MVP of 3.2 so I presume there isn't anything holding up current work for close of this milestone?

Yes - I wondered if it was a related issue.

I do not think there is anything urgent - the specific issue was resolvable by just updating all dependant PRs to master. But this ought to be unnecessary (assuming all the PRs are actually compatible amounts themselves)

Can pick up as part of 3.2

Thanks @FraserGreenroyd

[al-fisher]

Had another odd one with AppVeyor too. Just noting here Fraser for us to do a general review in 3.2.
Ta
see BHoM/BHoM_UI#222

[FraserGreenroyd]

So this has cropped up again this week, however, as we move towards utilising BHoMBot-CI more , I feel that this issue has been solved through isolating Test_Toolkit to nugets that work for the CI as opposed to conflicting between live builds. This means that the CI is version locked at run time, as opposed to being built every time it is needed, which is the current case with Azure.

As such, I feel this issue is being resolved through a natural evolution of CI operations, with our desired output for Azure to wind down and become a back up during the next couple of milestones. Thus I am going to close this issue on that basis, however if you feel this is the wrong answer then please do reopen 😄