myke

myke makes it easy to write development tasks

Development scripts usually begin as a simple shell wrapper with switch cases (service.sh start|stop|etc), and then aggregate multiple scripts, add arguments, discovery/listing, environment variable handling, then easy overriding and defaults, and soon manipulating files based on these variables, sed|awk|envsubst, then proceed to python/ruby/etc with some real templating, then start adding dependencies, then become projects themselves with a checkout/setup process

myke solves all these problems in a single tiny binary, to avoid reinventing the same stuff over and over again.

Features

Define tasks in simple .yml files
Tasks execute in a predictable environment irrespective of which folder they are invoked from
Nice aggregation and discovery with tag-based grouping, suitable for few and many tasks, organizing into subfolders/submodules/repos/projects
Robust environment handling - Can be defined as keys in the YML or as dotenv files, overridden by dotenv.local files, PATH is always prepended, shell always takes precedence
Built-in templating using golang text/template and 50+ functions provided by sprig
Mixin ymls to share tasks, envvars, etc
Runtime arguments like myke task1 --key1=val1 task2 --key2=val2 ...
before/after/error hooks to perform cleanups, chains with mixins, etc
retry support with max and delay for failing tasks
Tiny, cross-platform binaries
and a lot of small utilities packed in

Usage

Create myke.yml with tasks. For example, running myke on this folder prints:

  PROJECT  |    TAGS    |             TASKS
+----------+------------+-------------------------------------+
  myke     |            | test
  example  |            | build
  env      |            | env
  tags1    | tagA, tagB | tag
  tags2    | tagB, tagC | tag
  depends  |            | after, before, before_after, itself
  template |            | args, file
  mixin    |            | task2, task3, task1

Using the above myke.yml, you can invoke tasks like:

myke build runs build in all projects
myke <project>/build runs build in that specific <project>
myke <tag>/build runs build in all projects tagged <tag>
myke <tagA>/<tagB>/.../build can match tasks by many tags (AND)
myke task1 --key1=val1 task2 --key2=val2 ... passes arguments to individual tasks

Installation

Grab the latest release

Examples

Explore the self documenting examples folder.

Task Execution Environment

tasks always run with cwd set to the folder where the task is defined
cwd/bin is always added to PATH
environment variables are loaded from:
- env property in yml
- dotenv files from env_files
- for every dotenv file, the corresponding dotenv .local file is also loaded if present
same is done for every mixin that the yml uses
- So, if you mixin <some-other-folder>/myke.yml, then that yml's cwd/bin is also added to the PATH, that yml's env/env_files/env_files.local are also loaded, and so on
shell exported environment variables take precedence
additional variables: $MYKE_PROJECT, $MYKE_TASK, $MYKE_CWD are always set
- $myke is set to full path of myke itself to easily nest myke calls (e.g. $myke do_something will become myke.exe do_something in windows)
command is templated using golang text/template and sprig
- environment and task arguments are passed in as variables
command is run using sh -exc

FAQs

How do I share common logic in tasks?

There are multiple ways including:

Place shared scripts in bin folder (remember that CWD/bin is always added to the PATH). If the scripts are complex, you can write them in any scripting language of your choice
If multiple projects need to share the same scripts, then use a common mixin folder (remember that for mixin ymls - the same CWD/bin is added to PATH, same env files are loaded, etc, refer Task Execution Environment above)

For example,

java-mixin
- myke.yml - project template with tasks
- myke.env - environment vars, can be overridden by extending projects
- bin - gets added to the PATH of extending projects
  - any shared scripts that you want
kubernetes-mixin
- ...
- ...

Why use myke?

Deferring higher order build logic (like reading scm history for changelogs, updating scm tags/branches, generating version numbers, etc) to a meta-build tool (like a task runner or aggregator), restricting build tools to do only simple source builds, and having a shared build vocabulary across projects is a generally good idea. There are millions of such meta-build tools or task aggregators out there, we just wanted something fast, zero-dependency and language-agnostic while still helping us manage multiple components across repositories with ease.

In that sense, myke is never a build or deployment tool, its just a task aggregator. Its not designed to be an alternative for source build tools, rather it just augments them. The comparison below is on that same perspective.

maven is a lifecycle reactor and/or project management tool that does a lot of things (compilation/scm/release/lifecycle/build/etc), except its hard to use it as a simple task runner. myke focuses only on the latter
bazel buck pants gradle ... replace your current buildchain by giving you a totally new DSL to compile your programs (java_binary, etc). myke simply acts as a yml-based interface to your existing tools and workflows, thereby not needing to change your project and IDE setup
grunt gulp pyinvoke rake sake thor ... myke is zero-dependency, language agnostic, uses simple yml and allows aggregation of tasks through hierarchies, templates and tags
make scons ninja ... they are low-level build tools with a crux of file-based dependencies. Most buildchains today are already intelligent enough to process only changed files, so myke completely bypasses file tracking and only focuses on task aggregation and discoverability
capistrano fabric ... myke is not a deployment tool for remote machines, and does not do anything over SSH
ansible salt ... myke is not a configuration management tool, its a task runner
robo is the closest relative to myke, you should check it out as well

Development

Use docker/docker-compose to develop. You don't need to have golang installed.

docker-compose build Builds and runs tests
docker-compose up Produces bin folder with executables
docker-compose run --rm default /bin/bash Gives you a terminal inside the container, from where you can run go commands like:
- go test ./... Runs all tests
- go run main.go Compiles and runs main

omio-labs/myke