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}
refs/tags/v*	#.#.#

See: open-feature/dotnet-sdk#54, open-feature/dotnet-sdk#173

---

Note

This PR is a little more expansive than open-feature/dotnet-sdk#173 because I combined the separate os-specific workflow files to (1) better align with what already existed in open-feature/dotnet-sdk, and (2) easily gate the package publishing on the success of both os-specific CI checks.

Upon request, I'm more than willing to split the workflow combining out into a standalone PR that will need merged before this one, but opening as an all-in-one for the time being to keep things simple.

[austindrenski]

Need to react to reviews from open-feature/dotnet-sdk#173.

[austindrenski]

N.B. <VersionSuffix> will still be overridden in CI builds to be, e.g., 0.0.1-ci.$(date -u +%Y%m%dT%H%M%S)+sha.${GITHUB_SHA:0:9} when --version-suffix ... is passed, but 0.0.1-preview when no --version-suffix ... is passed, as in the release.yml workflow.

[austindrenski]

Clicking on the nupkgs artifact will download nupkgs.zip containing:

$ unzip -d nupkgs nupkgs.zip
$ tree nupkgs
nupkgs
├── OpenFeature.Contrib.Hooks.Otel
│   └── bin
│       └── Release
│           └── OpenFeature.Contrib.Hooks.Otel.0.1.3-pr.20240120T001332.nupkg
├── OpenFeature.Contrib.Providers.ConfigCat
│   └── bin
│       └── Release
│           └── OpenFeature.Contrib.Providers.ConfigCat.0.0.1-pr.20240120T001332.nupkg
├── OpenFeature.Contrib.Providers.FeatureManagement
│   └── bin
│       └── Release
│           └── OpenFeature.Contrib.Provider.FeatureManagement.0.0.1-pr.20240120T001332.nupkg
├── OpenFeature.Contrib.Providers.Flagd
│   └── bin
│       └── Release
│           └── OpenFeature.Contrib.Providers.Flagd.0.1.7-pr.20240120T001332.nupkg
├── OpenFeature.Contrib.Providers.Flagsmith
│   └── bin
│       └── Release
│           └── OpenFeature.Contrib.Providers.Flagsmith.0.1.5-pr.20240120T001332.nupkg
└── OpenFeature.Contrib.Providers.GOFeatureFlag
    └── bin
        └── Release
            └── OpenFeature.Contrib.GOFeatureFlag.0.1.5-pr.20240120T001332.nupkg

[austindrenski]

Note

Note: these instructions are also available in CONTRIBUTING.md

Following open-feature/dotnet-sdk#173, it is now possible for this repo to consume pre-release packages from open-feature/dotnet-sdk 🎉

This file provides dotnet restore with a mapping of where to look for packages. For example, if a project in this repo references a pre-release version of OpenFeature, dotnet restore will first look in the nuget source, and when the pre-release version is not found, it will proceed to checking in the github-open-feature source.

Currently, this repo does not yet reference any pre-release package versions, so there is no action required today for contributors.

However, contributors can prepare their local environments using the following instructions:

1. Acquire a GitHub personal access token (PAT) scoped for read:packages and verify the permissions:

   $ gh auth login --scopes read:packages
   
   ? What account do you want to log into? GitHub.com
   ? What is your preferred protocol for Git operations? HTTPS
   ? How would you like to authenticate GitHub CLI? Login with a web browser
   
   ! First copy your one-time code: ****-****
   Press Enter to open github.com in your browser...
   
   ✓ Authentication complete.
   - gh config set -h github.com git_protocol https
   ✓ Configured git protocol
   ✓ Logged in as ********

   $ gh auth status
   
   github.com
     ✓ Logged in to github.com as ******** (~/.config/gh/hosts.yml)
     ✓ Git operations for github.com configured to use https protocol.
     ✓ Token: gho_************************************
     ✓ Token scopes: gist, read:org, read:packages, repo, workflow

2. Run the following command to configure your local environment to consume packages from GitHub Packages:

   $ dotnet nuget update source github-open-feature --username $(gh api user --jq .email) --password $(gh auth token) --store-password-in-clear-text
   
   Package source "github-open-feature" was successfully updated.

Related

• https://cli.github.com
• https://learn.microsoft.com/nuget/consume-packages/package-source-mapping

[beeme1mr]

Will this change impact the Publish to Nuget step?

[austindrenski]

Nope, it should not, because in that step we explicitly pass the requisite API token.

This pattern here is just telling actions/setup-dotnet to (more or less) run dotnet nuget update source ... for this source-url using the ambient NUGET_AUTH_TOKEN while setting up the SDK.

As an alternative to pre-configuring this source-url here, we could instead pass additional sources and tokens to dotnet restore, but that gets really messy really fast, so the usual pattern is to just pre-configure your authenticated NuGet sources as part of setting up the .NET SDK.

I get this question a lot in repos where I'm setting up GitHub Actions for the first time, so often find myself wishing they had instead implemented source-url as source-urls: [ ... ] which would let us be more expressive about NUGET_AUTH_TOKEN being for, and only for, one source-url, but as things stand repos that want to pre-wire two auth'd feeds just end up running this step twice, once for each source-url and NUGET_AUTH_TOKEN.

Here's a snippet from the CI logs that kind of allude to this^ story (albeit, not very clearly, but if you squint you can kind of picture what its doing):

[beeme1mr]

Suggested change

	<Description>OpenFeature is an open standard for feature flag management, created to support a robust feature flag ecosystem using cloud native technologies. OpenFeature will provide a unified API and SDK, and a developer-first, cloud-native implementation, with extensibility for open source and commercial offerings.</Description>
	<Description>OpenFeature is an open specification that provides a vendor-agnostic, community-driven API for feature flagging that works with your favorite feature flag management tool or in-house solution.</Description>

I know this wasn't the intention of the PR, but it's probably worth updating. This updated phrasing is what we use throughout the project.

[austindrenski]

Obvi no objection to fixing this description, but I did wonder while drafting this if we should have this description here at all, given that components override it with their own descriptions, as instructed by CONTRIBUTING.md.

Alternatively, I wondered if perhaps the intent of CONTRIBUTING.md was for the components to use something like <Description>$(Description)\n\n....</Description> so this^ description would be embedded at the top of each component's package page.

Thoughts?

[toddbaert]

This all looks consistent with the related SDK changes. Thanks!

[austindrenski]

🥳 🥳 🥳 🥳

[toddbaert]

This is great! Thanks @austindrenski .

I really like the idea of puslishing CI builds to GH... we might be able to use this in some other repos as well. Sure, it requires auth, but I think it's mostly useful to devs who want to do manual testing or experimentation.