Sort out CD

[dazinator]

1. Can anyone help with the following tasks:

• We need to get cake build script to build the gem package as it isn't built at present.
• We need to get cake build script to build the tfs task as it isn't build at present.

2. We need to get all of the build assets being pushed automatically to their respective deployment channels, on every commit push. Can we agree on the following strategy:

• In order to issue a "stable" release, we will tag a commit on master with a stable number.
• Every other commit not tagged with a stable number, and irrespective of branch, will produce an "Unstable" release.

If so we need to:

• Configure gitversion to produce stable / unstable version numbers as per the above.
• Amend the build so that stable assets (i.e of the back of a stable build) are pushed to their stable deployment channels (i.e nuget.org etc)
• Ament the build so that "unstable" assets (everything that isn't a stable build are pushed to their unstable / pre-release deployment channels (i.e appveyor ci nuget feed etc)

Note: There appears to be a cake script for deployments` that does a lot of what we need already, but it's not clear to me when this runs or if someone executes it manually or something. Perhaps someone could clarify whether its still used and how.

We have PR's waiting in the wings, and issues because people can't find the latest packages where they are expecting, and this is because we haven't been able to get a handle on the release process or are too reliant on manual intervention.

See several of the bottom comments here for background.

The assets we need to be pushing (Please amend appropriately) are as seen here:

• NuGetCommandLineBuild --> NuGet.org
• NuGetRefBuild --> NuGet.org
• NuGetExeDotNetCoreBuild --> NuGet.org
• NuGetTaskBuild --> NuGet.org
• NuGetExeBuild --> Chocolatey.org
• GemBuild --> ?
• GitVersionTfsTaskBuild--> ?
• zip --> Docker Hub
• zip-dotnetcore --> Docker Hub

[dazinator]

@JakeGinnivan @asbjornu @gep13 @pascalberger please feel free to chime in

[gep13]

Not in a position to help directly, but I can review/answer questions if there are any.

There are addin's Cake.Gem and Cake.Tfx that might be able to help with the work that needs to be done.

[asbjornu]

I think #1338 might have some information on how the current release process works. Missing from the release list is Homebrew, but since that requires a pull request, I'm not sure we can fully automate that? Or can we?

[gep13]

Or can we?

Automatically creating a PR is something that certainly "can" be done. We have thought about doing this for Cake, as that is also pushed to homebrew, but for now, we do this as a manual step.

[dazinator]

@gep13

There are addin's Cake.Gem and Cake.Tfx that might be able to help with the work that needs to be done.

That sounds like an excellent place to start, thanks

[jnevins-gcm]

The support for netstandard has been underway for about 8 months and we are at the point of evaluating whether GitVersion(Task) is a viable solution for use in a new project. Is there any expectation of when a release may come or any advice that can be offered by the maintainers of this project? I realize and appreciate that there is a lot of pre-work required for this support - I'm just trying to evaluate whether it makes sense to use this tool right now.

[dazinator]

@jnevins-gcm afaik there is no reason why you cant consume the gitversiontask nuget package from the netstandard PR. You just need to add the appveyor nuget feed because its not released to nuget.org yet. Instructions should be at the top of the netstandard PR. If you hit problems let us know.

[jnevins-gcm]

That's what we're doing (with mostly success). The problem is redistributing the custom NuGet.config to all of our repos and build agents. Also, there is an issue with that PR that generates TONS of warnings in our builds and slow down build times by 4x (presumably due to the NuGet package restores that occur on every single project that gets versioned due to the newly introduced use of the MSBuild helper library for resolving dependent packages instead of including dependent dlls directly). Our build output looks like this:

    10>GetVersion:
         INFO [08/10/18 9:37:22:56] IsDynamicGitRepository: False
         INFO [08/10/18 9:37:22:56] Returning Project Root from DotGitDirectory: D:\gitrepo\.git - D:\gitrepo
         INFO [08/10/18 9:37:22:56] Project root is: D:\gitrepo
         INFO [08/10/18 9:37:22:56] DotGit directory is: D:\gitrepo\.git
         INFO [08/10/18 9:37:22:56] IsDynamicGitRepository: False
         INFO [08/10/18 9:37:22:56] Returning Project Root from DotGitDirectory: D:\gitrepo\.git - D:\gitrepo
    13>WriteVersionInfoToBuildLog:
         INFO [08/10/18 9:37:22:57] IsDynamicGitRepository: False
         INFO [08/10/18 9:37:22:58] Returning Project Root from DotGitDirectory: D:\gitrepo\.git - D:\gitrepo
         INFO [08/10/18 9:37:22:58] Project root is: D:\gitrepo
         INFO [08/10/18 9:37:22:58] DotGit directory is: D:\gitrepo\.git
         INFO [08/10/18 9:37:22:58] IsDynamicGitRepository: False
         INFO [08/10/18 9:37:22:58] Returning Project Root from DotGitDirectory: D:\gitrepo\.git - D:\gitrepo
    10>GetVersion:
         INFO [08/10/18 9:37:22:60] Begin: Loading version variables from disk cache
           INFO [08/10/18 9:37:22:60] Begin: Deserializing version variables from cache file D:\gitrepo\.git\gitversion_cache\DB52FF94A455E845DE32CE7BD871A0ABE8FC594C.yml
    13>WriteVersionInfoToBuildLog:
         INFO [08/10/18 9:37:22:62] Begin: Loading version variables from disk cache
           INFO [08/10/18 9:37:22:62] Begin: Deserializing version variables from cache file D:\gitrepo\.git\gitversion_cache\DB52FF94A455E845DE32CE7BD871A0ABE8FC594C.yml
    10>GetVersion:
           INFO [08/10/18 9:37:22:68] End: Deserializing version variables from cache file D:\gitrepo\.git\gitversion_cache\DB52FF94A455E845DE32CE7BD871A0ABE8FC594C.yml (Took: 77.13ms)
         INFO [08/10/18 9:37:22:68] End: Loading version variables from disk cache (Took: 77.93ms)

with tons of these

10>MSBUILD : Task factory warning NMSBT010: There is a mismatch between SDK NuGet version (4.7.0) and the NuGet version the task factory was compiled against (4.6.0). There might occur some exotic errors. [D:\gitrepo\src\Web\Web.csproj]

Also, our builds sporadically fail due to concurrency issues (which we having seen previously with other builds of GitVersionTask). MSBuild is building in parallel and it seems there are locking issues:
WARN [08/10/18 7:40:00:51] Could not determine assembly version: LibGit2Sharp.LockedFileException: failed to lock file 'D:/gitrepo/.git/config.lock' for writing:

[dazinator]

@jnevins-gcm
Could the parrallel build / locking issue you are seeing be anything related to: #1381

In terms of the additional restores slowing builds down, thats certainly something we could investigate, feel free to open a more specific issue, with more details about the csproj etc or a repro or link to a build etc. I would expect nuget packages to hit the cache when restored for the first time, so wouldn't expect too much of a slow down in this area.

With respect to the MSBUILD : Task factory warnings - what version of the dotnet sdk are you building with and what gitversiontask nuget package are you referencing?

Lastly, I tend not to use gitversiontask much these days. I usually just execute gitversion at the start of my build either the .exe directly, or if on a dotnet core platform, you can now also run it via the dotnet command, or if you have access to a docker host, you can invoke it via a docker image. This will give you the version number back, and I usually pass that in to msbuild via /p:PackageVersion. Not sure if this kind of approach would work better for you than the GitVersionTask so just mentioning it just in case.

[jnevins-gcm]

This is great help - thanks!

We will switch to the CLI for GitVersion. How is this runnable via the dotnet command?

Also, any reason you are passing in /p:PackageVersion vs. /p:Version?

Are there any other pieces of functionality that would be missing? (aside from appveyor/build server support which could be implemented pretty easily using the command line for their build worker api)?