#### Community support has been moved to https://github.com/cake-build/cake/discussions ####
Looking for input / feedback...
I have a lightweight test framework I call tclite. It's somewhat modelled after NUnit and NUnitLite, but with some differences. One use I have for it is to write tests in my cake scripts. For me, these are mostly system tests, which create output in XML format. I could, of course, have a separate test assembly to verify the format of the output, but I found it more convenient that my tests should live in the scripts themselves.
Currently, my mini-test-framework lives in a set of .cake
files but it could be in a separate assembly referenced by the script.
So... questions...
I suggest short answers here, longer via my email, which is my name here on gmail.
@CharliePoole We have question how to implement tests in Cake scripts from time to time here, so I assume something like this would be useful for some people.
Btw we started to use mainly GitHub discussions instead of this Gitter channel.
You might want to post there too for better coverage.
.cake
files as NuGet packages. It's what we call Recipe NuGet packages
Question 2:
So my use cases for something you suggested are mainly for testing of the recipe scripts, where I see two main use cases:
It's interesting that my own greatest need for this has come in testing extensions to the NUnit engine, where I don't want to write a test host to simulate completely the behavior of NUnit console and it's engine in calling the extension, because that's complex and error-prone and will need to be modified any time the engine is changed. But others would no doubt find different uses.
Anyway, I'm thinking that making it available to folks is the best way to find out what those uses are.
I'll move this to the GitHub discussions as you suggest.
Hi, I am trying Cake.AzureDevOps, trying to get pull request:
var pullRequestSettings =
new AzureDevOpsPullRequestSettings(
new Uri("http://myazuredevops/DefaultCollection/project/_git/CoreServices"),
"refs/heads/master",
AzureDevOpsAuthenticationNtlm());
var pullRequest =
AzureDevOpsPullRequest(
pullRequestSettings);
here it fails:
Error: System.AggregateException: One or more errors occurred. (Pull request not found)
---> Cake.AzureDevOps.Repos.PullRequest.AzureDevOpsPullRequestNotFoundException: Pull request not found
Please tell me, somebody, what am I horribly not realizing /missing? :).
Thanks...
@bravecobra Indeed, HKCU is not exposed in IRegistry and WindowsRegistryKey is internal which makes it harder for you to create your own reference to HKCU using IRegistryKey
.
You'll have to use the Registry classes directly from Microsoft.Win32.Registry
instead of using the Cake abstraction.
@ipavlu The source branch in the AzureDevOpsPullRequestSettings seems to be wrong:
var pullRequestSettings =
new AzureDevOpsPullRequestSettings(
new Uri("http://myazuredevops/DefaultCollection/project/_git/CoreServices"),
"refs/heads/master",
AzureDevOpsAuthenticationNtlm());
refs/heads/master
needs to be the branch which you want to merge with the pull request (feature/topic branch), not the target branch.
@bravecobra You're welcome. You absolutely can use Cake to interact with the Registry... You just can't use the Cake abstraction to it (yet) for your use-case.
Using the .NET classes directly should work just fine e.g.
using Microsoft.Win32;
var hkcu = Registry.CurrentUser;
var subKeyNames = hkcu.GetSubKeyNames();
foreach (var name in subKeyNames)
{
Information("Key name: {0}", name);
}
@tannerwatson :point_up: January 5, 2021 4:00 PM It should be fairly easy to implement a module for Pip similar to the Npm one if you take the same approach as the Npm module of executing Pip via ProcessRunner. In that case the only dependency you'll have is Python/Pip, which users might already have on the machine, or you can instruct users to download Python from NuGet as a tool e.g.
#module nuget:?package=Cake.Pip.Module&version=x.y.z
#tool "nuget:?package=python&version=3.9.1"
#tool "pip:?package=setuptools&version=49.2.1"
// ...
Alternatively you can implement the Pip protocol yourself - which would be more elegant, but with more work involved.
context.Tools.Resolve(string)
may find the tool from the previous version which still exists in the tools folder. Should we always clear out the tools directory before changing a package reference?
I might be doing this wrong, but I noticed that if you upgrade a reference in your cake build script
context.Tools.Resolve(string)
may find the tool from the previous version which still exists in the tools folder. Should we always clear out the tools directory before changing a package reference?
@aeos I ran a few tests just now and was not able to reproduce it. This is what I've done:
tools1.cake:
#tool "nuget:?package=python&version=3.9.1"
var pythonExePath = Context.Tools.Resolve("python.exe");
var exitCode = StartProcess(pythonExePath, "--version");
Information("Exit code: {0}", exitCode);
tools2.cake:
#tool "nuget:?package=python&version=3.10.0-a4&prerelease"
var pythonExePath = Context.Tools.Resolve("python.exe");
var exitCode = StartProcess(pythonExePath, "--version");
Information("Exit code: {0}", exitCode);
dotnet cake tools1.cake --verbosity=Diagnostic
Executing: "C:/augustoproiete/cake-tool-1-0-0--rc0002/tools/python.3.9.1/tools/Lib/venv/scripts/nt/python.exe" --version
dotnet cake tools2.cake --verbosity=Diagnostic
Executing: "C:/augustoproiete/cake-tool-1-0-0--rc0002/tools/python.3.10.0-a4/tools/Lib/venv/scripts/nt/python.exe" --version
#tool "nuget:?package=python&version=3.8.7&prerelease"
var pythonExePath = Context.Tools.Resolve("python.exe");
var exitCode = StartProcess(pythonExePath, "--version");
Information("Exit code: {0}", exitCode);
dotnet cake tools3.cake --verbosity=Diagnostic
Executing: "C:/augustoproiete/cake-tool-1-0-0--rc0002/tools/python.3.8.7/tools/Lib/venv/scripts/nt/python.exe" --version
No pyvenv.cfg file
.exe
of the correct version
#tool
directive is used. That registry is queried first.
nm, moved to github discussion