Use commit SHA as additional version fallback

[jamescrosswell]

sentry-dotnet/src/Sentry/Reflection/AssemblyExtensions.cs

Lines 44 to 48 in e75d537

	// Note: even though the informational version could be "invalid" (e.g. string.Empty), it should
	// be used for versioning and the software should not fallback to the assembly version string.
	// See https://github.com/getsentry/sentry-dotnet/pull/1079#issuecomment-866992216
	// TODO: Lets change this in a new major to return the Version as fallback
	return assembly.GetName().Version?.ToString();

[bruno-garcia]

Also please note there is an initative to have a default release in all SDKs, based on running git at compile time. @smeubank might know more about that

[bruno-garcia]

Also another thing we can do on 4.0: getsentry/sentry-javascript#9195 (comment)

Lets have more fallbacks where we get the SHA from one of those env vars at compile time? We have something that at compile timer adds an [assembly: .. attribute already I believe.

That is, unless newest versions of .NET have the AssemblyInformationVersion populated automatically, in which case we'd be reinventing the wheel

[bruno-garcia]

Oh @AbhiPrasad found it:

• Setting Release Automatically develop#755

[jamescrosswell]

That is, unless newest versions of .NET have the AssemblyInformationVersion populated automatically, in which case we'd be reinventing the wheel

Whatever people put in the AssemblyInformationalVersionAttribute can be obtained at run time from the Application.ProductVersion property.

Typically, a version number displays as major number.minor number.build number.private part number. You can set it explicitly by setting the assembly version within your assembly manifest.

Folks can add a SHA in the private part number by passing /p:SourceRevisionId=foo when building the assembly (Hanselman describes this). But if they're doing that then we're already capturing that here right:

sentry-dotnet/src/Sentry/Reflection/AssemblyExtensions.cs

Lines 32 to 36 in 3d8bb0a

	var informationalVersion = assembly.GetCustomAttribute<AssemblyInformationalVersionAttribute>()?.InformationalVersion;
	if (!string.IsNullOrEmpty(informationalVersion))
	{
	return informationalVersion;
	}

I think we can close this ticket then?

[bruno-garcia]

Whatever people put in the AssemblyInformationalVersionAttribute can be obtained at run time from the Application.ProductVersion property.

That's a .NET Framework API. Not available on .NET (Core)

Folks can add a SHA in the private part number by passing /p:SourceRevisionId=foo when building the assembly (Hanselman describes this).

He describes the parameter but you need to pass the actual value as an argument. The goal was for us to automate this (the same way that this does it for us:

sentry-dotnet/src/Directory.Build.props

Line 56 in 589ea4d

<PackageReference Include="Microsoft.SourceLink.GitHub" Version="1.1.1" PrivateAssets="All" />

If they are using this lib ^ or another SourceLink library as such it would already be setting AssemblyInformationalVersionAttribute properly and we wouldn't need to do anything.

For example, NuGet Trends has: https://github.com/dotnet/nuget-trends/blob/b4fbc342fec8159e01565a2dd8ae0e7362245338/src/Directory.Build.props#L20
Version isn't set in any other way when configuring Sentry (that I recall) and here's how releases show up in Sentry:

NuGetTrends.Web@1.0.0+b4fbc342fec8159e01565a2dd8ae0e7362245338

so: AssemblyName@AssemblyVersion+GitSHA

AssemblyVersion with 3 digits instead of the default 4, semver compatible. This is format is ideal.
If I'm not mistaken we're getting this from our logic of concatenating the assemblyname + @ + whatever we get from InformationalVersion that's set by that SourceLink package at build time.

[bruno-garcia]

If we decide to change the release building logic, 4.0.0 is ideal time for "breaking" changes

[jamescrosswell]

The goal was for us to automate this (the same way that this does it for us:

I'm not sure I follow. So if someone is not using something like SourceLink already, we want a mechanism in Sentry for them to able to set the private build number portion of their assembly version to a commit hash when building their application? Or we simply want to read this?

I'm assuming it's not about setting this since dotnet build already allows you to pass a SourceRevisionId property to do this.

In terms of reading it, we'd just need to pull this off the attribute that gets set. This code is a bit hacked together, but will do it:

using System.Reflection;

// Get the assembly for the current executable
var assembly = Assembly.GetExecutingAssembly();

// Get the AssemblyInformationalVersionAttribute 
var infoVersion = assembly.GetCustomAttribute<AssemblyInformationalVersionAttribute>();

// Extract just the informational version part
var privateBuildNumber = infoVersion?.InformationalVersion.Split('+')[1];

Console.WriteLine(privateBuildNumber); 

[bruno-garcia]

I'm not sure I follow. So if someone is not using something like SourceLink already, we want a mechanism in Sentry for them to able to set the private build number portion of their assembly version to a commit hash when building their application? Or we simply want to read this?

We would keep the value in a Sentry-specific "GitSha" attribute, so we could read it at runtime. That's only useful if they don't have set Release programatically. Nor have set AssemblyVersion (defaults to 1.0.0) so at least the commit sha differs. And if they don't use SourceLink.

I'm assuming it's not about setting this since dotnet build already allows you to pass a SourceRevisionId property to do this.

It's not about hoping the user does something manually (like passing the value). It's about Sentry working OOTB with no user configuration required. We'll show commit sha in the version (appended after version number through + as shown above).

In terms of reading it, we'd just need to pull this off the attribute that gets set. This code is a bit hacked together, but will do it:

Something like that but wouldn't be AssemblyInformationalVersionAttribute that we already have.
We'd read from our Sentry specific attribute.

[bruno-garcia]

I think if we used sometjhing like:

    // GitHub Actions - https://help.github.com/en/actions/configuring-and-managing-workflows/using-environment-variables#default-environment-variables
    process.env.GITHUB_SHA ||
    // Netlify - https://docs.netlify.com/configure-builds/environment-variables/#build-metadata
    process.env.COMMIT_REF ||
    // Vercel - https://vercel.com/docs/v2/build-step#system-environment-variables
    process.env.VERCEL_GIT_COMMIT_SHA ||
    process.env.VERCEL_GITHUB_COMMIT_SHA ||
    process.env.VERCEL_GITLAB_COMMIT_SHA ||
    process.env.VERCEL_BITBUCKET_COMMIT_SHA ||
    // Zeit (now known as Vercel)
    process.env.ZEIT_GITHUB_COMMIT_SHA ||
    process.env.ZEIT_GITLAB_COMMIT_SHA ||
    process.env.ZEIT_BITBUCKET_COMMIT_SHA ||

As they did in Node: minus some obvious stuff like VERCELL and instead whatever TeamCity, AppVayor, Azure DevOps and other popular .NET building tools this would be good enough

[bruno-garcia]

Moved to 5.0.0 since we have too much in scope right now