Project used for this example can be found in GitHub.
In GitHub actions you can use .NET based tools, both in Windows and in Linux machines, to accomplish various tasks. I’m a great fan of GitVersion tool, used to determine a semantic versioning based on a Git repository that uses git-flow structure. Another nice aspect is that GitHub action machines based on Linux comes with PowerShell core preinstalled, so I can use actions that comes from PowerShell gallery without any problems … errr.. almost.
.NET tooling can be used in GitHub actions without any problems.
I simply run GitVersion using some helper modules I’ve published on PowerShell Gallery, just install them and Invoke GitVersion tool. Setting $DebugPreference to continue allows me to view a verbose log of the execution.
When I first run my Powershell step I got errors, and looking at the output immediately tells me the problem.
When you have some stuff that works in Windows (.NET or Powershell core) but it does not works in Linux, 95% of the time you use wrong casing for files, it works for Windows that is not case sensitive, but does not work in Linux. This time it is not an exception, I’ve specified file name with wrong casing in PowerShell definition manifest, but once fixed my module I got another error.
It turns out that probably the version of GitVersion I’m using does not work inside an Ubuntu machine, but this is not a problem, because the best approach is using multiple jobs in GitHub Action, each one running on preferred environment, doing a specific job, and setting output variable to be consumed on dependant jobs. Once I moved the task on a Windows based machine, everything runs just fine.
Versioning of code (with GitVersion or other tools) is always a good strategy to keep track of code quality.
The main reason behind calculating a version is being able to track the evolution of code quality with some marker that can have business or technical meaning. Instead of telling that the actual version is commit ec52a9c68d0cdb40de98cf28f8bb0890e84de4b0, it is much more useful to tell user that the version is 0.2.0-beta-000x.
If you analyze your code with SonarCloud, it is also a good habit to send a version with the analysis, this will help you to identify how the code quality in Sonar change between versions. In your linux task that runs SonarCloud I can use the variable exported by previous job.
Every SonarCloud property value that is dynamic (value can be known only inside the action) can be directly passed from GitHub Action Task with the args syntax. All static parameters find a better place in sonar-project.properties file. The syntax used in the above example references an output variable of another job as I described in another post;
Figure 2: Versioning is now active in SonarCloud
As you can see, I’m now able to look at versioning in SonarCloud dashboard.