In this post I covered how to debug a failing build. This is more of the same, really; a sort of hodgepodge of bits that have cropped up while discovering issues with various projects.
If you’re interested, the library that caused all this was this one.
.Net Version
Let’s start with the version number that you’re building for. When you create the initial build you get a targetted .net version; and by default, it’s very specific (and the latest version):
dotnet-version: 3.1.101
There’s two things that are worth noting here. The first is that if you intend to release this library on NuGet or somewhere else that it can be consumed, then the lower the target version, the better. A .Net Core app can consume a library of the same version or lower. This sounds obvious, but it’s not without cost: some of the GitHub actions depend on later versions. For example, Publish Nuget uses the switch ---skip-duplicate, which is a .Net 3.1 thing. If you try to use this targeting a previous version of .Net, you’ll get the following error:
error: Unrecognized option '--skip-duplicate'
The second thing of note is the specific version; it’s not as well documented as it should be, but you can simply use something like this:
dotnet-version: '3.1.x'
And you’re build will work with any version of 3.1.
Cross Platform, Verbosity and Tracing
As with the post mentioned above, I had an issue with a specific library, whereby two of the tests were failing. The first test in question called a line of code that compared two strings:
if (String.Compare(string1, string2, StringComparison.OrdinalIgnoreCase) == 0)
It turns out that this doesn’t work cross platform, and was failing because it was running on Ubuntu.
The second issue was slightly more nuanced, and relates to the dates (1/3 was being read as 3/1); this isn’t specifically a Linux / Windows issue, but it is something that’s different between testing on your local environment, and on the build server. This might not be as much of an issue if you’re in the U.S. (or any country that formats its dates with the month first).
Although I initially suspected the cause, I began by changing the log level on the build:
run: dotnet test --no-restore --verbosity normal
To:
run: dotnet test --no-restore --verbosity detailed
Unfortunately, this didn’t really give me anything; and I’m sad to say that I next resorted to inserting lines line this into the code to try and determine what was going on:
Console.WriteLine("pcm-test-1");
I’m not saying this is the best method of debugging (especially in a situation like this), but it’s where we all go to when nothing else works.
A Better Way - Debugging on Linux Locally
In this post I covered how you can install Ubuntu and run it from your Windows Terminal, and in this post, I covered how you can install .Net on that instance. This means that we can run the tests directly from Linux and see what’s going on locally.
Simply cd to the directory that you’ve pulled the code down to, and run ```
dotnet test
. You may need to run it as elevated privilege, but it should run, and fail with the same error that you're getting from GitHub:
# Summary
I've used GitHub Actions a few times now, and this issue of the code running on a different platform is by far the most challenging thing about using them. Given that this is running on a Windows machine, being able to run (and debug) on a Linux platform is a huge step forward.