Arcade: Implement Git Commands Wrapper MSBuild Task

[JohnTortugo]

Implement ToolTask around some basic Git commands:

• Git Branch Name
• Git Commit SHA

First use will be on implementing the Semantic Versioning Task: https://github.com/dotnet/arcade/issues/134

[tmat]

Coming soon: https://github.com/tmat/repository-info/tree/master/src/Microsoft.Build.Tasks.Git

[tmat]

Why do we need branch name? I don't see it used in the versioning doc.

[tmat]

@weshaggard @dagood @dleeapho
The official SourceLink package I'm working on for our customers to use uses libgit2sharp library to query the git repo for various information. The same could be used here for the versioning.
libgit2sharp is a managed wrapper of native libgit2 library. Both are open source. If we used this lib in our infrastructure (for both SourceLink, so we use the same package our customers will be using, and for versioning) we would need to make it part of source build, right? Is that possible? How do we deal with 3rd party libraries in source build?

[weshaggard]

The interesting thing about this is we can only use this from our git repo's and for source-build our target is a buildable tarball so access git in that context isn't interesting so I suspect we can exclude this task from our source-build. If we need to build it we could as you say it is open but I wouldn't do the work given we aren't going to use it in our tarball build.

As for the libgit2sharp is that better then just depending on git? I ask primarily because of the libgit2 native library what is our strategy for deploying the correct version of that? Will it be in the SDK or will we try to find it based on the install of git, or we will care it in our task package for various architectures? I hope it isn't the later as that seems to add additional complexity that doesn't seem worth it to me.

[dagood]

This doesn't sound like something that needs to run during source-build. In the (offline) tarball build, we actually remove the git data entirely (it's dead weight at that point), so builds need to work without it. Currently we gather git data ourselves ahead of time using git commands and pass in whatever properties and environment vars we need to. (It'll be good to get everyone using the same tasks so the override is the same all over!)

We could use this in source-build to gather the Git data in the first place. libgit2 appears to already be available in various repo package repositories--if that's true, then we wouldn't need to build it ourselves, just have the source-build tarball build depend on it. It might be more trouble than it's worth since we already get what we need using git.

@dleeapho I think we should have a list of distros a new dependency needs to be available on in its default package repository for source-build to depend on it.

[JohnTortugo]

IMO, it seems that depending on third-party libraries to implement this might be a bit too much. As long as Git output is sufficiently consistent across platforms it's seems much less work to implement simple MSBuild ToolTasks around the commands than to depend on libgit2sharp->libgit->git

Why do we need branch name? I don't see it used in the versioning doc.

AFAIU the versioning proposal we won't need branch name. But that also brings me to another point. Which other info (SHA, Branch, TAG?) do you expect we to need from Git? Maybe we could postpone to implement a more complex thing to when the need arrive?

[weshaggard]

As for the branch we include it in our build-by string we included in the version metadata, see https://github.com/dotnet/buildtools/blob/master/src/Microsoft.DotNet.Build.Tasks/PackageFiles/versioning.targets#L384. @JohnTortugo https://github.com/dotnet/buildtools/blob/master/src/Microsoft.DotNet.Build.Tasks/PackageFiles/versioning.targets is a good file to look at to see what git commands we invoke from BuildTools.

[tmat]

Let's start with what features do we actually want in source build.
If it's just the GIT SHA then we certainly don't need libgit. If we want full SourceLink support and embedding of non-tracked files to PDBs then we will need libgit.

I like the idea of running tools that pre-generate the necessary metadata to .props/.json files outside of source build and include this files in the tarball.

[JohnTortugo]

Some properties defined on the links pointed by @weshaggard :

RawGitBranchName -> git describe --all HEAD
LatestCommitExitCode -> git rev-parse HEAD (Get the latest commit hash)
LatestDateCommand -> git show -s --format=%25cd --date=short HEAD

GitHubOwnerName -> # hardcoded as dotnet
GitHubRepositoryName -> # defined elsewhere
GitHubRepositoryUrl -> # https://github.com/$(GitHubOwnerName)/$(GitHubRepositoryName)

[markwilkie]

@tmat to propose the right next step to resolve this.

[markwilkie]

@tmat is working on this. Source-Link uses the same library....

[markwilkie]

@tmat - any update on this?

[tmat]

It's not needed anymore.