{{ message }}
Repository navigation
Integrate Cake as a dotnet CLI extension for .NET Core applications #1644
Description
I couldn't find if this has been suggested before, but I was looking at FlubuCore and how they integrate nicely with the dotnet CLI.
It struck me that this might be a perfect fit for cake too. I mean, wouldn't it be nice to do the following:
-
Restore regular NuGet packages and Cake with its addins
dotnet restore -
Run the do-the-thing task that you would normally call with
build.ps1 -Target "do-the-thing"
dotnet cake do-the-thing
I'm currently using Cake on a few projects here at work, and it's great! This sort of integration would make it even better though. 👍
Activity
maximpashuk commentedon Jul 13, 2017
@devlead Can you give your opinion on this issue?
I read the articles
https://docs.microsoft.com/en-us/dotnet/core/tools/extensibility
https://docs.microsoft.com/en-us/nuget/create-packages/creating-a-package#setting-a-package-type
It says that to implement Cake.CoreClr as dotnet cli tool you should make 2 things:
<PackageType>DotnetCliTool</PackageType>in csproj.Also dotnet cli repository
https://github.com/dotnet/cli/tree/master/TestAssets/TestPackages
contains some examples of cli tools.
Any plans to make Cake.CoreClr as cli tool?
patriksvensson commentedon Jul 13, 2017
@maximpashuk Thanks for your feedback. Currently we got no plans to add a CLI tool for Cake.
JonCubed commentedon Jul 13, 2017
@patriksvensson would you consider community contributions for this?
adamhathcock commentedon Jul 14, 2017
I’m not sure what benefit an extension would be. Since installing a tool requires a project file, bootstrapping is awkward.
If they had a story that allows dotnet tools to be installed outside of a project then it might be useful, imo.
JonCubed commentedon Jul 15, 2017
@adamhathcock you can have path based tools so it can be use across multiple solutions.
I can see it as a benefit to having it integrate into the tool chain that .net core users are already using and removing the need for the bootstrap script. I'm not doing anything funky with my bootstrap but perhaps for those that are having extensiblity hooks will be enough.
amoerie commentedon Jul 15, 2017
That would mean every project you ever want to build on a machine has to share the same cake version though, which is unacceptable for CI build agents.
Coming from MSBuild, we had a global project wide packages.config file that referenced MSBuild extension packages hosted on NuGet. We also had a build.proj file that contained our project wide tasks.
The build.proj file has been replaced with build.cake, so maybe we can make a packages.csproj file that is only used for references to Cake? That would allow for repository specific Cake versions, just like now.
adamhathcock commentedon Jul 15, 2017
well, I can see an advantage being you bootstrapper to install the tool then just use the
dotnettool CLI instead of a bootstrap script. It's not a huge one though.doing
dotnet cake run <target>just seems neat.I definitely agree you generally don't want to install Cake system wide because of versions in CI.
JonCubed commentedon Jul 15, 2017
@amoerie I don't believe that would be the case as tooling supports other methods like per-project and custom msbuild targets, it seems flexible enough for the various needs that will pop up.
I could see it working similar to npm packages where some are installed globally so you can init projects, modify files and be usable by editors, but each project then adds it so the version is pinned.
Global installs could also make sense when using containers as your agents.
amoerie commentedon Jul 15, 2017
Ah yes as long as system wide is not the default "officially encouraged" option I agree that it can be useful for certain people. Imho, the recommended approach should be repository-specific Cake versions.
I believe the biggest benefit of implementing this would be lowering the barrier of entry for Cake. Playing nice with the dotnet CLI would also be a gesture of maturity and good will I believe.
Finally, getting rid of the powershell script would be a bonus too, it's a bit unfortunate that this has to be copy pasted in every repository just to bootstrap the build system.
adamhathcock commentedon Jul 15, 2017
I don't think you can avoid a script for installation unless you somehow have a base project with the tool configured. Tools aren't at a solution level and there's no way to install them local to a repository without a project.
I've used a bootstrap project with some generated XML which could be a tool reference instead of a package reference.
phillipsj commentedon Dec 15, 2017
So I have started doing exactly this: https://github.com/phillipsj/dotnet-cake
I think it would be easier to just
The run the command like above
I have slowed down on it, but with the recent talk of bringing more of the bootstrapper into Cake itself, this is going to be a little simpler.
andycmaj commentedon Feb 6, 2018
sounds like it would be appropriate for this to be a dotnet core global tool
phillipsj commentedon Feb 6, 2018
adamhathcock commentedon Feb 6, 2018
Cake as a global tool is something I definitely want. Should be doable after the Net core 2 stuff is merged.
amoerie commentedon Feb 6, 2018
I see this thread is still going strong. While I'm advocating for nor against this CLI tool issue, we decided to continue with Cake Frosting.
The gist of this is that it removes the need for build.cake files, and instead makes you write your build logic as a console application that can be part of your solution. This has two big benefits:
Running your build is as easy as "dotnet publish your-build-app && your-build-app.exe". We still use a build.ps1 to file to ensure nuget is installed, the dotnet CLI is installed, etc.
Intellisense and debugging! Even though there is an excellent extension for VS Code now, it still cannot beat full fledged IDEs such as Visual Studio or Rider. With Cake.Frosting, your Cake targets are just C# classes that inherit from FrostingTask, and it's just another program you run.
Cake.Frosting is still in alpha, but has been stable enough for us to rely upon it.
P.S. @patriksvensson what's stopping a stable release for Cake.Frosting? If you need help..
adamhathcock commentedon Feb 6, 2018
That doesn’t seem desirable to me.
I want a cake file that’s an easy script to read for gluing builds together.
The worst part of cake has always been invoking it. Installing a global tool that’s just “cake -t build” or something seems great to me.
phillipsj commentedon Feb 6, 2018
ErikSchierboom commentedon Jun 7, 2018
This would be great to have.
Completely agree. By the way, Fake now supports this.
amoerie commentedon Jun 7, 2018
Ah, with the advent of dotnet global tools, I will close this issue in favor of #2067
(cake-buildGH-2067) Cake .NET Core Tool package
(cake-buildGH-2067) Cake .NET Core Tool package
(cake-buildGH-2067) Cake .NET Core Tool package
Merge branch 'release/0.30.0' into main