NUKE provides us with a DSL to configure the build steps using C# code, so we can certainly recognize many of the terms used here from the. Some of the values defined there will be familiar, as we chose them in the initial setup.įinally, we have the build steps themselves, Clean, Restore and Compile. Then, we have the Main method, the build’s entry point, which invokes Execute with the default step Compile, defined later on.īefore the various steps, we have some fields and properties we can use later. The class inherits from NukeBuild, which will provide it with some helper properties and methods. TestsDirectory.GlobDirectories( "**/bin", "**/obj").ForEach(DeleteDirectory) ĮnsureCleanDirectory(ArtifactsDirectory) SourceDirectory.GlobDirectories( "**/bin", "**/obj").ForEach(DeleteDirectory) readonly GitRepository GitRepository ĪbsolutePath SourceDirectory => RootDirectory / "src" ĪbsolutePath TestsDirectory => RootDirectory / "tests" ĪbsolutePath ArtifactsDirectory => RootDirectory / "artifacts" readonly Configuration Configuration = IsLocalBuild ? Configuration.Debug : Configuration.Release / Support plugins are available for: /// - JetBrains ReSharper /// - JetBrains Rider /// - Microsoft VisualStudio /// - Microsoft VSCode public static int Main () => Execute(x => x.Compile) In the Build.cs file we have an already fully functional build definition, as demonstrated by the previous execution. Customizing the build # What we get out of the box # \build.ps1 (because I’m on Windows using PowerShell right now). We’ll see the generated build definition in a minute, but we can run it immediately and see the result, by executing. I’m not going to paste the contents of the build.xyz files here, but in short, what they do is check for the pre-requisites, like if dotnet is installed, install it if needed, then run the build project. These will be what we use in our CI server (or locally) to kick of a build. nuke file marks the root directory and contains the default solution file, nothing fancy, but more interesting than that are the () files, used to bootstrap NUKE, either on Windows/Powershell or Unix/Bash. We can see the expected new build project ( _build.csproj and other related files), but we can also see that some additional files were added to the repository’s root. Won’t use GitVersion to handle the project versioningĪfter finishing the setup, we can take a look at the solution folder to see what went on:.artifacts for the output of the build (e.g.Selected the locations of key components.NET CLI to implement the build definition (the alterative was MSBuild/Mono) Accepted the help to get things started.Use the only available solution as the default one.Used the suggested build project name and location.It provides a nice little wizard, to guide us through the setup. Then we can use it to get things initialized. Going through the docs, there’s a pretty straightforward procedure to get things going, by installing a global tool and using it to initialize NUKE in our solution.ĭotnet tool install Nuke.GlobalTool -global With NUKE defining things in a console application, the support is there to begin with. What makes this interesting is that, even though Cake allows us to define things in C#, it still requires IDE/plugins to support it, and at least the last I tried it, IntelliSense didn’t work as well. This time I’m going with NUKE instead of Cake, not only to test out a different tool, but also because it has one trait that seems really interesting: the build is defined in a console application. Decouple the build definition from the CI/CD provider used, making it easier to migrate or even run in more than one at the same time.
0 Comments
Leave a Reply. |