Provide private feed with official nightly build

[MarcoRossignoli]

We should provide official nightly build to allow users to consume fix/features ASAP and avoid to release official nuget packages, this help for some reason to me:

• New features fix could be "tested" in real project, for instance corefx codebase could pickup nuget package from private feed and do feedback very quick, corefx is used every day by a lot of dev(@ViktorHofer).

• Adding documetation for VSTest Integration #402 We are about to become The cross platform solution for Code Coverage generation for .NET Core projects(in a consistent manner). likely a lot of user will use coverlet from non win system.
  DataCollector will be picked up as nuget package, with private feed they can simply update PackageReference add private feed and consume fix/features in a fast way(@vagisha-nidhi).

We could start using:

• myget service for open source https://www.myget.org/opensource
• New github package registry https://github.com/features/package-registry

BTW I don't know if foundation could help with better choice cc: @onovotny
Maybe azure blob storage?

@tonerdo I propose also to move CI to Azure Pipelines, I found command trigger very useful to re-run pipeline https://docs.microsoft.com/en-us/azure/devops/pipelines/repos/github?view=azure-devops&tabs=yaml#comment-triggers at the moment I cannot re-run appveyor CI from PR, I don't know if it's supported.

/cc @tonerdo @petli

[MarcoRossignoli]

Per offline discussion...I take this for first part, generate packages and upload to some nuget server. cc: @tonerdo

[tonerdo]

Nightly feed: https://www.myget.org/feed/Packages/coverlet-dev

[MarcoRossignoli]

Index path https://www.myget.org/F/coverlet-dev/api/v3/index.json

[MarcoRossignoli]

closed in #425

[MarcoRossignoli]

Sorry re-open we'll close when documentation will be up-to-date

[MarcoRossignoli]

@AArnott I did some check on nighly build and it works...there is one problem we would have a correct order inside vs on Latest prerelease at the moment are ordered in an alphabetic way.
Do we need to use git height?
I would like to have something like 1.0.0-{height}-gxxxxxxxxxx in this way we should have a correct order and we update every offical release semver of nightly.
What do you think?Can you share your experience?

[AArnott]

Absolutely. Nb.gv can help you here. Do you want semver v1 compatible or go for v2?

[AArnott]

I'll go ahead and ask this too. Why nightly? Why not just published everything from your CI?

[MarcoRossignoli]

Absolutely. Nb.gv can help you here. Do you want semver v1 compatible or go for v2?

I think we go for v2 but wait @tonerdo confirmation
Today we don't release with any metadata https://www.nuget.org/packages/coverlet.msbuild/

I'll go ahead and ask this too. Why nightly? Why not just published everything from your CI?

The idea is to release a new "beta" package version every day we have new "commit" on master.
We publish a package to https://www.myget.org/F/coverlet-dev/api/v3/index.json and let users to try "fix" ASAP because as today we don't have a "rigorous" release plan(we're talking about it off line but for now it's TBD)
At the moment we did(as you seen on PR) a simple script scheduled every night at 00.00 that load new package using nb.gv git hash so we don't waste space on free plan of myget(max 1GB our 3 packages togheter are almost 4mb).

We could schedule a build at 00.00 of master, publish prerelase artifacts and remove current script, is this your idea?

[AArnott]

that load new package using nb.gv git hash

No reason for the git hash to be part of your package versions. Those are only added to guarantee uniqueness when building in anything other than your shipping branch(es). Your "nightly" build would presumably come from master, so you wouldn't need the hash. It can instead be a git height based integer, which will ensure you get the ordering right, which you voiced a concern about.

I don't think you need a nightly build. Your build is already super-fast, so just do everything in a CI. Then you can create an Azure Pipeline release that automatically pushes to your myget feed. The release can also have an environment defined for nuget.org. You can schedule that release to run every night at midnight if you want to keep myget current, and then when you want to publicize a release further you can take that same release and publish to your 'nuget.org' environment.

Then as you decide to stabilize for a (non pre-)release, the flow I recommend is that you us nbgv prepare-release which branches off of master and removes the -prerelease tag. master continues forward with the next major or minor version and retains a -prerelease tag while your vX.Y branch can stabilize until you release it. You can periodically merge your stabilization branch into master to keep fixes moving forward.

[MarcoRossignoli]

It can instead be a git height based integer, which will ensure you get the ordering right, which you voiced a concern about.

How we can know which heighted release refer to which master commit for troubleshooting?

[AArnott]

How we can know which heighted release refer to which master commit for troubleshooting?

1. Call nbgv get-commits <version> where <version> is the 3 or 4 integer version from the package or the assembly file version. See nbgv.
2. Work backwards through the releases in Azure Pipelines to find the version number that matches and look up the commit that the build was based on.

[MarcoRossignoli]

Thank's @AArnott for advice!

[AArnott]

Actually, nbgv get-commits isn't going to work well for you since you specify 3 version integers instead of the recommended 2. This is something that I should fix up and filed dotnet/Nerdbank.GitVersioning#340 to track.

In the meantime, how do you feel about moving your versioning to a major.minor.height pattern?

[MarcoRossignoli]

In the meantime, how do you feel about moving your versioning to a major.minor.height pattern?

I'm fixing "nightly release" with new versioning, I think could work for coverlet we could move only major.minor by hand and use automatic height for PATCH, I like it.
After that I'll move nightly release to release pipeline and will remove ps script to have a clean and simple workflow.
When nightly release will be ok(stable) and we feel ok with "new model"(we moved to AZP few time ago, I use AZP in my day by day job since 1.5 year as a full CICD for some asp.net core web sites but I never tackle lib versioning problem with that, so your guidelines are very appreciated and I'm taking advantage of it 😄 ) I think we could release all throught AZP.

[AArnott]

Actually, nbgv get-commits isn't going to work well for you

I've fixed it so it works great in your repo even with a.b.c versions specified in version.json. Those fixes were long overdue and are available in nbgv version 3.0.15-beta (pushing to nuget.org in moments), which you can install like this:

dotnet tool install -g nbgv --version 3.0.15-beta

That said, it sounds like you're considering removing the PATCH version from version.json, leaving just major.minor, which serves a lot of folks well, and will allow version numbers to be more precise (because both patch and revision integers in an assembly file version can be used to pinpoint the exact commit).

[MarcoRossignoli]

Only to track simple links at the moment we don't have the gallery enabled

https://www.myget.org/feed/coverlet-dev/package/nuget/coverlet.msbuild
https://www.myget.org/feed/coverlet-dev/package/nuget/coverlet.collector
https://www.myget.org/feed/coverlet-dev/package/nuget/coverlet.console