Delete standalone cmake installation from Windows build images

[jkotas]

The Windows build images have two cmake installations: One that comes with Visual Studio and a standalone one. All repos should use the one that comes with Visual Studio.

The standalone cmake installation is redundant. It should be deleted to make our build environment simpler and more secure.

Context: https://github.com/dotnet/runtime/issues/88172#issuecomment-1613896921

Release Note Category

• [ ] Feature changes/additions
• [ ] Bug fixes
• [ ] Internal Infrastructure Improvements

  Release Note Description

[jkotas]

cc @agocke

[dougbu]

as mentioned in dotnet/runtime#88172, making this change would negatively impact any team using the standalone cmake installation. @dotnet/dnceng do we have a reliable way to determine who would be affected❔

[garath]

do we have a reliable way to determine who would be affected❔

Not that I know of. Anyone can use anything from the images we provide in any way. It's hard to get detailed auditing. And it is very hard to be confident a change won't break anyone.

Thus, changes of this kind to machine images are done with thorough communication with partner teams using channels like the Build Council, GitHub issues in the Arcade repository, the DNCEng Partners email alias, the General channel of the .NET Core Eng Services Partners Teams team and the engineering services rollout/release notes. But it's certainly possible.

In this particular situation, Engineering Services would partner with someone who would drive the change. This person is probably not a member of dnceng as this is a bit outside our usual stewardship concerns of things like Component Governance or other Compliance issues. So if there was a partner willing to take this on we would of course provide any data and support we could (e.g., build telemetry, access to our databases, etc.)

[jkotas]

And it is very hard to be confident a change won't break anyone.

That is true of any build image changes. The rollouts of the updated build images are regularly breaking dotnet/runtime builds and we have to always adjust to the break on a short notice. That's how the system is setup.

The proposed change is not deleting cmake from the image. It is effectively updating the version to the one that comes with VS and changing the location where it is installed. Both these types of breaks (version updates and changes in the exact locations where the tool is installed) happen regularly, without much ado.

I agree that it is a good idea to do some due diligence to see who may be affected - if it is easy to do that.

[garath]

The proposed change is not deleting cmake from the image. It is effectively updating the version to the one that comes with VS and changing the location where it is installed. Both these types of breaks (version updates and changes in the exact locations where the tool is installed) happen regularly, without much ado.

Ah, I did not realize this. That makes this easier to accomplish, I think.

I see your statements that the business motivation is to eliminate one source of problems by eliminating an unnecessary install of CMake. What do you view the urgency as?

[dougbu]

It is effectively updating the version to the one that comes with VS and changing the location where it is installed

not quite. anything using the standalone installation today has either configured their pipeline using the https://github.com/dotnet/arcade/blob/main/Documentation/NativeToolsOnMachine.md approach or is manually finding cmake where it's placed. the problem is applicable searches are going to find loads of matches in eng/common/tools.ps1 files and we don't constrain use of our queues to dotnet/* repos

[jkotas]

What do you view the urgency as?

This issue falls into secure supply chain improvements, not urgent.

IMHO, it should be your job to work towards making the build environment as secure as possible and as small as possible and get the users of the build images to adjust to the changes.

The users of the build images do not really care that there are extra duplicate tools installed from different sources.

[garath]

I think all the pertinent information is captured here (at least, my questions are answered) so I'll let the usual triage process take over.