GitHub Actions - automate, CI, package and push your .NET libraries to NuGet.org
Unbelievable! One of the oldest NetLicensing Client libraries for C# (with the first GitHub push made on Oct 2, 2013) was not available in one of the essential package managers for .NET
Better late than never - so we decided to change this status quo, and today want to share with you our this walkthrough on how we published NetLicensing C# Client library to NuGet repository using GitHub Actions.
Before moving forward, just a note about GitHub Flow workflow adopted for Labs64 projects hosted at GitHub.
“Pull Request” or “PR” is a very useful feature of the GitHub version control system and allowing efficient feature and bugfix development with the GitHub Flow.
The below diagram showing GitHub Flow adopted for Labs64 projects:
Any new feature or defect fix implementation is being done only in a dedicated feature branch. When branch implementation is ready to be integrated into the master branch, a Pull Request gets created. Using this PR, team members, working on a particular feature/enhancement/bug fix, can get feedback from other team members along the way.
This feedback is being used to make further changes and commits to the branch before finally merging the changes back up to the
For the above GitHub Flow following workflows will be defined:
- CI - build and test push commits at Pull Request branches and master
Release - package and publish C# library after successful CI run on
There are two ways how you can create a new GitHub Actions workflow:
Wizard - Use predefined configurations for your environment and technology stack. GitHub Actions offering heaps of community built actions that cover the whole #devops spectrum.
Manually - Create a new workflow YAML file in repository
- Manually - Create a new workflow YAML file in repository
This is the full YAML we are using for Continuous Integration runs upon every push in
'master' and feature branches. It uses actions to setup .NET Core, restore packages, build and test code base by executing NetLicensingClient-demo CLI project.
After Pull Request merge and successful "CI" workflow run, we trigger a second "Release" workflow to push
'master' branch code base to NuGet.
brandedoutcast/publish-nuget community action definition provides a very useful option to Publish Nuget packages every time the new project version is available.
The action by default looks for changes to the
<version></version> tag in your
.csproj file, which we had to tweak in our case using
VERSION_REGEX configuration parameter to
'^\s*<PackageVersion>(.*)<\/PackageVersion>\s*$' to match the format of the Visual Studio 2019.
For a basic action setup, you only need to set
NuGet API key needs to be created and added to GitHub Actions to authenticate publish requests to NuGet.
In the key creation dialogue provide:
- Key Name - use this name to easily identify the API key scope
- Package Owner - your NuGet account
- Select Scope- choose "Push new packages and package versions"
Glob Pattern - use
"*"to select all packages
Created API key needs to be added to the GitHub repository "Secrets" section.
In our configuration we use
NUGET_API_KEY as a key name; you can choose the name accordingly to your name schema, however.
After your GitHub Actions setup is complete the CI workflow will be executed every time you push changes in master or feature branch.
After the successful merge and incremented project version number, the Release workflow will start and publish NuGet package. Voilà!
Having the most of the steps automated we still have some minor but essential manual steps:
- GitHub release version - create a new GitHub release version for the created tag
- NuGet package documentation - provide a link to the prepared README-nuget.md file in the "Manage package" at NuGet
- Increase project next development version in Visual Studio
Possibly, there are some handy automation options available for the above manual tasks. We will be happy for any suggestions from the community.