GitHub Actions and sample NuGet-based library

We all use libraries from NuGet tremendously often. But how many times you’ve created your own, even the simplest library that is being published there? I expect, not so often… So do I. Thus, I decided to make the super simple example of doing that, while utilizing the new and shiny GitHub Actions for all automations.

This serves many purposes, as often when I do something:

• Minimum Viable Product (or example) of creating your own library that is automatically tested/versioned and published as a NuGet package – it requires to combine various building blocks and it turns out to be not-so-trivial. My goal would be to provide it as a kind of template for creating a new NuGet-based libraries.
• playground for fresh open source contributors that are willing to do some contributions that will be then propagated to a regular NuGet package – without a risk and fear of destroying something
• funny, joke-like package that, still, may be extended/improved
• and obviously, a great place to learn all this stuff (including me)

So this is how Strings.Abbreviations has been coined. A very simple C#-based library that makes the simplest thing I could imagine – provide sets of methods that resolve popular abbreviations like BRB or IMHO. For example Strings.BRB() with return “Be right back” string. To add some “logic”, there is an additional option to use “title casing”. So, Strings.BRB(titleCase: true) will return “Be Right Back”.

Obviously, this is trivial but it is by design! Thanks to that there is a very low entrance level for any contributor. Additionally, automation workflow is not hidden inside the complex logic and dependencies.

Initial design

So, this repository is based on a regular solution containing .NET Core library and test project. After the recent PR, there is also a trivial F#-based library (because we can!). As I said, the core part here is that Strings.Abbreviations is build, tested and published as a NuGet package with the use of Github Actions. All workflows we define are living inside the repository under .github/workflows folder. Currently there are two working workflows defined.

Building and testing

Every push and PR to master will trigger building and unit testing the whole solution. What’s super nice – thanks to that the result of the tests are available as an additional PR check. And we have a “badge” available on the top of this file (we will return to that).

Setting this was trivial, as we can use the default .NET Core workflow suggested when using Actions for the very first time. Underneath this workflow uses dotnet restore/build/test commands.

Building and publishing a NuGet package

Every push to master that bumps up Version in the Strings.Abbreviations.csproj file will trigger building and publishing a new NuGet package. Additionally, a new git tag will be pushed with the given version. It uses Publish NuGet custom Github Action which was also really easy to set up thanks to the documentation. All package data are taken from csproj file (no need for a separate .nuspec file). The only additional thing required here is to add NUGET_API_KEY secret key from the repository Settings tab.

Badges

To make our repository more professional and fancy, it is nice to add some “badges”. Readme.md file contains some. One is provided by the build-and-test workflow, and others (like current NuGet version or number of downloads) are provided by super-popular https://shields.io/ site:

What’s next?

It is not a full MVP still. There is a field of many improvements to make it a true template for potential library authors, including:

• the next big thing to add is producing GitHub releases every time a new version is being created. I wanted to depend on version tags being already pushed by the publish-nuget workflow. Unfortunately I have an issue with that.
• GitHub Actions for creating prerelease versions
• some simple documentation auto-generation example, like the list of currently supported abbreviations
• more automated tests, like code coverage or even benchmarks
• the core “logic” improvement, like auto-generating title case versions, more abbreviations, more languages etc.
• …? Any other good, not-to-complex automation ideas

So, in the end, please feel invited to look around and help me building it with your contributions. Any contributions to the “logic” itself is also welcomed!