Cake VS run

This is why 90-99% of our builds are done with Cake. It isolates all of it and you can run the build locally if you want.

I don't think it will get too much confusion, but there is a build system called Cake: https://cakebuild.net/

You may use other tools too: psake, make, cake, fake or any other *ake you are familiar with. I look at them as a tools that make build tasks behind simple commands and help me answer: How did I run that code again?

NAnt was quite a popular build tool used by projects of all sizes targeting .NET Framework on Windows. I have written many complex build systems using NAnt in the past. But XML based DSL was quite clunky to use and maintain. Besides, it was always a daunting task to explain to a new dev on the team. With .NET Core/.NET becoming a cross-platform framework, CAKE and FAKE gained a lot of adoption providing a C# and F# based DSL for build tasks accordingly.

Cake (C# Make) - simple, easy to set up, and with a lot of extensions scripting with C#.

For those not familiar with it, Cake is a build automation system with a C#-based DSL. It is based on the concept of tasks, which are small units of work, like restoring packages, building, or testing, which can have dependencies on, or trigger, other tasks.

Just a note: there's already a very active community of the same name for the build utility Cake.

Looks interesting! Although the name clashes with Cake (C# Make) project which could be confusing - https://cakebuild.net/

The recipe utilizes the Cake build automation .NET Tool in the background, but essentially the recipe exposes a C# class with a few properties you can control the recipe behavior, but the intention is that you should just set what's needed for your application and rest boring boiler plate is handled for you, and the recipe will automatically detect if it's running on GitHub actions and provided right secrets in place publish to Azure blob storage.

I've been using Run [0] for this purposes.

[0]: https://github.com/TekWizely/run

If you like to use make as a task runner, may I recommend you take a look at my entry into the ecosystem:

* https://github.com/TekWizely/run

Feels like make (by design) but purpose-built for managing small tasks.

Make is not actually that great of a task runner, but the syntax is easy and its ubiquitous.

I created a tool that allows you to define tasks in the easy make-style, but is purpose-build to be a task runner:

* https://github.com/TekWizely/run

To the extent that posts like these evolve into discussing the merits of Make as a task runner, I would like to offer my tool for review:

* https://github.com/TekWizely/run

I built it to feel like make, but be better at managing tasks and wrappers.

If you are evaluating task runners and appreciate the simplicity of Make's syntax, I hope you'll give Run a try.

A tool that I created in the same category:

RUN : A Task runner that helps you easily manage and invoke small scripts and wrappers

* https://github.com/TekWizely/run

Do you find yourself using tools like make to manage non-build-related scripts?

Build tools are great, but they are not optimized for general script management.

Run aims to be better at managing small scripts and wrappers, while incorporating a familiar make-like syntax.

Some features:

* Auto generates command list

* Auto generates help for commands

* Supports defining command-line arguments, which are presented in help text

* Can be composed via includes

* Each command can define its own shell (or even python, etc)

If you're interested in task runners, I hope you'll take a look!

I invite you take a look at Run, a similar tool that I maintain:

* https://github.com/TekWizely/run

Support for including other Runfiles was recently introduced, with support for globbing and the ability to indicate if an error should be generated if no files are found.

This looks like an interesting way to manage scripts globally. I could even see it able to manage n-sub-commands deep (vs usual "command sub-command" - maybe it already does?) by just trying to resolve each argument as a dir until you find a script to execute.

If you're interested in ways to better-manage small scripts and wrappers more locally, please take a look at my project, Run:

https://github.com/TekWizely/run