FYI, I just migrated Quartz.NET to feedz.io, which supports anonymous feeds and has Open Source billing plan (5GB storage instead of free plans 2GB). The management portal supports organizations and repositories under then, also team members with different permissions.

quartznet/quartznet@8ce7d90

There's a link in the README that we should update with the new location for these: https://github.com/nunit/nunit/blob/master/README.md?plain=1#L19

We use github packages for work:

Push as:

dotnet nuget push --skip-duplicate --source https://nuget.pkg.github.com/nunit/index.json --api-key "${{secrets.GITHUB_TOKEN}}" '*.nupkg'

Use as (nuget.config):

<add key="NUnitGitHub" value="https://nuget.pkg.github.com/nunit/index.json" />

I don't know if user needs a password for a public repository.
For work we have a github enterprise account with internal repositories and have to add the following to setup .net:

    - name: Setup .NET
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: |
          6.0.x
          7.0.x
        source-url: https://nuget.pkg.github.com/nunit/index.json
      env:
        NUGET_AUTH_TOKEN: ${{secrets.GLOBAL_READ_PACKAGES_SECRET}}

Where the GLOBAL_READ_PACKAGES_SECRET is set by our enterprise admins.

The github documentation suggests it is not needed.

I guess I can create a build that pushes the package to github and then I can check if I can use it from home.
Watch this space.

@OsirisTerje Do we want to push every successful master build as a nuget package or manually on a tag?
Note sure how we want to deal with lifespan of packages. A question was unanswered.
Although github might be happy to store hundreds, not sure how charging is for nunit.

GitHub packages always requires API key, even for consumption. This is why I chose feedz.io to get friendlier usage experience (public feed not requiring auth).

Do we want to push every successful master build as a nuget package or manually on a tag?

This has been the way we have been doing it, so for the DEV builds, I think we should continue this practice.

However, we should get GitVersion in at some time, @CharliePoole use it on the console/engine project, and I have been using it a lot in work. When we have that, we can use tags to push to nuget.org for alpha, beta and prod versions.

About the needed authentication for consuming github packages that @lahma mentions, I agree that is not so user friendly. It seems to be confirmed by the github docs too. (Cool @manfred-brands if you actually test it)

I think we either way still should push to github packages, but we could also push to something else, like feedz.io or any other alternative feed that is in fashion at the given time.

And myget seems to be up again, but we could either move completely off it, or using that also as an alternative feed could be ok.

But this deployment action should run when the master is updated but not block any PRs.

@OsirisTerje Do we want to push every successful master build as a nuget package or manually on a tag? Note sure how we want to deal with lifespan of packages. A question was unanswered. Although github might be happy to store hundreds, not sure how charging is for nunit.

I set up a separate manual workflow (workflow_dispatch event trigger to be exact) to publish to NuGet that runs from main.

This way I can merge my features to main and have clean release labels on main but only publish at my discretion.

Version number is maintained in the csproj file.

Just another option.

@manfred-brands @lahma @stevenaw Since myget is up again, should we just postpone this ?

Yes. There were permission issues.

We turned off publishing to myget from appveyor in https://github.com/nunit/nunit/pull/4441/files

I think this means we don't currently publish dev packages from CI. Should we add myget to the current pipeline until the GitHub side gets sorted?

I believe the appveyor build was killed (and should stay so imho).

But, we could just create a separate action for publishing to myget, which only trigger on master/main.

We have a new action flow to push to myget, and we have a draft PR to push to github package repo, so closing this.