Publish NuGet Packages Using GitHub Actions
A walkthrough on how we published NetLicensing C# Client library to NuGet repository using GitHub Actions.
Join the DZone community and get the full member experience.
Join For FreeUnbelievable! 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.
Background Info — GitHub Flow
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 'master'
branch.
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
'master'
Create Actions Workflow
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 the repository
.github/workflows
directory.
xxxxxxxxxx
name NetLicensing C# Client — CI
on
push
branches master
pull_request
branches master
jobs
build
runs-on ubuntu-latest
steps
uses actions/checkout@v2
name Setup .NET Core
uses actions/setup-dotnet@v1
with
dotnet-version'3.1.x'
name Install dependencies
run dotnet restore
name Build
run dotnet build --configuration Release --no-restore
name Test
run dotnet run --project NetLicensingClient-demo
Publish NuGet Package
After Pull Request merge and successful “CI” workflow run, we trigger a second “Release” workflow to push 'master'
branch code base to NuGet.
xxxxxxxxxx
name NetLicensing C# Client - Release
on
workflow_run
workflows"NetLicensing C# Client - CI"
branches master
types
completed
jobs
publish-nuget
runs-on ubuntu-latest
steps
uses actions/checkout@v2
name Setup .NET Core
uses actions/setup-dotnet@v1
with
dotnet-version'3.1.x'
name Install dependencies
run dotnet restore
name Build
run dotnet build --configuration Release --no-restore
name Publish to NuGet
uses brandedoutcast/publish-nuget@v2
with
PROJECT_FILE_PATH NetLicensingClient/NetLicensingClient.csproj
VERSION_REGEX'^\s*<PackageVersion>(.*)<\/PackageVersion>\s*$'
TAG_FORMAT'*'
NUGET_KEY $ secrets.NUGET_API_KEY
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 PROJECT_FILE_PATH
and NUGET_KEY
.
Create NuGet API Key
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
The 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.
Execution
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 the NuGet package. Voilà!
Manual Tasks and Open Points
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.
Published at DZone with permission of Labs64 NetLicensing. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
Tomorrow’s Cloud Today: Unpacking the Future of Cloud Computing
-
How Agile Works at Tesla [Video]
-
4 Expert Tips for High Availability and Disaster Recovery of Your Cloud Deployment
-
Which Is Better for IoT: Azure RTOS or FreeRTOS?
Comments