Added a .NET Core version of the Azure DevOps (vsts) build/release task. #1499

yohanb · 2018-10-15T20:05:17Z

Hi,
Here's a PR for the following request change:
#1496

I create a separate task specifically for .NET Core so it doesn't interfere with the current portable version.
I tested the task on my personal Azure DevOps account on a hosted Ubuntu agent and it works! It requires for .NET Core 2.0+ to be installed on the agent.

Let me know if I can do anything else to get this thing out in the wild.

Cheers.

arturcic · 2018-10-16T06:48:58Z

Thank you for the contribution. That will be a great step to support the Unix agents on Azure DevOps.

yohanb · 2018-10-16T14:02:24Z

@arturcic the build steps have failed because I added a new VsixNetCoreOutputFilePath parameter.

arturcic

@arturcic the build steps have failed because I added a new VsixNetCoreOutputFilePath parameter.

This parameter should be also included in the paths.cake as this parameter is later used for Publishing

arturcic · 2018-10-16T06:40:54Z

build.cake

@@ -276,6 +281,37 @@ Task("Pack-Tfs")
    });
 });

+Task("Pack-Tfs-NetCore")


I would keep the Pack tasks for TFS as a single task, similar to the way nuget packages are create. The packaging logic could be moved to a method in utils.cake and you just pass some arguments for mono based and dotnet core based version, and within the Pack-Tfs task you call the method for both variants

build.cake

arturcic · 2018-10-16T06:45:48Z

build.cake

@@ -238,6 +238,11 @@ Task("Copy-Files")
    CopyFileToDirectory(portableDir + "/" + "GitVersion.exe", tfsPath);
    CopyDirectory(portableDir.Combine("lib"), tfsPath.Combine("lib"));

+    // Vsix dotnet core
+    var tfsNetCorePath = new DirectoryPath("./src/GitVersionTfsTask.NetCore/GitVersionTask");


I would prefer to have the second TFS task in the same ./src/GitVersionTfsTask root folder, but in a different GitVersionNetCoreTask child folder, just to keep everything related to TFS in the same root folder. That means we need to change a little the structure of the GitVersionTfsTask folder.

OK, I'll find the time to rework the folders this week.

Thanks, you can have as inspiration the way here it is structured

yohanb · 2018-10-25T15:45:58Z

hey @arturcic ,
I modified the code as you requested. I haven't really validated it works besides the cake build and packaging.
Keep me posted!

arturcic · 2018-10-31T07:40:59Z

@yohanb, I'll have a look soon, thanks

mitchdenny · 2018-11-05T03:45:18Z

Would love to see this merged :)

arturcic · 2018-11-05T08:57:20Z

@yohanb Can you please make the changes so that we can move forward? We should also consider using azure-pipelines-task-lib npm package as vsts-task-lib is deprecated (details)

src/GitVersion.sln

src/GitVersion.sln.DotSettings

src/GitVersionCore/AssemblyInfo.cs

src/GitVersionExe/AssemblyInfo.cs

src/GitVersionRubyGem/gitversion.gemspec

src/GitVersionTfsTask/vss-extension.json

src/GitVersionTfsTask/GitVersion.ts

src/GitVersionTfsTask/GitVersionTask/task.json

yohanb · 2018-11-05T15:50:54Z

@arturcic done making the changes.

arturcic · 2018-11-05T17:49:12Z

Looks great! I have run the build locally and it seems the paths to the vsix (the ones used for publishing) differ from the actual paths

Can you update the path here? https://github.com/GitTools/GitVersion/pull/1499/files#diff-faf8aebe07f0c09fe65d5a4be490bb83R43

build/paths.cake

arturcic · 2018-11-05T18:23:46Z

there is one missing line you should add so that the new vsix file is published to AppVeyor and to the marketplace https://github.com/GitTools/GitVersion/blob/master/build/parameters.cake#L106, Please add the netcore path as well.

yohanb · 2018-11-05T18:43:23Z

there is one missing line you should add so that the new vsix file is published to AppVeyor and to the marketplace https://github.com/GitTools/GitVersion/blob/master/build/parameters.cake#L106, Please add the netcore path as well.

done

arturcic · 2018-11-05T19:19:02Z

@yohanb Looks great to me. Can we prepare it for merge by squashing all the commits as one commit? Then you can rebase it on master, to keep the commit history clean? Thanks

yohanb · 2018-11-05T19:43:12Z

@arturcic do you mean rebase on my forked master and create another PR for yohanb:master -> gittools:master ?

arturcic · 2018-11-05T19:45:30Z

@arturcic do you mean rebase on my forked master and create another PR for yohanb:master -> gittools:master ?

looks like a simple squash is not possible as you have merged the master already, So all the commits after the master merge commit can be squashed. Need to think about

yohanb · 2018-11-05T19:54:32Z

@arturcic do you mean rebase on my forked master and create another PR for yohanb:master -> gittools:master ?

looks like a simple squash is not possible as you have merged the master already, So all the commits after the master merge commit can be squashed. Need to think about

it should be possible to simply squash and commit the PR according to the docs:
https://help.github.com/articles/about-pull-request-merges/#squash-and-merge-your-pull-request-commits

arturcic · 2018-11-05T21:00:12Z

it should be possible to simply squash and commit the PR according to the docs:
https://help.github.com/articles/about-pull-request-merges/#squash-and-merge-your-pull-request-commits

ok then, give it a try.

yohanb · 2018-11-05T22:01:10Z

it should be possible to simply squash and commit the PR according to the docs:
https://help.github.com/articles/about-pull-request-merges/#squash-and-merge-your-pull-request-commits

ok then, give it a try.

can't

arturcic · 2018-11-06T08:25:57Z

here is the way you can do that in terminal

git reset --soft 1a842897 - this will reset to the first commit when you created the branch, but will keep the changes
git add . - staging the squashed changes
git commit -m "Added a .NET Core version of the Azure DevOps (vsts) build/release task." - commit the changes
git rebase master - rebase on master
fix the conflicts
git rebase --continue - you have rebased
Now you can force push and you're done

yohanb · 2018-11-06T18:50:03Z

@arturcic everything is clean and rebased on my forked master. How do you wish to commit the changes upstream to this repo?

arturcic · 2018-11-06T18:54:55Z

@yohanb first of all you should push (forced) to your origin, this way it will appear on your origin master branch and it will automatically appear here. So the history will be overwritten.

yohanb · 2018-11-06T19:06:19Z

@yohanb first of all you should push (forced) to your origin, this way it will appear on your origin master branch and it will automatically appear here. So the history will be overwritten.

ok thanks, I forgot to force push on this feature branch. Not used to rewriting git history 🤣
here goes nothing!

arturcic · 2018-11-06T19:33:48Z

@yohanb. I have fixed the rebase conflict and ran the build. The changes are ready for merging. I'll merge the PR. Thanks for the contribution and the patience.

jmezach · 2018-11-06T19:37:02Z

Awesome work guys!

yohanb · 2018-11-06T19:46:24Z

@yohanb. I have fixed the rebase conflict and ran the build. The changes are ready for merging. I'll merge the PR. Thanks for the contribution and the patience.

My pleasure. Hopefully this will enable greater adoption of GitVersion no matter the platform!

jmezach · 2018-11-07T07:15:17Z

@arturcic Looks like the new extension version isn't yet available on the Marketplace. Is there a manual step still involved to make that happen?

arturcic · 2018-11-07T07:17:00Z

that's right, and that's because the marketplace does not allow to publish pre-release versions, and we'll get a new version on marketplace when we have a stable version released

jmezach · 2018-11-08T13:02:03Z

I see. Do you have an idea when that will happen? We could greatly benefit from this since we would no longer have to delay our macOS and Linux builds for the Windows builds to finish.

arturcic · 2018-11-08T13:07:25Z

As far as I know we don't have a well defined milestones structure with issues that need to be included in one release or another. I guess we need that, @gep13 , @JakeGinnivan , @asbjornu - do you have anything to add?

jmezach · 2018-11-08T13:11:56Z

Perhaps a preview version of the Azure DevOps extension could be useful as well. I'm developing an open source extension myself as well and from our CI pipeline we build and package the preview version of the extension and we just monotonically increase the patch version number. Then when we ship we use the GitVersion generated version as the version number. This allows us to dogfood the extension ourselves and we could even share the preview extension with specific accounts if we want.

asbjornu · 2018-11-08T16:09:54Z

We don't have a well defined process for stable releases, no. Is it so that this particular PR is impossible to actually test without it being published to Azure DevOps, which we can't do until it has a stable version number?

arturcic · 2018-11-08T16:13:52Z

It is possible to test locally the tasks as they are nodejs apps, but to check how they work on Azure DevOps as part of the build you need to install it as far as I know

jmezach · 2018-11-08T19:03:02Z

@arturcic @asbjornu Yes, you can only test an Azure DevOps extension by uploading it to the Marketplace and as far as I know it only supports major.minor.patch versions and no -prerelease tags.

However as I mentioned you can have a separate extension (with a different id in the vss-extension.json) that can be marked as preview and can even be private (as in, only available in your own account or shared with specific accounts). You can then simply increment the patch version every time you build and upload the extension automatically. Then when you're ready to ship you can change the ID of the extension to the original one and use the appropriate version number.

I'm currently using this extension to automate that inside of my CD pipeline.

asbjornu · 2018-11-09T08:25:36Z

@jmezach: That sounds like a neat solution. How do we set up something like that and who can do it? I don't use Azure DevOps, so I don't even know where to start.

arturcic · 2018-11-09T09:39:51Z

@jmezach thanks for suggestion. I'll think about this, and probably we'll have a separate extension for pre-release - something like GitVersion-beta or similar.

However as I mentioned you can have a separate extension (with a different id in the vss-extension.json) that can be marked as preview and can even be private

Are you talking about this ?

jmezach · 2018-11-09T09:43:08Z

So the way that I've set this up currently is the the vss-extension.json in our source repository uses the ID augurk.augurk-preview. We process that through our CI pipeline to generate a .vsix with the -preview tag. We upload that .vsix as an artifact associated with a particular build.

Then in our release pipeline (not sure if you can actually see this, but I hope so ;)) we've defined two stages: staging and production. In the staging stage we use tasks from the extension I mentioned earlier to determine the version of the preview extension that's currently on the Marketplace. We then increase the patch number, repackage the VSIX and upload it to the Marketplace. Once that's done we are able to try out the extension within our own Azure DevOps account, but it's not visible to other accounts unless we explicitly share it with them.

When we're ready to ship (which usually means merging the changes to the master branch) we process it through the same pipeline and then promote it to production. In that stage we repackage the extension and remove the -preview tag and also stamp the correct version number (as generated by GitVersion) into it. After that anyone can use the new version of the extension.

@arturcic Yes, that is exactly what I'm talking about. In fact, you could even have a stage where the extension is just private and marked as preview, then a public version that's marked as preview and a public version that is the released version. That's not what we're doing, but it's definitely an option.

arturcic · 2018-11-09T09:47:33Z

Thanks for explanation. I guess we can have a GitVersion-preview extension that will be public and in preview, and it will be updated on every pre-release build. On stable release we'll pack the extension as GitVersion as it is now. Same for the second extension - the one running on .net core.

jmezach · 2018-11-09T10:08:24Z

Sounds like a great plan. Looking forward to trying it out.

asbjornu · 2018-11-09T10:50:47Z

@arturcic: That sounds like a great plan. How do we implement it? Do you have the required time and expertise to do it?

arturcic · 2018-11-09T10:54:50Z

I don't have much time, but will try to find some. The implementation is just in the build script - we check if it's stable release or pre-release, and we add the suffix or not in the vss-extension.json. Basically we change this json file depending on the type of the release.

yohanb · 2018-11-09T14:37:22Z

happy to see things moving here! 👍

until GitTools/GitVersion#1499 is released. Also follow: GitTools/GitVersion#1527

* Integrate with GitVersion for SemVer * Adding mono-complete and libcurl3 to ubuntu build * Attempt to fix yml issues * Disabling SemVer in linux build until GitTools/GitVersion#1499 is released. Also follow: GitTools/GitVersion#1527

This was referenced Oct 15, 2018

GitVersion on VSTS fails with hosted macOS and Linux agents #1497

Closed

GitVersion 4.0.0 fails on VSTS #1496

Closed

arturcic self-requested a review October 16, 2018 06:02

arturcic reviewed Oct 16, 2018

View reviewed changes

arturcic requested changes Nov 5, 2018

View reviewed changes

arturcic mentioned this pull request Nov 5, 2018

VSTS GitVersion Task Icon is Missing in build #1517

Closed

arturcic requested changes Nov 5, 2018

View reviewed changes

src/GitVersionTfsTask/GitVersionTask/task.json Outdated Show resolved Hide resolved

arturcic reviewed Nov 5, 2018

View reviewed changes

build/paths.cake Outdated Show resolved Hide resolved

yohanb closed this Nov 5, 2018

yohanb reopened this Nov 5, 2018

Added a .NET Core version of the Azure DevOps (vsts) build/release task.

0e4c3fd

yohanb force-pushed the feature/dotnet-core-vsts-task branch from 11f697d to 0e4c3fd Compare November 6, 2018 19:04

Merge branch 'master' into feature/dotnet-core-vsts-task

c607386

arturcic approved these changes Nov 6, 2018

View reviewed changes

arturcic merged commit 067882f into GitTools:master Nov 6, 2018

yohanb deleted the feature/dotnet-core-vsts-task branch November 6, 2018 20:41

arturcic mentioned this pull request Nov 9, 2018

Azure DevOps add preview extensions #1527

Closed

BrandonBoone added a commit to BrandonBoone/Spritey that referenced this pull request Nov 16, 2018

Disabling SemVer in linux build

eedc9e0

until GitTools/GitVersion#1499 is released. Also follow: GitTools/GitVersion#1527

Added a .NET Core version of the Azure DevOps (vsts) build/release task. #1499

Added a .NET Core version of the Azure DevOps (vsts) build/release task. #1499

Conversation

yohanb commented Oct 15, 2018

arturcic commented Oct 16, 2018

yohanb commented Oct 16, 2018

arturcic left a comment • edited Loading

Choose a reason for hiding this comment

arturcic Oct 16, 2018

Choose a reason for hiding this comment

arturcic Oct 16, 2018

Choose a reason for hiding this comment

yohanb Oct 17, 2018

Choose a reason for hiding this comment

arturcic Oct 17, 2018

Choose a reason for hiding this comment

yohanb commented Oct 25, 2018 • edited Loading

arturcic commented Oct 31, 2018

mitchdenny commented Nov 5, 2018

arturcic commented Nov 5, 2018 • edited Loading

yohanb commented Nov 5, 2018 • edited Loading

arturcic commented Nov 5, 2018

arturcic commented Nov 5, 2018

yohanb commented Nov 5, 2018

arturcic commented Nov 5, 2018

yohanb commented Nov 5, 2018

arturcic commented Nov 5, 2018

yohanb commented Nov 5, 2018

arturcic commented Nov 5, 2018

yohanb commented Nov 5, 2018

arturcic commented Nov 6, 2018 • edited Loading

yohanb commented Nov 6, 2018

arturcic commented Nov 6, 2018

yohanb commented Nov 6, 2018

arturcic commented Nov 6, 2018

jmezach commented Nov 6, 2018

yohanb commented Nov 6, 2018

jmezach commented Nov 7, 2018

arturcic commented Nov 7, 2018 • edited Loading

jmezach commented Nov 8, 2018

arturcic commented Nov 8, 2018

jmezach commented Nov 8, 2018

asbjornu commented Nov 8, 2018

arturcic commented Nov 8, 2018

jmezach commented Nov 8, 2018

asbjornu commented Nov 9, 2018

arturcic commented Nov 9, 2018

jmezach commented Nov 9, 2018

arturcic commented Nov 9, 2018

jmezach commented Nov 9, 2018

asbjornu commented Nov 9, 2018

arturcic commented Nov 9, 2018

yohanb commented Nov 9, 2018

arturcic left a comment •

edited

Loading

yohanb commented Oct 25, 2018 •

edited

Loading

arturcic commented Nov 5, 2018 •

edited

Loading

yohanb commented Nov 5, 2018 •

edited

Loading

arturcic commented Nov 6, 2018 •

edited

Loading

arturcic commented Nov 7, 2018 •

edited

Loading