chore: Add support for GitHub Packages

[austindrenski]

GITHUB_REF	version format
refs/heads/*	#.#.#-ci.{%Y%m%d}T{%H%M%S}+sha.${GITHUB_SHA:0:9}
refs/pull/*	#.#.#-pr.{%Y%m%d}T{%H%M%S}+sha.${GITHUB_SHA:0:9}

See: #54, open-feature/dotnet-sdk-contrib#134

Closes: #54

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (f47cf07) 0.00% compared to head (0a0273d) 93.86%.

Additional details and impacted files

@@            Coverage Diff            @@
##           main     #173       +/-   ##
=========================================
+ Coverage      0   93.86%   +93.86%     
=========================================
  Files         0       23       +23     
  Lines         0      946      +946     
  Branches      0      105      +105     
=========================================
+ Hits          0      888      +888     
- Misses        0       34       +34     
- Partials      0       24       +24     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[austindrenski]

Well, still failed, but now I'm pretty sure it's just the fork issue. Assuming ${{ secrets.NUGET_TOKEN }} is available to others, then this will work as is, otherwise, I can update the conditions to skip publishing from forks.

[benjiro]

FYI the secrets.NUGET_TOKEN is for nuget.org registry but looking at this change its pushing to github registry. Also i believe forks won't have access to any secrets from memory. You might need to update the permissions on the workflow to get write access to github registeries on the secrets.GITHUB_TOKEN that the action runner generates https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs#defining-access-for-the-github_token-scopes

One problem with using githubs nuget registry is you need a github account setup to pull down the packages (this could of change since last time i checked). This is why i originally suggested using something like MyGet which offer free accounts for OpenSource projects.

I think gating the prerelease packages behind auth defeats the purpose, and makes for a cumbersome developer experience. Happy to go a head with it if people are fine with that.

[austindrenski]

FYI the secrets.NUGET_TOKEN is for nuget.org registry but looking at this change its pushing to github registry. Also i believe forks won't have access to any secrets from memory. You might need to update the permissions on the workflow to get write access to github registeries on the secrets.GITHUB_TOKEN that the action runner generates https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs#defining-access-for-the-github_token-scopes

Bah, I knew there was something I was forgetting. Thanks, will update.

One problem with using githubs nuget registry is you need a github account setup to pull down the packages (this could of change since last time i checked). This is why i originally suggested using something like MyGet which offer free accounts for OpenSource projects.

I think gating the prerelease packages behind auth defeats the purpose, and makes for a cumbersome developer experience. Happy to go a head with it if people are fine with that.

Full agree that GitHub should just give us the option to allow un-auth'd package retrieval for OSS projects, but I also don't think the auth requirement is all that big of a blocker.

Now this could be some corporate dev bias, but of all the authenticated feeds I have to deal with at my day job, GitHub Packages is the least annoying of them lol.

But bigger picture, I think providing prerelease packages directly from GitHub is a really useful solution for discoverability, plus if you're already setup to consume one GitHub package feed, then that auth carries over to the N+1 feed too.

So wouldn't ever recommend we only publish to GitHub Packages (e.g. as opposed to, say, nuget.org), but I think it's a really nice built-in option that comes pretty much for free (as in beer/time) and offers a nice UX in terms of code+packages+releases all in one place.

(also, none of what I'm saying here precludes also publishing to myget in addition to github, I'm just saying there's no reason to not offer github while we're at it.)

[toddbaert]

I think this is wrong. I could be missing something, but pull_request_target runs in the context of the base branch - so this will make all our CI tests run the code in main, not the code in whatever PR.

[austindrenski]

I think this is wrong. I could be missing something, but pull_request_target runs in the context of the base branch - so this will make all our CI tests run the code in main, not the code in whatever PR.

Geeze, I think you're right. I'm not sure what I was doing when I changed that (testing token perms, maybe?).

Reverting now.

[toddbaert]

Is this because we're not building on Windows in the job? Will this have any impact on the release build (it does run on windows)?

[austindrenski]

Is this because we're not building on Windows in the job?

Yep! It gives dotnet build enough context to build the net462 TFM on Linux, so we can run package builds on ubuntu-latest which, among other reasons, runs circles around windows-latest for dotnet restore and anything else that uses compression:

• windows-latest:

  Run dotnet test test\OpenFeature.Tests\ --configuration Release --logger GitHubActions
    Determining projects to restore...
    Restored D:\a\dotnet-sdk\dotnet-sdk\src\OpenFeature\OpenFeature.csproj (in 21.2 sec).
    Restored D:\a\dotnet-sdk\dotnet-sdk\test\OpenFeature.Tests\OpenFeature.Tests.csproj (in 1.69 min).
  

• ubuntu-latest:

  Run dotnet test test/OpenFeature.Tests/ --configuration Release --logger GitHubActions
    Determining projects to restore...
    Restored /home/runner/work/dotnet-sdk/dotnet-sdk/src/OpenFeature/OpenFeature.csproj (in 5.33 sec).
    Restored /home/runner/work/dotnet-sdk/dotnet-sdk/test/OpenFeature.Tests/OpenFeature.Tests.csproj (in 5.5 sec).
  

Will this have any impact on the release build (it does run on windows)?

It should have no impact since it's conditioned on the OS var and the reference assemblies won't be included in the compilation, leaving dotnet to find the actual assemblies in the GAC (or on disk, can't remember which it actually checks, so don't quote me on this part).

But it does mean, that once everyone is comfortable with it (i.e. this workflow runs without issues a few times), we could then update release.yml to run on ubuntu-latest too.

That workflow obviously runs less frequently than ci.yml, so the dotnet restore perf won't be as big of a consideration in that case, but I personally feel better building my internal stable releases on the ubuntu-latest runners. Things just always seem to work better there lol (e.g. cli perf, line endings, etc).

edit: opened #195 for later

[toddbaert]

Makes sense. I'm in favor of that change in the future. Thanks for the explanation 🙏

recent changes

[toddbaert]

Approving again, and will merge in a moment, but consider this.

[austindrenski]

Woohoo, it lives! 🥳🥳🥳

• https://github.com/open-feature/dotnet-sdk/pkgs/nuget/OpenFeature