feat(execution): Add flexible build execution methods and options
A Big Thank You for a Great Product
First and foremost, I want to express my gratitude for creating such a fantastic tool. It has been invaluable in our build processes, and the flexibility it offers is truly appreciated.
Description of the Issue:
While running multiple build types, I encountered an issue with the following exception:
The process cannot access the file '...\.nuke\temp\build.log' because it is being used by another process.
Upon investigation, I found that in the DeleteOldLogFiles method, the second call to filestream.SetLength(0); triggers this exception. This happens because the log file remains locked even after calling Log.CloseAndFlush(); in the preceding step.
Solution:
To address this issue, I introduced a new approach that allows for more flexible log configuration during build execution. Specifically:
New Method:
Added ExecuteWithOptions<T> methods in both BuildManager and NukeBuild.
These methods allow for optional execution parameters to be specified, including whether or not the log should be configured.
New Class:
Introduced an ExecuteOptions class to manage these execution parameters.
This class includes an option to disable the default log configuration, preventing the aforementioned file lock issue.
Logging Configuration:
Updated BuildManager to conditionally configure logging based on the provided ExecuteOptions.
This solution ensures that build execution can proceed without file locking issues while providing more control over logging behavior.
I confirm that the pull-request:
- [x] Follows the contribution guidelines
- [x] Is based on my own work
- [x] Is in compliance with my employer
I chose to introduce a new method name, ExecuteWithOptions, instead of creating an overload for the existing Execute method. This decision was made to avoid any potential issues with reflection resolving the correct method.
Thanks for the suggestion, but at the moment that's not something that appeals to me.