Stop producing git-info files

[omajid]

This is a follow-up from https://github.com/dotnet/installer/pull/18941 (which was finally merged as https://github.com/dotnet/sdk/pull/41190)

@premun said:

I am only a bystander in this effort but once you are done with the whole feature change, can you please let me know and I can make the VMR synchronization tooling stop producing the git-info files?

I think we can do that now.

[dotnet-issue-labeler[bot]]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[dotnet-issue-labeler[bot]]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ViktorHofer]

cc @premun

[ViktorHofer]

@omajid I think the following lines still depend on the git-info files:

• https://github.com/dotnet/dotnet/blob/ce657d2f2becb95311251f222a5f5d3b61e1b5c1/repo-projects/deployment-tools.proj#L13
• https://github.com/dotnet/dotnet/blob/ce657d2f2becb95311251f222a5f5d3b61e1b5c1/repo-projects/roslyn.proj#L15
• https://github.com/dotnet/dotnet/blob/ce657d2f2becb95311251f222a5f5d3b61e1b5c1/repo-projects/Directory.Build.props#L146-L147
• https://github.com/dotnet/dotnet/blob/ce657d2f2becb95311251f222a5f5d3b61e1b5c1/repo-projects/Directory.Build.props#L150-L151

[omajid]

Uh, so deployment-tools.proj is something I can probably fix.

But as for OfficalBuildId and PrereleaseVersionLabel, I am not sure that was in scope of my original plan for fixing git commit hashes. I don't know of any way to obtain the values of those variables aside from these git-info files.

Maybe I should re-target this issue to just not recording commit hashes in git-info files?

[ViktorHofer]

Would be great if you could fix / standardize deployment-tools :)

Regarding OfficialBuildId / PrereleaseVersionLabel, I'm not actually sure. IIRC for most repos the idea is to use the OfficialBuildId calculated passed-in (either from AzDO or as a local arg). But we have some repos like roslyn which might need a different OfficialBuildId. cc @mmitche @MichaelSimons in case you remember

[mmitche]

For repos that need to have an official build id line up with another released product, the official build id is hardcoded into the repo state. IIRC we had another place this was recorded. For repos that only ship via the VMR, the OB ID can float (changes run to run). In that case it's provided via the CI system, and we will tell you what the number should be when you build, or more likely, we will simply make it so that it doesn't for product functionality whether everyone chooses the same ID. only major.minor.patch + prerelease label and iteration matter. Those are coded into the product sources.