Remove Mono dependecy

[RouR]

From this comment - If I want to use GitVersion, Mono must have installed.

I try to use it on Travic CI server ubuntu.14.04-x64 without any dependency to Mono, and it`s fail.

Is it really necessary to use Mono?
.NET Core 2.0.2 work`s fine on ubuntu.14.04-x64 without any dependency to Mono

[dazinator]

The latest beta packages should run under dotnet core sdk <= 2.0.0 now. If you have 2.1.0 installed youll need a global.json file to pin sdk version to 2.0.0 until we merge a Pr that adds support for > 2.0.0

[dazinator]

We also have a dotnet core 2.0 based docker image.

[nlowe]

@dazinator Assuming you're talking about gittools/gitversion-dotnetcore:0.0.0-alpha0015 (The most recent tag for gittools/gitversion is over a year old) It would appear that image is windows based. Can we get a linux image with the dotnet core version?

[dazinator]

@nlowe I don't see why not. Is this something you would consider contributing? The docker files are pretty simple - you can see them here: https://github.com/GitTools/GitVersion/tree/master/src/Docker/

I assume you just want a copy of the dotnetcore one, just using the linux base image right?

[nlowe]

Sure. I'd be happy to contribute. Do you want a separate issue to track this, or can I just send in a PR?

[nlowe]

So It looks like microsoft/dotnet:2.0-runtime has a split tag (it's windows and linux, it depends on what mode you're in when you pull / run / build it). Can we rebuild it in linux mode and push it? I don't think there's an automated process that does that just yet (#1445)

[dazinator]

I see. I think there is automation for the docker build and push, check this script: https://github.com/GitTools/GitVersion/blob/master/deploy.cake#L211

Perhaps you could look at adjusting that in a PR to cater for the linux version - you are right #1445 isnt fully sorted yet, but once it is, we should see some fruits of our labour.

[JakeGinnivan]

Getting the docker images deployed is high on my priority list, because it's what I use because all our build servers are centOS and can't run GitVersion at all

[JakeGinnivan]

Will probably sort out on Saturday

[derwasp]

@JakeGinnivan if I may, why can't one run GitVersion on CentOS? libgit2sharp.nativebinaries supports rhel RID.

[JakeGinnivan]

I had the issue quite some time ago @derwasp . But it was due to libssl or something from memory. Can try running natively again though!

[derwasp]

@JakeGinnivan I built an AWS lambda function, which runs on something very close to rhel.7.2-x64 and I am using gitversion lib in there. Works like charm.

[RouR]

Has there been any progress made on this?
I use dotnet core sdk 2.1 for now

[arturcic]

@RouR could you have a look at the new docker images? you can find them here https://hub.docker.com/r/gittools/gitversion-dotnetcore/tags/

[RouR]

I don`t know how to use it directly in my project.
I use "nuke-build", which have dependency to "gitversion".

This script will call gitversion and it will throw this error (See initial issue)

[arturcic]

I seems the nuke-build you're using depends on a version of GitVersion that runs on mono only https://github.com/nuke-build/nuke/blob/develop/source/Nuke.GlobalTool/templates/_build.sdk.csproj#L15. There is a PR in progress that adds support for .net core sdk 2.1 and global tools

[gep13]

@arturcic Regarding the Global Tool, I noticed this on NuGet.org:

https://www.nuget.org/packages/dotnet-gitversion/

Is that going to cause a problem? Or what were you thinking about naming the package?

[arturcic]

Btw related to that, probably we should consider reviewing the nuget packages IDs by making them shorter and add the GitTools as prefix to avoid confusions with other packages on nuget.org? As far as I can see this is not a global tool, meaning it will not cause issues when running the global tool

[arturcic]

probably we need to open an issue regarding the package IDs, and have the discussion there

[gep13]

@arturcic said...
probably we need to open an issue regarding the package IDs, and have the discussion there

Sounds like a good idea to me.

[asbjornu]

As #1528 implemented the global tool and #1572 discussed the naming scheme, I feel this issue can be closed. If there's still naming scheme issues to discuss, please open a new issue.