This is no objection to using nuke builds, but I'd recommend to move this to post-v4.1 time, simply to ensure that you (as new maintainers) experienced the full bandwidth of existing build solutions in the project before creating a new one.

This advice is independent from the quality level of the current solution - if it's great or horrible, you first have to dive into its greatness and horribleness to know what exactly you're replacing here. I'm sure you have the general idea already, but familiarity can help beyond that.

Feel free to disregard this advice if you're confident in this, but I would be somewhat unhappy in case this causes issues or hiccups that wouldn't have existed otherwise 😄 Please just make sure this isn't a running system vs. "shiny new stuff" thing.

(Other than that, I think it's great to rethink existing workflows to be a better fit for you and future contributors.)

Either way though, I think this one is something both of you (cc @SirePi ) should review and agree on before considering.

It was my intention to merge this after v4. But I had some leftover time and decided to make a start with it so we have something more concrete to talk about. Thats also why its a draft PR.

Open-source projects get special service when using nuke.

Haha my draft PR is already drawing attention.

@matkoch Our first priority currently is getting duality v4.0.0 out there but after that I will continue to look into getting the build tooling more up to date. Iam wondering though what kind of special service are you referring to?

Updated this PR as dotnet tooling now works properly with the solution.

Also added a build docs target so I think we now have feature parity with the old nightlybuilder or atleast close to it if I missed something @ilexp.

commandline summary output:

In the nightlybuilder I still see some code that copies files but iam not sure if its even being used atm:

					if (includeDocs)
					{
						File.Copy(
							Path.Combine(config.DocBuildResultDir, config.DocBuildResultFile), 
							Path.Combine(config.BuildResultDir, config.DocBuildResultFile),
							true);
						Console.WriteLine("Documentation copied to build directory");
					}

and

			// Copy ZIP Package
			if (!string.IsNullOrWhiteSpace(config.CopyPackageTo))
			{
				Console.WriteLine("=============================== Copy ZIP Package ==============================");
				{
					Console.WriteLine("Copying package to '{0}'", config.CopyPackageTo);
					if (!Directory.Exists(config.CopyPackageTo))
						Directory.CreateDirectory(config.CopyPackageTo);
					File.Copy(packagePath, Path.Combine(config.CopyPackageTo, config.PackageName), true);
				}
				Console.WriteLine("===============================================================================");
				Console.WriteLine();
				Console.WriteLine();
			}

As I see all the nuget packages getting generated I didnt put these in the nuke build. Are these lines of code even being used atm?

In the nightlybuilder I still see some code that copies files but iam not sure if its even being used atm:

No, the entire BuildResultDir and PackageCopyDir are unused - actually, they could be removed from NightlyBuilder as well for v4.0. Both of them serve the old "package the binary download .zip" use case, which no longer exists with the new template.

Also added a build docs target so I think we now have feature parity with the old nightlybuilder or atleast close to it if I missed something @ilexp.

Judging from the build step definitions from the diff, I'd say yes, it should have feature parity.

In the nightlybuilder I still see some code that copies files but iam not sure if its even being used atm:

No, the entire BuildResultDir and PackageCopyDir are unused - actually, they could be removed from NightlyBuilder as well for v4.0. Both of them serve the old "package the binary download .zip" use case, which no longer exists with the new template.

Ok I will clean that up in a separate PR #851

Also added a build docs target so I think we now have feature parity with the old nightlybuilder or atleast close to it if I missed something @ilexp.

Judging from the build step definitions from the diff, I'd say yes, it should have feature parity.

Ok thats nice :)