Allow classic cake syntax in frosting projects

[mabead]

Context

I've been using cake for about 4 years at my current job. With about 25 micro-services being built & tested using cake, I think that we can say that the adoption is a great success. The fact that Cake is c# syntax was one of the key factor for adoption.

But even with these signs of success, many of my teammates are reluctant to contribute to our cake scripts. So we most often end-up with only a few folks that are ready to really get involved in the cake scripts. The push back that we get often looks like this:

You're telling me it's c# syntax right? Then why can't I just edit and debug in Visual Studio? What are these addin and load preprocessor directives? This doesn't look like c# to me... And why can't I have intellisense without having to install some custom VS extensions? How do I use a pre-release version of our internal Cake helpers library?

I recently discovered that cake now has the frosting runner which will finally answer these questions with satifiying answers. Great job for this 👍

Problem

I tried to migrate one of our cake scrpit and I quickly came to the conclusion that frosting is similar in terms of concepts (setup, teardown, tasks, dependencies) with the standard runner but the implementation is totally different. For example, let's say that I have a standard set of tasks like this:

Task("Restore")
    .Does(() => Information("Restore"));

Task("Build")
    .IsDependentOn("Restore")
    .Does(() => Information("Build"));

When I translate these in Frosing syntax, I end-up with something that looks like this:

    [TaskName("Restore")]
    public sealed class Restore : FrostingTask
    {
        public override void Run(ICakeContext context)
        {
            context.Log.Information("Restore");
        }
    }

    [TaskName("Build")]
    [Dependency(typeof(Restore))]
    public sealed class Build : FrostingTask
    {
        public override void Run(ICakeContext context)
        {
            context.Log.Information("Build");
        }
    }

This works fine but I think that it's not ideal for adoption of frosting. Here are the problems that I see:

• even though the concepts are the same, the syntax is completely changed. So porting a standard cake script to frosting requires lots of code changes.
• the syntax is more verbose. It just takes a lot of more code (classes, inheritance, override, attributes) to the same thing.
• intellisense does not help you to get started and discover what is available/possible. The programmer must know what are the base classes available (Ex: FrostingTask, AsyncFrostingTask), the attributes, etc. If the programmer is not aware of these tools, intelli-sense will not help him to discover them after typing a . following a method/property call. From my experience, a typical developer contributes to a cake scripts at most once every 3 months. So the number of things that he must know / remember should be minimal.

Proposition

I looked at the code of frosting and came to the conclusion that these problems could be adressed by removing some syntactic sugar of Frosting (I don't like cake with too much frosing in real life as well 😉 ). This can easilly be done by using the ICakeEngine. I quickly hacked the ICakedHost.Run method to accept a callback that makes it possible to configure the cake engine with a syntax that is very very similar to the classic cake syntax. I tried to convert the Cake.Frosting.Example to this pattern. Here's what it looks like:

public class Program
{
    public static void SetupCake(ICakeEngine engine)
    {
        var hello = engine.RegisterTask("Hello")
            .Does((context) =>
            {
                context.Log.Information("Hello!");
            });

        var world = engine.RegisterTask("World")
            .IsDependentOn(hello)
            .Does(async (context) =>
            {
                context.Log.Information("About to do something expensive");
                await Task.Delay(1500);
                context.Log.Information("Done");
            });

        var magic = engine.RegisterTask("Magic")
            .WithCriteria((context) => context.Environment.Platform.Family != PlatformFamily.OSX)
            .IsDependentOn(world)
            .Does((context) =>
            {
                context.Log.Information("Value is: {0}", context.Arguments.HasArgument("magic"));
            });

        engine.RegisterTask("Default")
            .IsDependentOn(magic);
    }

    public static int Main(string[] args)
    {
        var host = new CakeHostBuilder()
            .WithArguments(args)
            .Build();

        return host.Run(SetupCake);
    }
}

Here's what I find interesting in this approach:

• the syntax is almost the same as the one of a classic cake script. It therefore makes it trivial to port standard cake scripts to Frosting.
• the syntax is less verbose than frosting and it is similar (in terms of verbosity) to the one of standard cake scripts.
• intellisense helps the programmer to figure out what is available. For example, if he wants to add a criteria to a task but he does not exactly remember the syntax / name of the method, he can just start typing and the intelli-sense will most likely find what he is looking for. With frosting tasks, it's harder to discover such things: Is it and attribute? An override? A different base class?

You may completely disagree with how I hacked the ICakeHost.Run method and that's ok. The goal of this discussion is not to agree on the how . The goal is to discuss about the concept of adding a simpler syntax to frosting. Also note that I am not talking about replacing the current Frosting strategy. I am just trying to discuss of a way to have best of both worlds:

• from classic cake: minimalist syntax
• from frosting: A console application has the advantage of full IDE support, like IntelliSense, refactoring and debugging.

Thank you in advance for your time and also a huge thanks for creating cake. I just can't imagine anymore the days where we were working with psake or xml msbuild scripts. These were the dark days of the .net build system 😨

[devlead]

There're other similar PoC approaches done i.e. Cake.Bridge which will let you have a Program.cs looking something like this

using System.Linq;
using Cake.Common;
using Cake.Common.Diagnostics;
using Cake.Common.IO;
using Cake.Common.Tools.DotNetCore;
using Cake.Core;
using CakeConsoleRunner;
using static CakeBridge;

var target = Context.Argument<string>("target", "Build");

Setup(context =>
{
    context.Information("Setting up...");

    return new BuildData(
        Context
            .GetFiles("./src/*.sln")
            .FirstOrDefault()
        ??
        Context
            .GetFiles("../../src/*.sln")
            .FirstOrDefault()
        ??
        Context
            .GetFiles("../../../../*.sln")
            .FirstOrDefault());
});

Teardown(context =>
{
    context.Information("Tearing down...");
});

var restore = Task("Restore")
    .Does<BuildData>(buildData =>
    {
        Context.DotNetCoreRestore(buildData.Solution.FullPath);
    });

var build = Task("Build")
    .IsDependentOn(restore)
    .Does<BuildData>(buildData =>
    {
        Context.DotNetCoreBuild(buildData.Solution.FullPath);
    });

RunTarget(target);

And Cake.Bridge.DependencyInjection that takes the IoC route letting you do code like

var serviceCollection = new ServiceCollection()
    .AddCakeCore();

var serviceProvider = serviceCollection.BuildServiceProvider();

var scriptHost = serviceProvider.GetRequiredService<IScriptHost>();

scriptHost.Task("Hello")
    .Does(ctx => ctx.Information("Hello"));

scriptHost.Task("World")
    .IsDependentOn("Hello")
    .Does(ctx => ctx.Information("World"));

await scriptHost.RunTargetAsync("World");

Both Cake.Bridge.DependencyInjection and Cake.Bridge are up on NuGet if one wants to take them for a spin.

[mabead]

@devlead @pascalberger did you reach a conclusion on the place that Cake.Bridge could take in the cake ecosystem?

I am asking the question because one of my collegue had to fight for more than a day to invoke a c# function of the AWS SDK from a cake script. This is a lot of wasted time to just call a function 😢

In the end, he fixed the issue by replacing:

#addin "nuget:?package=AWSSDK.Lambda"

by

#addin "nuget:?package=AWSSDK.Lambda&version=3.7.0.23&loaddependencies=true"

This is the kind of problem that would never have happened if our build script was using direct c# just like frosting and cake.bridge do.

The problem with frosting is that the migration path is just too painfull. I don't see the time where we will do such a migration.

[augustoproiete]

@mabead Not to hijack this thread (It's def. worth exploring how we can improve the migration path to Frosting from Cake), but I also would like to understand how we could improve Cake scripting as well in the scenario you described.

Are you able to share the error message you get? Perhaps Cake scripting would be able to show a better error message that would immediately send you in the right direction and avoid the issue altogether?

Another avenue to explore could be to make LoadDependencies=true by default in Cake v2.0. This is something you can enforce today by dropping a cake.config file in your repo that sets LoadDependencies=true by default. You can get a template/example here.

[mabead]

@augustoproiete My collegue was trying to invoke an AWS lambda function like this:

InvokeResponse response = await _lambdaClient.InvokeAsync(new InvokeRequest 
        {
            FunctionName = "GitHubActions-RequestToken",
            InvocationType = InvocationType.RequestResponse,
            Payload = JsonConvert.SerializeObject(new RequestTokenPayload(this.LockName, concurrency, expiration))
        });

He was then getting an error like this:

Error: System.AggregateException: One or more errors occurred. (One or more errors occurred. (1 validation error detected: Value '{FunctionName}' at 'functionName' failed to satisfy constraint: Member must satisfy regular expression pattern: (arn:(aws[a-zA-Z-]*)?:lambda:)?([a-z]{2}((-gov)|(-iso(b?)))?-[a-z]+-\d{1}:)?(\d{12}:)?(function:)?([a-zA-Z0-9-_\.]+)(:(\$LATEST|[a-zA-Z0-9-_]+))?))

Then, as soon as he changed #addin "nuget:?package=AWSSDK.Lambda" by #addin "nuget:?package=AWSSDK.Lambda&version=3.7.0.23&loaddependencies=true" it started working. He doesn't know if the problem was fixed by adding version or by adding loaddependencies=true. I suspect the later.

[augustoproiete]

Thanks @mabead. I tried to repro with the code sample above, but I get a very different result. Is it possible the error was caused by a different code path?

#addin "nuget:?package=AWSSDK.Lambda"

using Amazon;
using Amazon.Lambda;
using Amazon.Lambda.Model;

IAmazonLambda lambdaClient;

var response = await lambdaClient?.InvokeAsync(new InvokeRequest
{
    FunctionName = "GitHubActions-RequestToken",
    InvocationType = InvocationType.RequestResponse,
    Payload = "{ \"test\": 10 }",
});

And I get a compilation error (as expected) because the dependent assembly containing AmazonLambdaClient is missing:

The 'addin' directive is attempting to install the 'AWSSDK.Lambda' package
without specifying a package version number.
More information on this can be found at https://cakebuild.net/docs/writing-builds/reproducible-builds/
It's not recommended, but you can explicitly override this warning
by configuring the Skip Package Version Check setting to true
(i.e. command line parameter "--settings_skippackageversioncheck=true",
environment variable "CAKE_SETTINGS_SKIPPACKAGEVERSIONCHECK=true",
read more about configuration at https://cakebuild.net/docs/running-builds/configuration/)
Could not load .\tools\Addins\AWSSDK.Lambda.3.7.0.25\lib\netcoreapp3.1\AWSSDK.Lambda.dll (missing AWSSDK.Core, Version=3.3.0.0, Culture=neutral, PublicKeyToken=885c28607f98e604)
/test-error-load-deps.cake(9,36): error CS0012: The type 'IAmazonService' is defined in an assembly that is not referenced. You must add a reference to assembly 'AWSSDK.Core, Version=3.3.0.0, Culture=neutral, PublicKeyToken=885c28607f98e604'.
/test-error-load-deps.cake(9,35): error CS0012: The type 'IAmazonService' is defined in an assembly that is not referenced. You must add a reference to assembly 'AWSSDK.Core, Version=3.3.0.0, Culture=neutral, PublicKeyToken=885c28607f98e604'.
Error: Error(s) occurred when compiling build script:
/test-error-load-deps.cake(9,36): error CS0012: The type 'IAmazonService' is defined in an assembly that is not referenced. You must add a reference to assembly 'AWSSDK.Core, Version=3.3.0.0, Culture=neutral, PublicKeyToken=885c28607f98e604'.
/test-error-load-deps.cake(9,35): error CS0012: The type 'IAmazonService' is defined in an assembly that is not referenced. You must add a reference to assembly 'AWSSDK.Core, Version=3.3.0.0, Culture=neutral, PublicKeyToken=885c28607f98e604'.

It seems that your Cake build script was compiling successfully and you were getting a runtime error rather than a compilation error, which would hint that somehow AWSSDK.Core.dll was present (and perhaps loaddependencies=true was not really the fix (?) 🤔).

[mabead]

@augustoproiete I'm pretty sure that he error was caused by this code path. Unfortunately, since I didn't face the problem myself, I can't give much more details that this.