Distribute on NPM?

[MeirionHughes]

It might be nice to be able to run gitversion in Node and then from there we can have gulp-gitversion.

[JakeGinnivan]

That would be cool. I am thinking we hold off for v4 to do this, because then we will have cross platform support via mono.

[gep13]

I have never done any npm packaging, is this something that is simple to do?

[MeirionHughes]

@JakeGinnivan fair enough. :)
@gep13 I believe so, a few lines in a build script when its setup. end-users then just need to install node.js (or just npm on its own) then it would be as simple as npm install gitversion -g to use it computer wide, or locally in a single project. Beauty of it is its exactly the same usage on Windows/Linux/OSX

[gep13]

@MeirionHughes what about the gulp-gitversion portion? Is this something that we would want to take ownership of?

[JakeGinnivan]

I think we should take ownership of it, to be honest there is little friction in maintaining it. There is a lot more when someone else has to play catch up all the time. Once appveyor allows us to have command line deployment tasks then I can automate NPM, Gulp and Ruby deployments

[MeirionHughes]

gulp-gitversion would basically be a wrapper around gitversion with the src being the folder (?), plus a json parse and version selector. Once its setup I don't think you'll look at it again.

Edit; thinking about it. May well not need a gulp task anyway unless you do something special.

[gep13]

I think we should take ownership of it,

Yip, I was thinking the same, just wanted to make sure we are on the same page 😛

[JakeGinnivan]

FYI just looking at this, I would simply be creating a lightweight NPM package with a node api. I dont see us creating a gulp package, if you are using gulp you can still call node APIs and there are plenty of bridge projects.

Personally I just use NPM scripts

[MeirionHughes]

Fair enough, its easy enough to run your own code in a gulp task anyway.

To implement this, it might be easily done by simply calling the .net library/executable via https://github.com/tjanczuk/edge

[dazinator]

Being able to execute gitversion as a gulp task, could tie in to #647 - i.e you could update the project.json file also. Debatable whether gitversion would actually need to handle updating the project.json file itself, or whether we could just document a gulp task that pipes the git version supplied version number to another gulp tool to update the file..

[roryprimrose]

This would be great. I've just put together a SPA proof of concept that uses gulp. I want to create a nupkg of the gulp output to push to Octopus Deploy. Being able to update the version of the nuspec via GitVersion would be very handy.

[roryprimrose]

I got around this by using the GitVersion task in VSTS build vNext to populate the version details into build variables. I then used the nuget package build step which supports assigning the version from a build variable. Job done :)

[asbjornu]

If we did this, which variant of GitVersion should we base it on? Is it OK to require .NET Core installed in order to run an npm binary? How about Docker or Mono? Perhaps this should wait until we can AOT compile a single binary for every thinkable platform out there?

[dazinator]

Or we could create a cloud service... push your git branch to our own git server in the cloud then make an http request to get its version. The only two dependencies for that to work are git, and a http client like curl. Then charge a small subscription fee.. #justanidea :-)

[dazinator]

.. And then watch as we get zero customers - because everyone is fine using the dotnet cli global tool for gitversion that runs locally :-)

[asbjornu]

Haha, that sounds like a completely water-tight business plan, @dazinator! Will you do the setup? I'll join once the millions are pouring in to help alleviate you of all the excessive cash. 💵 😄

[MeirionHughes]

had another look and it seems someone has attempted to mimic how this lib works but for node packages: https://www.npmjs.com/package/git-semver-info

Doesn't look like its being maintained though.

could invite them to transfer into GitTools org and join. ;)

[arturcic]

There is an interesting global tool I found https://github.com/dgiagio/warp. We can basically wrap the .net core version into a single executable for each platform. Then we can use that executable for npx, or homebrew, or chocolatey, ruby gem. What do you think?

[dazinator]

@arturcic Yeah I have stumbled accross warp.
I know dotnet core cli have been working on also publishing to a single file (compressed, which gets auto decompressed when the app is first invoked by the cli) not quite as powerful as warp. It looks like the two can be used together though: https://www.hanselman.com/blog/MakingATinyNETCore30EntirelySelfcontainedSingleExecutable.aspx

[asbjornu]

Warp looks very interesting. Since it's only a simple command line, it shouldn't be hard to extend our build process to start producing some executables. We can then run that executable through most of our command line tests.

[gep13]

@asbjornu there is also a Cake.Warp addin that can be used 😄

[asbjornu]

Haha, that doesn't surprise me at all, @gep13. And by mentioning it, didn't you just volunteer to implement a spike for this? 😄

[gep13]

@asbjornu said...
And by mentioning it, didn't you just volunteer to implement a spike for this?

Hmmm.... wait... did I?!?! 😄

Honestly, I would love to, but right now, I don't have the bandwidth to take this on. Already juggling quite a few things just now, and I have a couple work trips coming up, so I can't commit to doing anything here. Happy to advice on any Cake related questions though.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

[clmcgrath]

any update on the status of this ?

[clmcgrath]

if this happens , adding the automatic file patching would be really nice feature to add for package.json files
currently running this outside of npm and manually patching the file via script currently

[dazinator]

I'm wondering if the following might suffice:

1. Install the gitversion dotnet cli global tool into your environment. This means you can now execute gitversion via the command line.
2. Use node / gulp to execute the gitversion command line and get the version info back for you to do whatever with.

This approach wouldnt require any special distribution of gitversion, just that gitversion command is available on your environment.

Not as convenient as pulling in gitversion as an npm package I grant, but it's less work (for gittools!)

[arturcic]

My solution I was thinking of is the following:

1. Create a GitVersionInstaller.ts - this one will download the one of the tar.gz assets depending on the platform example

2. GitVersion tool wrapper that will invoke the native executable

[arturcic]

It's similar in approach to the azure devops extension and Github action, but instead of the global tool it will use the native executable

[dazinator]

@arturcic - Yeah, installing the native self contained executable is nice, as then there is no pre-requisite on the user to install anything. Few questions though:

1. That install is 17mb (ish) - what if the user would prefer to install the tool once globally (to speed up build times on ci servers etc) - this ties in with next question:
2. Would you auto install the tool at a global level on their environment, or inside the current working directory, or somewhere else?

My suggestion wasn't really a solution ;-) - I was just attempting to bypass these questions by saying, let the user install the tool where they want, and then all we'd need to do initially is just document how to call gitversion executable from node and get back version information. However your solution I agree is the more fully fledged one - i.e automatically installing gitversion onto the environment!

[dazinator]

@arturcic oh also:

3. Would the proposed GitVersionInstaller.ts script be included in some gitversion npm package? (if not how would it be obtaine?). If so, could the native executables also be included in the same npm package - as npm itself already allows packages to be installed at a global or working directory level. If it's anything like nuget, it would have a global cache, so installing the package into local working directories wouldn't actually require a download of the package everytime, meaning the hit of having a single large package (containing linux, windows and macos native executables) shouldn't be too bad unless there is no package cache and I've got that wrong!

[arturcic]

to be honest I'd prefer not to embed as it will be too big. Better if we can download the platform specific version. As for the the script, it will be as an npm package that you can install and then call. I will be using typescript and then compile it to javascript. It's still in the ideas phase.

[arturcic]

2. Would you auto install the tool at a global level on their environment, or inside the current working directory, or somewhere else?

well the tar.gz contains only one file, I guess it will go in the node_modules/bin folder, so no need to install

[dazinator]

to be honest I'd prefer not to embed as it will be too big. Better if we can download the platform specific version.

Yeah I guess it's a tradeoff. If its a package that you are installing once globally, a larger initial download size would be weighed against the fact that we would be eliminating a class of potential run-time errors with downloads failing at execution time. For example if an organisation has allowed npm traffic through the firewall, consuming the npm package may be fine - if the npm package fails to install well that's an npm issue nothing to do with git version. However with the seperate download approach, the npm package may succeed but then when you execute the script the download (from github releases?) may fail. Or, there might be some other transient network fault that causes the download to fail etc. That would now become a GitVersion issue. This may be unlikely - but possible! That's all I can think of at the moment - either way you decide!

One last thought - I assume with the download approach, the script would be pinned to a specific release of gitversion? (i.e we wouldn't want it to just download the latest gitversion release, it would download gitversion from the same release as the package release right?)

[clmcgrath]

already do this now was hoping to not have to do it for every project any more , if your installing it as an npm package , i would think you would follow the same methodology as any other npm package , generally your bins deploy inside the package , and your entry command gets added to the .bin directory in node_modules
so unless the user installs with -g it should be locally run from node_modules

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

[PixnBits]

FWIW there is an npm package semantic-release that appears to be similar, and makes use of conventionalcommits.org.
[edit] In searching this repository I don't see any references to conventional commits, so #2395 I guess 😅

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

[hazzik]

stale bots are evil