Skip to main content

Versioning Artifacts

Whenever a build produces artifacts, those should be identifiable with a unique version number. This avoids making wrong expectations about available features or fixed bugs, and allows for clear discussions between developers, QA team, and product users. The most common version approaches are are semantic versioning and calendar versioning.

Repository-based Versioning​

NUKE supports 4 different tools that help generating version numbers from your repository and its commits. Each of these tools comes with its own attribute that populates the field with the information calculated:

note

Please refer to the GitVersion documentation for any questions.

Tool Installation
nuke :add-package GitVersion.Tool
Build.cs
[GitVersion]
readonly GitVersion GitVersion;

Target Print => _ => _
.Executes(() =>
{
Log.Information("GitVersion = {Value}", GitVersion.MajorMinorPatch);
});
info

Note that when the versioning tool fails to calculate version numbers, a warning will be logged and the attributed field remains uninitialized. In that case, you can try executing the issued command manually or nuke --verbosity verbose to reveal more detailed information. In most cases, the repository is either not initialized, has no commits, or is missing the tool-specific configuration file.

Dependency-based Versioning​

When your versioning is affected by external dependencies, NUKE provides another mechanism to load the latest version of those prior to build execution. Each attribute provides various properties to control which versions should be considered and how it should be transformed:

Build.cs
[LatestNuGetVersion(
packageId: "JetBrains.ReSharper.SDK",
IncludePrerelease = true)]
readonly NuGetVersion ReSharperVersion;

Target Print => _ => _
.Executes(() =>
{
Log.Information("ReSharperVersion = {Value}", ReSharperVersion);
});

You can learn more about different versioning aspects from the following resources: