nuke-build / nuke Goto Github PK

Nuke worked great for my project, but I encountered a few issues.

Expected Behavior

Builds work with a Directory.Build.props file in a parent directory containing:

<Project>
  <PropertyGroup>
    <AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
    <BaseIntermediateOutputPath>..\..\..\artifacts\nuke\obj\</BaseIntermediateOutputPath>
    <OutputPath>..\..\..\artifacts\nuke\bin\$(Configuration)\</OutputPath>
  </PropertyGroup>
</Project>

Current Behavior

Assertion failed: buildProjectDirectory != null
   at Nuke.Common.ControlFlow.Fail(String text)
   at Nuke.Common.ControlFlow.NotNull[T](T obj, String text)
   at Nuke.Common.EnvironmentInfo.get_BuildProjectDirectory()
   at Nuke.Common.NukeBuild.get_RootDirectory()
   at Nuke.Common.NukeBuild.get_SolutionFile()
   at Nuke.Common.ProjectModel.SolutionAttribute.GetStaticValue()
   at Nuke.Common.Execution.InjectionService.InjectValues(NukeBuild build)
   at Nuke.Common.Execution.BuildExecutor.Execute[T](Expression`1 defaultTargetExpression)

Steps to Reproduce

1. Create project or clone CreateAndFake.
2. Add/modify a Directory.Build.props file similar to the example.
3. Run any build.

Additional Information

It seems to not be registering the setting.

In command line shell works perfectly

Steps to reproduce in powershell console:

iwr https://nuke.build/powershell -OutFile setup.ps1
./setup.ps1

after setup build scripts doesn't exists

Fixed by

#line 130
#WriteFile "build.ps1" ...
WriteFile "$RootDirectory/build.ps1" # ...

#line 137
#WriteFile "build.sh" ...
WriteFile "$RootDirectory/build.sh" # ...

#line 144
#(New-Object System.Net.WebClient).DownloadFile("$BootstrappingUrl/../build.cmd", "build.cmd")
(New-Object System.Net.WebClient).DownloadFile("$BootstrappingUrl/../build.cmd", "$RootDirectory/build.cmd")

$PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.14409.1012
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.14409.1012
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Hi,

I'm following your Getting started documentation and the first thing I did was installing the nuke global tool.

When invoking nuke or nuke :setup I get the following error:

Assertion failed: obj != null

Nothing else is done/shown.

I was then trying to invoke it with --help to see if I can make the output a bit more verbose, but this results in the same error.

Since the global tool didn't work for me, I tried using the PowerShell setup, but the bootstrapping file from the docs isn't available any longer.

Is there anything I can do to get a better understanding on whats going wrong?

I'm trying to add a build script for a solution containing net4.5.2 projects (having the new csproj format)

Not sever, exit code is non-zero.

Hi,

Firstly, great tool!

I get this error when I run a msbuild target on my local dev machine:

> "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\amd64\msbuild.exe" C:\Repos\build\ManagementSystem.sln /maxcpucount:4 /nodeReuse:System.Object /p:Configuration=Debug /target:ManagementSystem_Api;ManagementSystem_Api_IntegrationTests;ManagementSystem_Api_UnitTests;ManagementSystem_Application;ManagementSystem_Data;ManagementSystem_Database;ManagementSystem_Domain;ManagementSystem_Domain_Models;ManagementSystem_Integration;ManagementSystem_Processes;ManagementSystem_Test_Common;ManagementSystem_Test_Db;StateMachines
Microsoft (R) Build Engine version 15.5.180.51428 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

MSBUILD : error MSB1042: Node reuse value is not valid. String was not recognized as a valid Boolean..
Switch: System.Object

The example error, above, is from my compile target:

Target Compile => def => def
        .DependsOn(Restore)
        .Executes(() => MSBuild(_ => DefaultMSBuildCompile));

I think the issue is down to the thing that generates the command. NodeReuse is a nullable boolean that is null by default, but is set to true if I use the default msbuild settings, via NukeBuild.Instance.IsLocalBuild. If I explicitly set it false:

Target Compile => def => def
        .DependsOn(Restore)
        .Executes(() => MSBuild(_ => DefaultMSBuildCompile.SetNodeReuse(false)));

The error goes away. The output is:

> "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\amd64\msbuild.exe" C:\Repos\build\ManagementSystem.sln /maxcpucount:4 /p:Configuration=Debug /target:ManagementSystem_Api;ManagementSystem_Api_IntegrationTests;ManagementSystem_Api_UnitTests;ManagementSystem_Application;ManagementSystem_Data;ManagementSystem_Database;ManagementSystem_Domain;ManagementSystem_Domain_Models;ManagementSystem_Integration;ManagementSystem_Processes;ManagementSystem_Test_Common;ManagementSystem_Test_Db;StateMachines
Microsoft (R) Build Engine version 15.5.180.51428 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

I think Arguments.cs should change from:

        public Arguments Add(string argument, bool? condition = true)
        {
            return Add(argument, condition.HasValue && condition.Value ? new object() : null);
        }

to:

        public Arguments Add(string argument, bool? condition = true)
        {
            return Add(argument, condition.HasValue && condition.Value ? bool.TrueString : null);
        }

However, I still don't think its right.

nodeReuse is on by default, but my potential fix doesn't allow me to turn it off (see the last output - /nodeReuse:false is missing). I think it should actually be:

        public Arguments Add(string argument, bool? condition = true)
        {
            return Add(argument, condition.HasValue ? (condition.Value ? bool.TrueString : bool.FalseString) : null);
        }

That could, potentially, be a change to functionality.

What do you think - is that a change we could make? I could raise a pull request if you like?

Cheers,
Andy

For deploying websites to Azure and IIS, I'm using usually Microsoft WebDeploy. There's no *.exe available via NuGet, but a dll package: Microsoft.Web.Deployment

Now I've drafted a small Task so I can use it with Nuke, the code is available as Gist:
https://gist.github.com/GeorgDangl/5521ef94bc6cae85793f8842f64fa3c5
(Consider this an early WIP)

I'd like to ask for some guidance how such a plugin should be published, especially these questions would be interesting:

• Should WebDeploySettings inherit from ToolSettings? When calling functions via a dll, there's no need for a ToolPath property. I've marked it obsolete in the draft, which gives me compiler warnings, otherwise, I've got a unused property. Should I just inherit from ISettingsEntity or just use a its own class?
• The required NuGet package is only available for the full .Net framework, so the build is Windows only. No problem for my use cases, but would this be OK?
• Are there any naming conventions for external plugins that are planned to be released on NuGet? For example, can I release it as Nuke.Tools.WebDeploy?

The first time I ran .\build.ps1 I get this error:

C:\Program Files\dotnet\sdk\2.1.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(198,5): error : Assets file 'build\obj\project.assets.json' not found. Run a NuGet package restore to generate this file. [build\.build.csproj]

If I open the solution and build manually, looks like project.assets.json file gets created correctly and subsequent calls to .\build.ps1 works as intended.

Actual:
OctopusCreateReleaseSettings.WaitForDepployment

Expected:
OctopusCreateReleaseSettings.WaitForDeployment

See also:
https://www.nuke.build/api/Nuke.Common/Nuke.Common.Tools.Octopus.OctopusCreateReleaseSettings.html#Nuke_Common_Tools_Octopus_OctopusCreateReleaseSettings_WaitForDepployment

Current documentation lacks very important part: examples of usage of the classes/settings. I know you have getting started, but it is not sufficient. I think main "build" tools, like using MSBuild, NUnit / MSTest, Code Coverage (Open Cover) should be documented with nice and working examples.

Currently, the bootstrapping scripts always downloads the nuget/dotnet CLT. Although this is more reliable and ensures determinism, it is not always recommendable.

In both setup scripts, there should be added an option to chose between:

1. Always download nuget/dotnet CLT
2. Use local nuget/dotnet installation

This should influence the value of NuGetFile/DotNetFile. Also the file existence check must be adapted.

Instead of copying the two-liner setup code, it would be more convenient to have a global tool, alias or script, that executes exactly that for us.

We could include git-flow commands into the global tool:

nuke :release

Requires GitVersion.yml and clean working copy.

If current branch is not release/xxx, then create release/[GitVersion.MajorMinorPatch] from develop. If current branch is release branch, then merge into develop and master, create a tag, and delete release branch.

nuke :feature [name]

Requires clean working copy.

If current branch is not feature/xxx, then either require a name or provide a list of locally available feature branches. If current branch is feature branch, then merge into develop and delete feature branch.

nuke :hotfix [name]

Similar to nuke :feature.

Use Levenshtein distance?

When specifying arguments for DotNetRun with spaces in, the arguments are enclosed in quotes which cause the arguments to not be passed to the program to be run (see here). Using the = sign works to avoid this, but is only available if you have one argument.

Using SetApplicationArguments($"--ExampleArgument=asd"):
"C:\Program Files\dotnet\dotnet.exe" run --configuration Debug --project ExampleProject -- --ExampleArgument=asd

Using SetApplicationArguments($"--ExampleArgument asd"):
"C:\Program Files\dotnet\dotnet.exe" run --configuration Debug --project ExampleProject -- "--ExampleArgument asd"

When running the setup.ps1 script it will ask target platform, but when answering the question, the script instantly crashes. Using Start-Transcript i found that the error is:

"The response content cannot be parsed because the Internet Explorer engine is not available."

I hadn't started regular, non-edge internet explorer yet. But after i started it and chose the "use recommended settings", the script ran without problems

The powershell setup script generates relative paths that will go beyond root directory, so that if a repository is cloned with a different name than the original, the boostrapping script will fail.

Currently the executing and dependsOn targets are not following any order (#90).

Example:

Target Clean => 
   .Executes(() => {});

Target Compile =>
  .DependsOn(Clean)
  .Executes(() => {});

Target Coverage => 
 .Executes(() => {});

When executing nuke Compile+Coverage, it's possible that Coverage is executed before Clean and therefore the coverage results will be deleted. To solve that problem without the usage of DependsOn (hard dependency) we should introduce "soft dependencies" for targets. This basically means that the target must run before another target but doesn’t requires the other target to run.
This could be achieved by adding the functions

• ITargetDefiniton Before(params Target[] targets);
• ITargetDefinition After(params Target[] targets);

to the ITargetDefiniton interface.

With this we could change the above example to this:

Target Clean => 
   .Executes(() => {});

Target Compile =>
  .DependsOn(Clean)
  .Executes(() => {});

Target Coverage => 
 .After(Clean)
 .Executes(() => {});

Instead of defining .After(Clean) in the Coverage target it would be also possible to define .Before(Coverage) in the Clean target.

The table below shows the executed commands and the resulting execution order.

Currently, conditions provided via OnlyWhen are checked exactly prior to execution of a target. Another use-case is to check those during dependency resolution, so that we allow to skip targets, which are dependencies for a skipped target.

Proposal:

ITargetDefinition OnlyWhen(Func<bool> predicate, CheckBefore checkMode);

enum CheckBefore
{
  ThisTarget,
  AllTargets
}

To be defined. What to do with the existing OnlyWhen method? Deprecate? Default to CheckBefore.ThisTarget ?

For example: Finished build on 11/09/2017 12:03:26.
My current culture is RU_ru so the output should be
Finished build on 09.11.2017 12:03:26.

They have pretty thorough documentation at:
https://docs.unity3d.com/Manual/CommandLineArguments.html

I'm trying to set up a Nuke build for the very first time, and I'm following along with the Getting Started page on the website. More specifically, I'm trying to build a target to execute all unit tests.

Target UnitTest => _ => _
   .DependsOn(Compile)
   .Executes(() =>
   {
      var assemblies = GlobFiles(SolutionDirectory, $"*/bin/{Configuration}/net*/*.Tests.dll").NotEmpty();
      var xunitSettings = new Xunit2Settings()
                .AddTargetAssemblies(assemblies)
                .AddResultReport(Xunit2ResultFormat.Xml, OutputDirectory / "tests.xml");

      XunitTasks.Xunit2(s => xunitSettings);
   });

But this always throws a System.InvalidOperationException.

_  _ _  _ _ ___ ___ ____ ____ ___
|  | |\ | |  |   |  |___ [__   |
|__| | \| |  |   |  |___ ___]  |

Sequence contains more than one element
   at System.Linq.Enumerable.SingleOrDefault[TSource](IEnumerable`1 source)
   at Build.<get_UnitTest>b__8_1() in /Users/romatthe/Source/reniver-i4-opcua/build/Build.cs:line 60
   at System.Collections.Generic.List`1.ForEach(Action`1 action)
   at Nuke.Common.Execution.BuildExecutor.Execute(IEnumerable`1 executionList)
   at Nuke.Common.Execution.BuildExecutor.Execute[T](Expression`1 defaultTargetExpression)

Looking a bit deeper, it seems like this thrown from inside the ToolPathResolver.GetPackageExecutable method, more specifically on this exact line.

Now, in my case, Directory.GetFiles is looking inside /Users/romatthe/.nuget/packages/xunit.runner.console/2.4.0 for xunit.console.exe. Obviously this doesn't yield a single return value, as I have multiple versions of this package in the tools directory.

/Users/romatthe/.nuget/packages/xunit.runner.console/2.4.0
├── build
│   └── xunit.runner.console.props
├── tools
│   ├── net452
│   ├── net46
│   ├── net461
│   ├── net462
│   ├── net47
│   ├── net471
│   ├── net472
│   ├── netcoreapp1.0
│   └── netcoreapp2.0
├── xunit.runner.console.2.4.0.nupkg
├── xunit.runner.console.2.4.0.nupkg.sha512
└── xunit.runner.console.nuspec

Whats the proper way to work around this? Setting the toolpath manually seems like a rather tricky thing to do, especially because this build should be working on both Windows, OSX and Linux.

As you've probably noticed, I'm currently working on OSX.
Nuke version is 0.5.3

When executing a build locally (HostType == Console), we could initialize parameters like ApiKey or Password via console input. It is important to mask out passwords.

Interactive input is only possible for properties/fields without property/field initialization.

Repro:

1. Creates simple Console application targeting 4.5 framework
2. When generating chose "L" (legacy format) when generating build.csproj
3. run .\build.cmd
   and you'll get a bunch of:
   Build.cs(3,7): error CS0246: The type or namespace name 'Nuke' could not be found (are you missing a using directive or an assembly reference?) [D:\temp\NukeTest\build.build.csproj]

I guess project generator messed up something with references.
SDK based format works nice.

Not a sever bug, but more cosmetic.

I've created build project with folowing settings: Target Framework as .Net Framework, Project format is Legacy format and other settings by default.
If uncomment [GitVersion] readonly GitVersion GitVersion; at Buils.cs and then run powershell -ExecutionPolicy ByPass -File ./build.ps1 -help you will get Assertaion failed error.

Stack trace:
Assertion failed: !IncludesDependencies(Z:\Code\AIMP\aimp_DiskCover\build\packages.config) || includeDependencies
at Nuke.Core.ControlFlow.Assert(Boolean condition, String text)
at Nuke.Common.Tools.NuGetPackageResolver.d__2.MoveNext()
at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable'1 source, Func'2 predicate)
at Nuke.Common.Tools.NuGetPackageResolver.GetLocalInstalledPackage(String packageId, String packagesConfigFile)
at Nuke.Common.Tools.ToolPathResolver.GetPackageExecutable(String packageId, String packageExecutable)
at Nuke.Common.Tools.GitVersion.GitVersionSettings.get_ToolPath()
at Nuke.Core.Tooling.ProcessManager.StartProcess(ToolSettings toolSettings, ProcessSettings processSettings)
at Nuke.Common.Tools.GitVersion.GitVersionTasks.GitVersion(Configure'1 configurator, ProcessSettings processSettings)
at Nuke.Common.Tools.GitVersion.GitVersionAttribute.GetStaticValue()
at Nuke.Core.Injection.StaticInjectionAttributeBase.GetValue(String memberName, Type memberType)
at Nuke.Core.Execution.InjectionService.InjectValues(NukeBuild build)
at Nuke.Core.Execution.BuildExecutor.Setup[T](Expression'1 defaultTargetExpression)
at Nuke.Core.Execution.BuildExecutor.Execute[T](Expression'1 defaultTargetExpression)
The following call failed with exit code 199475893. ' & $BuildExeFile $BuildArguments '
At Z:\Code\AIMP\aimp_DiskCover\build.ps1:32 char:32

The links to the addin repositories in the disclaimer, for example for Azure resolves to:
http://www.nuke.build/api/Nuke.Azure/Nuke.Azure instead of
https://github.com/nuke-build/azure.

I'm playing with nuke right now and would be awesome to use tools that run on dotnet core ootb.

Coverlet looks promising...
https://github.com/tonerdo/coverlet

Another possible way is to enable custom parameters on DotNetTest wrapper.
What you guys think about this integration?

It should be easier to recognize information from process invocations:

/usr/bin/dotnet build /some/path/my.sln --configuration Debug
--------|------|-----|-----------------|---------------|-----
 path     name   cmd        value           switch      value

Nuke worked great for my project, but I encountered a few issues.

Expected Behavior

Specifying Test+Coverage or DependsOn(Test, Coverage) should execute Test build first, then Coverage build.

Current Behavior

Coverage runs first, then Test. It appears to be following alphabetical order.

Steps to Reproduce

1. Create project or clone CreateAndFake.
2. Run a combo build contrary to alphabetical order, such as './build/build Tests+Coverage' for CreateAndFake.

Additional Information

This greatly reduces my ability to tie together builds. Like on AppVeyor, I'd like to create a target that depends on Test and Coverage, but it's runs them out of order. And because Test depends upon Clean, where Coverage doesn't, Test deletes my coverage results.

Instead, my server script first calls build Test, then calls build Coverage, since build Test+Coverage has this issue as well.

According to the VisualStudio roadmap, CodeLens API will be made public in Q3.

Also have a look at an existing extension.

minimal build file link on getting started page leads to 404
https://raw.githubusercontent.com/nuke-build/nuke/master/bootstrapping/Build.cs

Reference version should also be replaced to match selected major.minor version. Requires changes in setup scripts.

https://github.com/nuke-build/nuke/blob/master/bootstrapping/.build.legacy.csproj#L85-L90

We wish for something like StartsWith.

After running the powershell script nuget fails restore the packages for .build.csproj. I have setup nuke for .Net FW and legacy project structure.

Checking for updates from https://www.nuget.org/api/v2/.
Currently running NuGet.exe 4.3.0.
NuGet.exe is up to date.
MSBuild auto-detection: using msbuild version '15.3.409.57025' from 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\bin'.
Cannot determine the packages folder to restore NuGet packages. Please specify either -PackagesDirectory or -SolutionDirectory.
The following call failed with exit code 1. ' & $NuGetFile restore $BuildProjectFile '
At <redacted>\build.ps1:31 char:32
+ ... de -ne 0) { throw "The following call failed with exit code $LastExit ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (The following c...ldProjectFile ':String) [], RuntimeException
    + FullyQualifiedErrorId : The following call failed with exit code 1. ' & $NuGetFile restore $BuildProjectFile '

Am I missing something?

Some console hosts and build servers support ANSI color output. One thing to consider is when to enable them. On Windows systems, ANSI colors usually don't work, whereas UNIX terminals support them.

The help text for parameters should provide additional standardized information. For instance:

• Possible values if type is an enum
• Default values
• Separator character

When a build chain failed, sometimes it's enough to only retry/continue from the last failed target. Adding -retry (preferably because it's shorter) or -continue to the invocation could be helpful.

We should check that the last invocation is the same (except, from adding the new parameter). Probably use some kind of hash that is saved in temp directory.

Nuke worked great for my project, but I encountered a few issues.

Expected Behavior

Builds work with a Nuget.config file in the root directory containing:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="globalPackagesFolder" value=".\artifacts\packages" />
  </config>
</configuration>

Current Behavior

Assertion failed: Could not find package 'OpenCover' via 'C:\projects\createandfake\build\nuke\.Build\.Build.csproj'.
   at Nuke.Common.ControlFlow.Fail(String text)
   at Nuke.Common.ControlFlow.NotNull[T](T obj, String text)
   at Nuke.Common.Tooling.ToolPathResolver.GetPackageExecutable(String packageId, String packageExecutable)
   at Nuke.Common.Tooling.ProcessManager.StartProcess(ToolSettings toolSettings, ProcessSettings processSettings)
   at Nuke.Common.Tools.OpenCover.OpenCoverTasks.OpenCover(Configure`1 configurator, ProcessSettings processSettings)
   at Build.<get_Coverage>b__19_2() in C:\projects\createandfake\build\nuke\.Build\Build.cs:line 100
   at System.Collections.Generic.List`1.ForEach(Action`1 action)
   at Nuke.Common.Execution.BuildExecutor.Execute(IEnumerable`1 executionList)
   at Nuke.Common.Execution.BuildExecutor.Execute[T](Expression`1 defaultTargetExpression)

Steps to Reproduce

1. Create project or clone CreateAndFake.
2. Ensure your normal global package folder does not contain the package.
3. Run a build using a NuGet tool, such as './build/build Coverage' for CreateAndFake.

Additional Information

It seems the build doesn't respect the Nuget.config, and just looks in the global folder. Either the Nuget.config file needs to be considered, or an option to specify a package directory is needed.

I followed the bootstrap procedure from the site.

powershell -Command iwr https://nuke.build/powershell -OutFile setup.ps1
powershell -ExecutionPolicy ByPass -File ./setup.ps1

But this is all I got - console output:
0.1.277

Looked into setup.ps1 to found:

[CmdletBinding()]
Param()

$LatestVersion = $(Invoke-WebRequest https://api-v2v3search-0.nuget.org/query?q=packageid:Nuke.Common | ConvertFrom-Json
).data.version
Write-Host $LatestVersion

exit

A couple of extension hooks for reporting could be useful, for instance:

• Before and after injection
• Before and after target execution
• On target failure
• Before summary output

An invocation of nuke that automatically opens the browser and shows the issue submission prefilled (https://github.com/isaacs/github/issues/new?title=foo&body=bar). We could prefill information about versions and maybe even logs. Of course, we should prompt for confirmation. We could even tell additional information about how to debug.

Command could look like nuke * or nuke @ or nuke # - requires moving cursor when parameters are supplied - or a dedicated parameter -report (reserved).

Console experience can be improved by adding some kind of progress/status bar to the end of the console output that gets rewritten with every new output. This could include:

• Amount of finished targets / percentage
• Currently running targets
• Currently running operation
• Time since last output (hang detection)

One example. Build is not finished yet, mind the last three lines:

____ ____ _  _ ___  _ _    ____
|    |  | |\/| |__] | |    |___
|___ |__| |  | |    | |___ |___

> /usr/local/share/dotnet/dotnet build /Users/matt/code/nuke/nuke-common.sln
Microsoft (R) Build Engine version 15.7.179.6572 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Nuke.MSBuildLocator -> /Users/matt/code/nuke/source/Nuke.MSBuildLocator/bin/Debug/Nuke.MSBuildLocator.exe
  Nuke.Common -> /Users/matt/code/nuke/source/Nuke.Common/bin/Debug/netstandard2.0/Nuke.Common.dll
  Nuke.Common -> /Users/matt/code/nuke/source/Nuke.Common/bin/Debug/net461/Nuke.Common.dll
  Nuke.CodeGeneration -> /Users/matt/code/nuke/source/Nuke.CodeGeneration/bin/Debug/netstandard2.0/Nuke.CodeGeneration.dll
  Nuke.GlobalTool -> /Users/matt/code/nuke/source/Nuke.GlobalTool/bin/Debug/netcoreapp2.1/Nuke.GlobalTool.dll
  Nuke.CodeGeneration -> /Users/matt/code/nuke/source/Nuke.CodeGeneration/bin/Debug/net461/Nuke.CodeGeneration.dll
  Nuke.Common.Tests -> /Users/matt/code/nuke/source/Nuke.Common.Tests/bin/Debug/net461/Nuke.Common.Tests.dll

# Compile [/user/local/share/dotnet/dotnet build /Users/matt/...]
# ParallelTarget [Cleaning /Users/matt/code/nuke/output]
# [@@@@____] 50% 

Metadata should be contained here as well.

ReSharper and Rider plugins should be documented in Getting Started section.

Probably also add something on main page.

I got this exception. I think there is a bug in this script.

$ ./build.sh
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
Microsoft (R) .NET Core SDK version 2.0.2
_  _ _  _ _  _ ____ 
|\ | |  | |_/  |___ 
| \| |__| | \_ |___ 
Version: 0.5.3 [CommitSha: 0aff3c55]
Host: Travis
Assertion failed: Could not find 'mono' via '/usr/bin/which'.
   at Nuke.Common.ControlFlow.Fail(String text)
   at Nuke.Common.ControlFlow.NotNull[T](T obj, String text)
   at Nuke.Common.Tooling.ToolPathResolver.GetPathExecutable(String pathExecutable)
   at Nuke.Common.Tooling.ProcessManager.StartProcess(ToolSettings toolSettings, ProcessSettings processSettings)
   at Nuke.Common.Tools.GitVersion.GitVersionTasks.GitVersion(Configure`1 configurator, ProcessSettings processSettings)
   at Nuke.Common.Tools.GitVersion.GitVersionAttribute.GetStaticValue()
   at Nuke.Common.Execution.InjectionService.InjectValues(NukeBuild build)
   at Nuke.Common.Execution.BuildExecutor.Execute[T](Expression`1 defaultTargetExpression)
The command "./build.sh" exited with 7.

Full build log - https://travis-ci.org/RouR/ToDo-ToBuy/builds/409529136
Config file for Travis - https://github.com/RouR/ToDo-ToBuy/blob/413beb4b4f9e25f509d13fce0d74382c449fb0b9/.travis.yml#L35

build.ps1 started to fail with an error starting with version 0.6 while it worked with the previous version.
It looks like it can't find the vswhere file or path. Then I assume an empty string as the path is passed and causes the error.

error:

2018-08-08T08:20:55.9558440Z ##[error]Unbehandelte Ausnahme: System.InvalidOperationException: Der Prozess kann nicht gestartet werden, da ein Dateiname nicht angegeben wurde.
bei System.Diagnostics.Process.Start()
bei Nuke.MSBuildLocator.Program.MSBuildLocator.GetProcessOutput(String arguments)
bei Nuke.MSBuildLocator.Program.MSBuildLocator.GetVSWhereInstallation(String products, IReadOnlyCollection1 requires, Boolean legacy) bei Nuke.MSBuildLocator.Program.MSBuildLocator.TryGetMSBuildPath(String products, IReadOnlyCollection1 requires, Boolean legacy)
bei Nuke.MSBuildLocator.Program.MSBuildLocator.Resolve()
bei Nuke.MSBuildLocator.Program.Main(String[] args)
\build.ps1 :
Der Ausdruck nach "&" in einem Pipelineelement hat ein ungültiges Objekt erzeugt. Der Ausdruck muss einen
Befehlsnamen, Skriptblock oder ein CommandInfo-Objekt ergeben.
In Zeile:1 Zeichen:1

The exception message could be translated to: The process can't be started, because no file name was specified.

Here's the full output:
NukeBuildPs1Error.txt

I've forced Nuke.MSBuildLocator in the build.ps1 to version 0.5 to fix it.

If there is a folder without access permissions in the solution directory or one of its child directories the execution fails with the message:

> nuke
Access to the path 'F:\System Volume Information' is denied.

Effectively unusable, since GitVersionAttribute will access all build instances, and we use EnsureVariable everywhere. My current guess is to only use Variable. Would require tests to also check the CanBeNull attribute, and if it's not there, we add an additional not-null assertion.