Command line tool to frictionlessly manage project-specific commands.

<h1 align="center">
  <br>
  <a href="https://github.com/gopinath-langote/1build">
    <img src="https://github.com/gopinath-langote/1build/blob/master/docs/assets/1build-logo.png?raw=true" alt="1build" width="500"></a>
  <br>
</h1>

<br>

<p align="center">
  <a href="https://github.com/gopinath-langote/1build/releases/latest">
    <img src="https://img.shields.io/github/release/gopinath-langote/1build?label=version" alt="1build Version">
  </a>
  <a href="https://github.com/sindresorhus/awesome">
    <img src="https://cdn.rawgit.com/sindresorhus/awesome/d7305f38d29fed78fa85652e3a63e154dd8e8829/media/badge.svg" alt="Awesome" /></a>
  <a href="https://github.com/gopinath-langote/1build/blob/master/LICENSE">
    <img src="https://img.shields.io/github/license/gopinath-langote/1build" alt="License">
  </a>
  <a href="https://travis-ci.org/gopinath-langote/1build">
      <img src="https://travis-ci.org/gopinath-langote/1build.svg?branch=master" alt="Build Status">
  </a>
  <a href="https://goreportcard.com/report/github.com/gopinath-langote/1build">
        <img src="https://goreportcard.com/badge/github.com/gopinath-langote/1build" alt="Go Report Card">
    </a>
</p>

<br>

1build is an automation tool used for research and development projects that arms you with the convenience to configure project-local command line aliases – and then
run the commands quickly and easily. It is particularly helpful when you deal with multiple projects and switch between
them all the time. It is often the fact that different projects use different build tools and have different environment
requirements – and then switching from one project to another is becoming increasingly cumbersome. That is where 1build comes
into play.

With 1build you can create simple and easily memorable command aliases for commonly used project commands such as build,
test, run or anything else. These aliases will have a project-local scope which means that they will be accessible only
within the project directory. This way you can unify all your projects to build with the same simple command disregarding
of what build tool they use. It will remove the hassle of remembering all those commands improving the mental focus for
the things that actually matter.

## Install

### Homebrew

```console
brew install gopinath-langote/one-build/one-build
```

### Manual

1.  Download and install binary from [the latest release](https://github.com/gopinath-langote/1build/releases/latest)
2.  Recommended: add `1build` executable to your `$PATH`.

## Usage

### Configuration
-   Create `1build.yaml` configuration file by
    ```console
    1build init --name <your_project_name>
    ```

-   Edit file according to project command list, Example of `1build.yaml` for node project:
    ```yaml
    project: Sample Web App
    commands:
      - build: npm run build
      - test: npm run test
    ```

### Running 1build for the above sample project

-   building the project
```console
  1build build
  ```

-   fix the coding guidelines lint and run tests (executing more than one commands at once)
```console
  1build lint test
  ```

### Set new or update existing configuration

-   Set new command configuration for `lint` to `"eslint server.js"`
```console
   1build set lint "eslint server.js"
   ```
### Remove/Unset existing configuration

-   Unset command configuration for `lint`
```console
   1build unset lint
   ```

-   To unset multiple commands at once
```console
  1build unset lint test build
  ```

### Using `before` and `after` commands
Consider that your project requires some environment variables to set before running any
commands and you want to clean up those after running commands. It is a headache to always
remember to set those environment variables. What you want is to set env variables automatically
when you run the command in the project and remove those when the command is complete.
Another example – a project requires `Docker` to be up
and running or you need to clean up the database after running a test harness.

This is where `before` & `after` commands are useful. These commands are both optional – 
you can use one of them, both or neither.

#### Examples
1.  Setting env variables and cleaning those up
    ```console
    1build set before 'export VARNAME="my value"'
    1build set after "unset VARNAME"
    ```
  
    Configuration with before and after setup
    
    ```yaml
    project: Sample Web App
    before: export VARNAME="my value"
    after: unset VARNAME
    commands:
       - build: npm run build
    ```

2.  Ensure that `Docker` is up and running
    ```console
    1build set before "./docker_run.sh"
    ```

3.  Clean up database after some commands
    ```console
    1build set after "./clean_database.sh"
    ```

4.  Remove `before` and `after` commands
    ```console
    1build unset before after
    ```

### Using `--quiet` or `-q` flag
Sometimes you choose to not see all logs/output of your command and just see success or failure as the outcome.
So using `--quiet` or `-q` flag to 1build command execution will result in just executing the command
but not showing the entire output of it, only shows SUCCESS/FAILURE as result of command execution.
```console
  1build lint test --quiet
  ```
  OR
```console
  1build lint test -q
  ```

See `1build --help` for command usages.

## Contributing

Please read [CONTRIBUTING.md](https://github.com/gopinath-langote/1build/blob/master/CONTRIBUTING.md) for details on our code of conduct, and the process for submitting pull requests to us.

## Versioning

We use [Semantic Versioning](http://semver.org/) for all our releases. For the versions available, see the [tags on this repository](https://github.com/gopinath-langote/1build/tags).

## Changelog
All notable changes to this project in each release will be documented in [Releases Page](https://github.com/gopinath-langote/1build/releases/).

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).

## License

This project is licensed under the MIT License - see the [LICENSE](LICENSE) file for details

## Contributors

<a href="https://github.com/gopinath-langote/1build/graphs/contributors">
  <img src="https://contributors-img.firebaseapp.com/image?repo=gopinath-langote/1build" />
</a>

## Sponsors

<a href="https://www.jetbrains.com/?from=github.com/gopinath-langote/1build">
    <img src="https://github.com/gopinath-langote/1build/blob/master/docs/assets/jetbrains.png?raw=true" alt="1build" width="150"></a>
<a href="https://www.1password.com/?from=github.com/gopinath-langote/1build">
    <img src="https://github.com/gopinath-langote/1build/blob/master/docs/assets/1password.png?raw=true" alt="1build" width="300"></a>


1build

# :cloud: Air - Live reload for Go apps

[![Go](https://github.com/air-verse/air/actions/workflows/release.yml/badge.svg)](https://github.com/air-verse/air/actions?query=workflow%3AGo+branch%3Amaster) [![Codacy Badge](https://app.codacy.com/project/badge/Grade/dcb95264cc504cad9c2a3d8b0795a7f8)](https://www.codacy.com/gh/air-verse/air/dashboard?utm_source=github.com&utm_medium=referral&utm_content=air-verse/air&utm_campaign=Badge_Grade) [![Go Report Card](https://goreportcard.com/badge/github.com/air-verse/air)](https://goreportcard.com/report/github.com/air-verse/air) [![codecov](https://codecov.io/gh/air-verse/air/branch/master/graph/badge.svg)](https://codecov.io/gh/air-verse/air)

![air](docs/air.png)

English | [简体中文](README-zh_cn.md) | [繁體中文](README-zh_tw.md)

## Motivation

When I started developing websites in Go and using [gin](https://github.com/gin-gonic/gin) framework, it was a pity
that gin lacked a live-reloading function. So I searched around and tried [fresh](https://github.com/pilu/fresh), it seems not much
flexible, so I intended to rewrite it better. Finally, Air's born.
In addition, great thanks to [pilu](https://github.com/pilu), no fresh, no air :)

Air is yet another live-reloading command line utility for developing Go applications. Run `air` in your project root directory, leave it alone,
and focus on your code.

Note: This tool has nothing to do with hot-deploy for production.

## Features

- Colorful log output
- Customize build or any command
- Support excluding subdirectories
- Allow watching new directories after Air started
- Better building process

### Overwrite specify configuration from arguments

Support air config fields as arguments:

If you want to config build command and run command, you can use like the following command without the config file:

```shell
air --build.cmd "go build -o bin/api cmd/run.go" --build.bin "./bin/api"
```

Use a comma to separate items for arguments that take a list as input:

```shell
air --build.cmd "go build -o bin/api cmd/run.go" --build.bin "./bin/api" --build.exclude_dir "templates,build"
```

## Installation

### Via `go install` (Recommended)

With go 1.23 or higher:

```bash
go install github.com/air-verse/air@latest
```

### Via install.sh

```shell
# binary will be $(go env GOPATH)/bin/air
curl -sSfL https://raw.githubusercontent.com/air-verse/air/master/install.sh | sh -s -- -b $(go env GOPATH)/bin

# or install it into ./bin/
curl -sSfL https://raw.githubusercontent.com/air-verse/air/master/install.sh | sh -s

air -v
```

### Via [goblin.run](https://goblin.run)

```shell
# binary will be /usr/local/bin/air
curl -sSfL https://goblin.run/github.com/air-verse/air | sh

# to put to a custom path
curl -sSfL https://goblin.run/github.com/air-verse/air | PREFIX=/tmp sh
```

### Docker/Podman

Please pull this Docker image [cosmtrek/air](https://hub.docker.com/r/cosmtrek/air).

```shell
docker/podman run -it --rm \
    -w "<PROJECT>" \
    -e "air_wd=<PROJECT>" \
    -v $(pwd):<PROJECT> \
    -p <PORT>:<APP SERVER PORT> \
    cosmtrek/air
    -c <CONF>
```

#### Docker/Podman .${SHELL}rc

if you want to use air continuously like a normal app, you can create a function in your ${SHELL}rc (Bash, Zsh, etc…)

```shell
air() {
  podman/docker run -it --rm \
    -w "$PWD" -v "$PWD":"$PWD" \
    -p "$AIR_PORT":"$AIR_PORT" \
    docker.io/cosmtrek/air "$@"
}
```

`<PROJECT>` is your project path in container, eg: /go/example
if you want to enter the container, Please add --entrypoint=bash.

<details>
  <summary>For example</summary>

One of my project runs in Docker:

```shell
docker run -it --rm \
  -w "/go/src/github.com/cosmtrek/hub" \
  -v $(pwd):/go/src/github.com/cosmtrek/hub \
  -p 9090:9090 \
  cosmtrek/air
```

Another example:

```shell
cd /go/src/github.com/cosmtrek/hub
AIR_PORT=8080 air -c "config.toml"
```

this will replace `$PWD` with the current directory, `$AIR_PORT` is the port where to publish and `$@` is to accept arguments of the application itself for example -c

</details>

## Usage

For less typing, you could add `alias air='~/.air'` to your `.bashrc` or `.zshrc`.

First enter into your project

```shell
cd /path/to/your_project
```

The simplest usage is run

```shell
# firstly find `.air.toml` in current directory, if not found, use defaults
air -c .air.toml
```

You can initialize the `.air.toml` configuration file to the current directory with the default settings running the following command.

```shell
air init
```

After this, you can just run the `air` command without additional arguments, and it will use the `.air.toml` file for configuration.

```shell
air
```

For modifying the configuration refer to the [air_example.toml](air_example.toml) file.

### Runtime arguments

You can pass arguments for running the built binary by adding them after the air command.

```shell
# Will run ./tmp/main bench
air bench

# Will run ./tmp/main server --port 8080
air server --port 8080
```

You can separate the arguments passed for the air command and the built binary with `--` argument.

```shell
# Will run ./tmp/main -h
air -- -h

# Will run air with custom config and pass -h argument to the built binary
air -c .air.toml -- -h
```

### Docker Compose

```yaml
services:
  my-project-with-air:
    image: cosmtrek/air
    # working_dir value has to be the same of mapped volume
    working_dir: /project-package
    ports:
      - <any>:<any>
    environment:
      - ENV_A=${ENV_A}
      - ENV_B=${ENV_B}
      - ENV_C=${ENV_C}
    volumes:
      - ./project-relative-path/:/project-package/
```

### Debug

`air -d` prints all logs.

## Installation and Usage for Docker users who don't want to use air image

`Dockerfile`

```Dockerfile
# Choose whatever you want, version >= 1.16
FROM golang:1.23-alpine

WORKDIR /app

RUN go install github.com/air-verse/air@latest

COPY go.mod go.sum ./
RUN go mod download

CMD ["air", "-c", ".air.toml"]
```

`docker-compose.yaml`

```yaml
version: "3.8"
services:
  web:
    build:
      context: .
      # Correct the path to your Dockerfile
      dockerfile: Dockerfile
    ports:
      - 8080:3000
    # Important to bind/mount your codebase dir to /app dir for live reload
    volumes:
      - ./:/app
```

## Q&A

### "command not found: air" or "No such file or directory"

```shell
export GOPATH=$HOME/xxxxx
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin
export PATH=$PATH:$(go env GOPATH)/bin <---- Confirm this line in you profile!!!
```

### Error under wsl when ' is included in the bin

Should use `\` to escape the `' in the bin. related issue: [#305](https://github.com/air-verse/air/issues/305)

### Question: how to do hot compile only and do not run anything?

[#365](https://github.com/air-verse/air/issues/365)

```toml
[build]
  cmd = "/usr/bin/true"
```

### How to Reload the Browser Automatically on Static File Changes

Refer to issue [#512](https://github.com/air-verse/air/issues/512) for additional details.

- Ensure your static files in `include_dir`, `include_ext`, or `include_file`.
- Ensure your HTML has a `</body>` tag
- Activate the proxy by configuring the following config:

```toml
[proxy]
  enabled = true
  proxy_port = <air proxy port>
  app_port = <your server port>
```

## Development

Please note that it requires Go 1.16+ since I use `go mod` to manage dependencies.

```shell
# Fork this project

# Clone it
mkdir -p $GOPATH/src/github.com/cosmtrek
cd $GOPATH/src/github.com/cosmtrek
git clone git@github.com:<YOUR USERNAME>/air.git

# Install dependencies
cd air
make ci

# Explore it and happy hacking!
make install
```

Pull requests are welcome.

### Release

```shell
# Checkout to master
git checkout master

# Add the version that needs to be released
git tag v1.xx.x

# Push to remote
git push origin v1.xx.x

# The CI will process and release a new version. Wait about 5 min, and you can fetch the latest version
```

## Star History

[![Star History Chart](https://api.star-history.com/svg?repos=air-verse/air&type=Date)](https://star-history.com/#air-verse/air&Date)

## Sponsor

[![Buy Me A Coffee](https://cdn.buymeacoffee.com/buttons/default-orange.png)](https://www.buymeacoffee.com/cosmtrek)

Give huge thanks to lots of supporters. I've always been remembering your kindness.

## License

[GNU General Public License v3.0](LICENSE)


Simple application watcher for multiple programming languages.

# Anko
> Simple Application watcher

[![Mentioned in Awesome Go](https://awesome.re/mentioned-badge.svg)](https://github.com/avelino/awesome-go) ![GitHub](https://img.shields.io/badge/golang%20->=1.15.x-blue.svg) [![License: Apache-2.0](https://img.shields.io/badge/License-Apache%202.0-yellow)](https://img.shields.io/badge/License-Apache%202.0-yellow) [![Go Report Card](https://goreportcard.com/badge/github.com/GuilhermeCaruso/anko)](https://goreportcard.com/report/github.com/GuilhermeCaruso/anko) [![Build Status](https://travis-ci.com/GuilhermeCaruso/anko.svg?branch=main)](https://travis-ci.com/GuilhermeCaruso/anko) [![codecov](https://codecov.io/gh/GuilhermeCaruso/anko/branch/main/graph/badge.svg?token=FROE5RSLOY)](https://codecov.io/gh/GuilhermeCaruso/anko)

<p >
  <img src=".github/assets/anko_logo.png" width=200>
</p>

The Anko project aims to be a command line used to watch files of different extensions, executing actions previously configured, such as, restart, deletion, execution of scripts, among others.

The project so far has the following functionalities:

- Definition of execution language. [List of implemented languages](#implemented-languages-and-commands)
- Declaration of extensions and files for watching.
- Independent configuration file

# Summary

- [Install](#install)
- [Guide](#guide)
  - [Anko File](#anko-file)
- [Example](#example)
- [Implemented Languages and Commands](#implemented-languages-and-commands)
- [OS compatibility](#os-compatibility)
- [To do](#to-do)
- [Author](#author)
- [License](#license)


# Install

### **If you have golang installed**

- To get Anko CLI

```sh
go get -u github.com/GuilhermeCaruso/anko
```

- If you prefer to create your own build using the flags you want, just clone this repository and run the golang build command

```sh
git clone git@github.com:GuilhermeCaruso/anko.git && \
cd anko && \
go <your_flags_here> build  
```

Once with the binary, remember to add it to the system PATH

> If you still don't know how to do it, [read here](https://superuser.com/questions/284342/what-are-path-and-other-environment-variables-and-how-can-i-set-or-use-them)!


### **If you don't have golang isntalled**

Soon we will make available the download the binaries...


# Guide

The anko project was initially developed to observe changes in golang projects and reload it on demand. During development, we noticed that the project could be used for the most diverse languages ​​and technologies (With the help of the community), because of that, it was necessary to add a configuration file, the Anko file

## Anko File

- **Localization**

The Anko file is a `.yaml` file written, preferably, at the root of the project you want to observe, but nothing prevents you from saving it wherever you want.

- **Nomenclature**

The project was developed to avoid as much as possible that the user has to adapt the project to suit him, however, the file name is the only information that must be kept as a standard.

The configuration file name must always be: `anko.yaml`

- **Properties**

> Root

| key | type | description |
|-|-|-|
|`application`| Application | Base of the anko file

> Application

|key |type| description|
|-|-|-|
|`root_path`| string | Path to the directory to be observed
|`exec_ath`| string | Path to application entry point
|`language`| string | Execution language. Check [here](#implemented-languages-and-commands) if your favorite language has already been implemented
|`watch`| Watch | List of files and extensions to be observed. Initially only update events

> Watch

|key |type| description|
|-|-|-|
|`extensions`| []string | List of extensions that must be observed
|`files`| []string | List of files that must be observed


# Example

Below is a simple example of the `anko.yaml` file

> anko.yaml

```yaml
application:
  root_path: "."
  exec_path: "path/to/main.go"
  language: go
  watch:
    extensions: 
      - go
      - env
    files:
      - go.mod
```

Once you have the Anko cli set up, just run the command in the folder containing the `anko.yaml` file.

```sh
anko
```

The initial output should be:

```
> Starting Anko! 
> Configuring watcher. 
> Listening for changes... 
```

# Implemented languages and Commands

The implemented languages and commands ​​allow the angel project to be able to execute the most diverse projects independently and performatively.

Throughout the development and with the help of the community, several languages ​​will be implemented and listed below.


| Command or languages | Anko name | Status |
| - | - | - |
| GO | go | [example](https://github.com/GuilhermeCaruso/anko/tree/main/example/golang)
| NodeJs | node |[example](https://github.com/GuilhermeCaruso/anko/tree/main/example/nodejs)

# OS compatibility

Throughout the development of the project, with its respective versions and builds, compatibility with the most diverse operating systems is validated to ensure that everything is ok.

As it is a project in its initial phase, not all operating systems are being compatible with it, however, with the help of the community and the commitment of the team involved, we hope to mitigate this problem in an agile manner.

Below are listed in a macro manner the tested operating systems and their respective status

| OS | Status |
| - | - |
| Debian | `compatible`
| macOS Big Sur | `compatible`
| Windows 10 | `incompatible`


# To do
- [ ] Add more elaborate commands to the command line
  - [ ] Init
  - [ ] Test
  - [ ] Update
  - [ ] Run
- [ ] Create website for project documentation and news
- [ ] Add OS compatibility
  - [ ] Windows 10
  - [ ] Arch
  - [ ] Fedora
- [ ] Improve the implementation of new languages
- [ ] Add languages or commands compatibility
  - [ ] Makefile
  - [ ] Shellscript
  - [ ] Rust
  - [ ] Lua
  - [ ] Yarn
  - [ ] Npm


# Author

Guilherme Caruso 
- [@GuilhermeCaruso](https://github.com/GuilhermeCaruso) on Github
- [@guicaruso_](https://twitter.com/guicaruso_) on Twitter
- [@guicaruso_](https://instagram.com/guicaruso_) on Instagram

# License

Apache 2.0 licensed. See the LICENSE file for details.


anko

Builds and restarts a Go project when it crashes or some watched file changes.

<p align="center">
  <img width="200px" src="https://raw.githubusercontent.com/maxcnunes/gaper/master/gopher-gaper.png">
  <h3 align="center">gaper</h3>
  <p align="center">
   Used to build and restart a Go project when it crashes or some watched file changes
   <br />
   <b>Aimed to be used in development only.</b>
  </p>
</p>

---

[![Software License](https://img.shields.io/badge/license-MIT-brightgreen.svg?style=flat-square)](LICENSE.md)
[![Linux - Build Status](https://travis-ci.org/maxcnunes/gaper.svg?branch=master)](https://travis-ci.org/maxcnunes/gaper)
[![Windows - Build status](https://ci.appveyor.com/api/projects/status/e0g00kmxwv44?svg=true)](https://ci.appveyor.com/project/maxcnunes/gaper)
[![Coverage Status](https://codecov.io/gh/maxcnunes/gaper/branch/master/graph/badge.svg)](https://codecov.io/gh/maxcnunes/gaper)
[![Go Doc](https://img.shields.io/badge/godoc-reference-blue.svg?style=flat-square)](http://godoc.org/github.com/maxcnunes/gaper)
[![Go Report Card](https://goreportcard.com/badge/github.com/maxcnunes/gaper)](https://goreportcard.com/report/github.com/maxcnunes/gaper)
[![Powered By: GoReleaser](https://img.shields.io/badge/powered%20by-goreleaser-green.svg?style=flat-square)](https://github.com/goreleaser)

## Changelog

See [Releases](https://github.com/maxcnunes/gaper/releases) for detailed history changes.

## Installation

Using go tooling:

```
go get -u github.com/maxcnunes/gaper/cmd/gaper
```

Or, downloading the binary instead (example for version 1.1.0, make sure you are using the latest version though):

```
curl -SL https://github.com/maxcnunes/gaper/releases/download/v1.1.0/gaper_1.1.0_linux_amd64.tar.gz | tar -xvzf - -C "${GOPATH}/bin"
```

## Usage

```
NAME:
   gaper - Used to build and restart a Go project when it crashes or some watched file changes

USAGE:
   gaper [global options] command [command options] [arguments...]

VERSION:
   version

COMMANDS:
     help, h  Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --bin-name value                 name for the binary built by gaper for the executed program (default current directory name)
   --build-path value               path to the program source code (default: ".")
   --build-args value               arguments used on building the program
   --program-args value             arguments used on executing the program
   --verbose                        turns on the verbose messages from gaper
   --disable-default-ignore         turns off default ignore for hidden files and folders, "*_test.go" files, and vendor folder
   --watch value, -w value          list of folders or files to watch for changes
   --ignore value, -i value         list of folders or files to ignore for changes
   --poll-interval value, -p value  how often in milliseconds to poll watched files for changes (default: 500)
   --extensions value, -e value     extensions to watch for changes (default: "go")
   --no-restart-on value, -n value  don't automatically restart the supervised program if it ends:
                                      if "error", an exit code of 0 will still restart.
                                      if "exit", no restart regardless of exit code.
                                      if "success", no restart only if exit code is 0.
   --help, -h                       show help
   --version, -v                    print the version
```

### Watch and Ignore paths

For those options Gaper supports static paths (e.g. `build/`, `seed.go`) or glob paths (e.g. `migrations/**/up.go`, `*_test.go`).

On using a path to a directory please add a `/` at the end (e.g. `build/`) to make sure Gaper won't include other matches that starts with that same value (e.g. `build/`, `build_settings.go`).

### Default ignore settings

Since in most projects there is no need to watch changes for:

* hidden files and folders
* test files (`*_test.go`)
* vendor folder

Gaper by default ignores those cases already. Although, if you need Gaper to watch those files anyway it is possible to disable this setting with `--disable-default-ignore` argument.

### Watch method

Currently Gaper uses polling to watch file changes. We have plans to [support fs events](https://github.com/maxcnunes/gaper/issues/12) though in a near future.

### Examples

Using all defaults provided by Gaper:

```
gaper
```

Example providing a few custom configurations:

```
gaper \
    --bin-name build/api-dev \
    --build-path cmd/server \
    --build-args "-ldflags=\"-X 'main.Version=dev'" \
    -w 'public/**' -w '*.go' \
    -e js -e css -e html \
    --ignore './**/*_mock.go' \
    --program-args "-arg1 ok -arg2=nope" \
    --watch .
```

## Contributing

See the [Contributing guide](/CONTRIBUTING.md) for steps on how to contribute to this project.

## Reference

This package was heavily inspired by [gin](https://github.com/codegangsta/gin) and [node-supervisor](https://github.com/petruisfan/node-supervisor).

Basically, Gaper is a mixing of those projects above. It started from **gin** code base and I rewrote it aiming to get
something similar to **node-supervisor** (but simpler). A big thanks for those projects and for the people behind it!
:clap::clap:

### How is Gaper different of Gin

The main difference is that Gaper removes a layer of complexity from Gin which has a proxy running on top of 
the executed server. It allows to postpone a build and reload the server when the first call hits it. With Gaper 
we don't care about that feature, it just restarts your server whenever a change is made.


gaper

[Gradle](https://docs.gradle.org/)/[Maven](https://maven.apache.org/) like build tool for Go projects.

<p align="center">
Golang Project Boot
  <br/>
  <br/>
  <a href="https://github.com/kcmvp/gob/blob/main/LICENSE">
    <img alt="GitHub" src="https://img.shields.io/github/license/kcmvp/gob"/>
  </a>
  <a href="https://goreportcard.com/report/github.com/kcmvp/gob">
    <img src="https://goreportcard.com/badge/github.com/kcmvp/gob"/>
  </a>
  <a href="https://pkg.go.dev/github.com/kcmvp/gob">
    <img src="https://pkg.go.dev/badge/github.com/kcmvp/gob.svg" alt="Go Reference"/>
  </a>
  <a href="https://github.com/kcmvp/gob/blob/main/.github/workflows/workflow.yml" rel="nofollow">
     <img src="https://img.shields.io/github/actions/workflow/status/kcmvp/gob/workflow.yml?branch=main" alt="Build" />
  </a>
  <a href="https://app.codecov.io/gh/kcmvp/gob" ref="nofollow">
    <img src ="https://img.shields.io/codecov/c/github/kcmvp/gob" alt="coverage"/>
  </a>

</p>

<span id="nav-1"></span>

<span id="nav-2"></span>

## Introduction

Although the Golang programming ecosystem is becoming more and more mature,
these tools and frameworks exist independently to solve specific problems.
Whenever a new Golang project is started, it requires a series of initialization;
What’s worse is that whenever your switch the development environment, same process have to be repeated!
This project is built to solve this problem by providing a tool named *gbc**, which is similar to [Maven](https://maven.apache.org/)
or [Gradle](https://gradle.com/) in the **Java** ecosystem together with a framework(glue) similar to [SpringBoot](https://spring.io/projects/spring-boot). Please refer [documents](#commands) for details

<span id="nav-3"></span>

## Features

1. Everything is a plugin, you can use any tool you like as a plugin to customize your build process!
2. Model driver SQL database DAO(data access object).
3. IoC Container support via [samber/do](https://github.com/samber/do).
4. Code generation for most popular frameworks scaffolding.
5. Environment sensitive profile. **application.yml** for no-test environment and **application-test.yml** for test environment
6. Friendly help messages
7. More ....

## What's a gob based project looks like?
Just like[SpringBoot](https://spring.io/projects/spring-boot), the most important part of a gob project is the **configurations** which define your project.
There are **two** main configurations
1. **gob.yaml** : it acts as the same as **settings.gradle.kts**( [Gradle](https://gradle.com/)) or **pom.xml**([Maven](https://maven.apache.org/)), you can define any thrid party tool as a plugin in this file.
2. **application.yaml**: it acts as the same **application.yaml** of [SpringBoot](https://spring.io/projects/spring-boot)


## Quick Start
1. Install `gbc` with below command
```shell
    go install github.com/kcmvp/gob/cmd/gbc@latest
```
2. Initialize project with below command(in the project home directory)
```shell
  gbc init
```

| Git Hooks                                                                                        | Dependency Tree                                                                                      |
|--------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------|
| <img src="https://github.com/kcmvp/gob/blob/main/docs/commit_hook.gif" height="245" width="400"> | <img src="https://github.com/kcmvp/gob/blob/main/docs/dependency_tree.png" height="245" width="300"> |



## How gbc works
`gbc` takes everything defined in the `gob.yaml` as plugin.
```mermaid
flowchart TD
        gbc --> gob.yaml 
        gob.yaml --> plugin1
        gob.yaml --> plugin2
        gob.yaml --> plugin3
```
You just need to tell `gbc` 3W(where,when and what)
1. **Where** : where to download the tool
2. **When** : when to execute to command
2. **What** : what to do with the tool


## Commands 

Build Commands
- [gbc init](#gbc-init)
- [gbc build](#gbc-build)
- [gbc clean](#gbc-clean)
- [gbc test](#gbc-test)
- [gbc lint](#gbc-lint)
- [gbc deps](#gbc-deps)

Plugin Commands
- [gbc plugin install](#gbc-plugin-install)
- [gbc plugin list](#gbc-plugin-list)
 
Setup Commands
- [gbc setup version](#gbc-setup-version)

### gbc init
```shell
gbc init
```
Initialize gbc for the project, it will do following initializations 
1. generate file `gob.yaml`
2. generate file `.golangci.yaml`, which is the configuration for [golangci-lint](https://github.com/golangci/golangci-lint)
3. setup `git hooks`(if project in the source control.)  
   1. commit-msg 
   2. pre-commit 
   3. pre-push

> This command can be executed at any time. 

Content of `gob.yaml`

```yaml
exec:
    commit-msg-hook: ^#[0-9]+:\s*.{10,}$
    pre-commit-hook:
        - lint
        - test
    pre-push-hook:
        - test
plugins:
    golangci-lint:
        alias: lint #When : when issue `gbc lint`
        args: run ./... #What: execute `golangci-lint run ./...`
        url: github.com/golangci/golangci-lint/cmd/golangci-lint@v1.55.2 #Where: where to download the plugin
    gotestsum:
        alias: test
        args: --format testname -- -coverprofile=target/cover.out ./...
        url: gotest.tools/gotestsum@v1.11.0
```
in most cases you don't need to edit the configuration manually. you can achieve this by [plugin commands](#gbc-plugin-install) 

### gbc build
```shell
gbc build
```
This command would build all the candidate binaries(main methods in main packages) to the `target` folder.
1. Final binary name is same as go source file name which contains `main method`
2. Would fail if there are same name go main source file

### gbc clean
```shell
gbc clean
```
This command would clean `target` folder

### gbc test
```shell
gbc test
```
This command would run all tests for the project and generate coverage report at `target/cover.html`

### gbc lint
```shell
gbc lint
```
Run `golangci-lint` against project based on the configuration, a report named `target/lint.log` will be generated if there are any violations
### gbc deps
```shell
gbc deps
```
List project dependencies tree and indicate there are updates for a specific dependency
### gbc plugin install
```shell
gbc plugin install github.com/golangci/golangci-lint/cmd/golangci-lint@v1.55.2 lint run ./...
```
It is an advanced version of `go install`, which supports multi-version.(eg:`golangci-lint-v1.55.2`, `golangci-lint-v1.55.1`)
1. Install the versioned tool(just the same as `go install`)
2. Set up the tool as plugin in `gob.yaml`
3. You can update adjust the parameters of the plugin by editing  `gob.yaml`
 
### gob plugin list

```shell
gob plugin list
```
List all the installed plugins

### gob setup version
```shell
gob setup version
```
This command will generate file `version.go` in `infra` folder, and project version information
will be injected into `buildVersion` when build the project with command `gob build`
```go
// buildVersion don't change this
var buildVersion string
```

## FAQ

- [When install a plugin, how to find out the url?](#)
 
   `gob plugin install` work the same way as `go install`, it take the same url as `go install`.
 

- [How to upgrade a plugin ?](#)
 
   Just simply edit `gob.yaml` file and update the version you want. 
    ```yaml
   plugins:
      golangci-lint:
      alias: lint
      args: run ./...
      url: github.com/golangci/golangci-lint/cmd/golangci-lint@v1.55.2
   ```
`



# goyek

> Task automation in Go

[![Go Reference](https://pkg.go.dev/badge/github.com/goyek/goyek.svg)](https://pkg.go.dev/github.com/goyek/goyek/v2)
[![Keep a Changelog](https://img.shields.io/badge/changelog-Keep%20a%20Changelog-%23E05735)](CHANGELOG.md)
[![GitHub Release](https://img.shields.io/github/v/release/goyek/goyek)](https://github.com/goyek/goyek/releases)
[![go.mod](https://img.shields.io/github/go-mod/go-version/goyek/goyek)](go.mod)

[![Build Status](https://img.shields.io/github/actions/workflow/status/goyek/goyek/build.yml?branch=main)](https://github.com/goyek/goyek/actions?query=workflow%3Abuild+branch%3Amain)
[![Go Report Card](https://goreportcard.com/badge/github.com/goyek/goyek)](https://goreportcard.com/report/github.com/goyek/goyek)
[![codecov](https://codecov.io/gh/goyek/goyek/branch/main/graph/badge.svg)](https://codecov.io/gh/goyek/goyek)
[![Mentioned in Awesome Go](https://awesome.re/mentioned-badge.svg)](https://github.com/avelino/awesome-go)

Please ⭐ `Star` this repository if you find it valuable and worth maintaining.

[![Introduction](https://img.youtube.com/vi/e-xWEH-fqJ0/hqdefault.jpg)](https://www.youtube.com/watch?v=e-xWEH-fqJ0)

[Slides](https://docs.google.com/presentation/d/1xFAPXeMiOD-92xeIHkUD-SHmJZwc8mSIIgpjuJXEW3U/edit?usp=sharing).

---

Table of Contents:

- [Description](#description)
- [Quick start](#quick-start)
- [Repository template](#repository-template)
- [Examples](#examples)
- [Defining tasks](#defining-tasks)
- [Running programs](#running-programs)
- [Wrapper scripts](#wrapper-scripts)
- [Using middlewares](#using-middlewares)
- [Customizing](#customizing)
- [Alternatives](#alternatives)
  - [Make](#make)
  - [Mage](#mage)
  - [Task](#task)
  - [Bazel](#bazel)
- [Contributing](#contributing)
- [License](#license)

## Description

**goyek** (/ˈɡɔɪæk/ [🔊 listen](http://ipa-reader.xyz/?text=%CB%88%C9%A1%C9%94%C9%AA%C3%A6k))
is a task automation tool.
As opposed to many other tools, it is just a Go library
with API inspired by
[`testing`](https://golang.org/pkg/testing),
[`cobra`](https://github.com/spf13/cobra),
[`flag`](https://golang.org/pkg/flag),
[`http`](https://golang.org/pkg/http)
packages.

Here are some good parts:

- It is cross-platform and shell independent.
- No binary installation is needed.
- It is easy to debug, like a regular Go application.
- The tasks are defined similarly to
  [`cobra`](https://github.com/spf13/cobra) commands.
- The task actions look like a Go unit test.
  You may even use [`testify`](https://github.com/stretchr/testify)
  or [`fluentassert`](https://github.com/fluentassert/verify) for asserting.
- You can reuse code like in any Go application.
  It may be helpful to use packages like
  [`fsnotify`](https://github.com/fsnotify/fsnotify) and [`viper`](https://github.com/spf13/viper).
- It is highly customizable.
- It does not use any third-party dependency other than the Go standard library.
  You can find supplumental features in [`goyek/x`](https://github.com/goyek/x).
- Minimal supported Go version is 1.13.

## Quick start

> Supplemental packages from [`github.com/goyek/x`](https://pkg.go.dev/github.com/goyek/x)
> are used for convinence.

The convention is to have the build automation
in the `/build` directory (or even Go module).

Put the following content in `/build/hello.go`:

```go
package main

import (
	"flag"

	"github.com/goyek/goyek/v2"
	"github.com/goyek/x/cmd"
)

var msg = flag.String("msg", "greeting message", "Hello world!")

var hello = flow.Define(goyek.Task{
	Name:  "hello",
	Usage: "demonstration",
	Action: func(a *goyek.A) {
		a.Log(*msg)
		cmd.Exec(a, "go version")
	},
})
```

Put the following content in `/build/main.go`:

```go
package main

import (
	"github.com/goyek/goyek/v2"
	"github.com/goyek/x/boot"
)

func main() {
	goyek.SetDefault(hello)
	boot.Main()
}
```

Run:

```out
$ go mod tidy

$ go run ./build -h
Usage of build: [flags] [--] [tasks]
Tasks:
  hello  demonstration
Flags:
  -dry-run
        print all tasks without executing actions
  -long-run duration
        print when a task takes longer (default 1m0s)
  -msg string
        Hello world! (default "greeting message")
  -no-color
        disable colorizing output
  -no-deps
        do not process dependencies
  -skip comma-separated tasks
        skip processing the comma-separated tasks
  -v    print all tasks as they are run

$ go run ./build -v
===== TASK  hello
      hello.go:16: greeting message
      hello.go:17: Exec: go version
go version go1.19.3 windows/amd64
----- PASS: hello (0.12s)
ok      0.123s
```

## Repository template

You can use [goyek/template](https://github.com/goyek/template)
to create a new repository.

For an existing repository you can copy most of its files.

## Examples

- [example_test.go](example_test.go) -
  demonstrative examples
- [goyek/template](https://github.com/goyek/template) -
  Go application repository template
- [fluentassert](https://github.com/fluentassert/verify) -
  Go library
- [build](build) -
  dogfooding
- [splunk-otel-go](https://github.com/signalfx/splunk-otel-go/tree/main/build) -
  multi-module repository
- [goyek/demo](https://github.com/goyek/demo)
  and [goyek/workflow](https://github.com/goyek/workflow) -
  demonstratation of the reusability potential

## Defining tasks

Use [`Define`](https://pkg.go.dev/github.com/goyek/goyek/v2#Define)
to register a a task.

You can add dependencies to already defineded tasks using
[`Task.Deps`](https://pkg.go.dev/github.com/goyek/goyek/v2#Task.Deps).
The dependencies are running in sequential order.
Each task runs at most once.

The [`Task.Action`](https://pkg.go.dev/github.com/goyek/goyek/v2#Task.Action)
is a function which executes when a task is running.
A task can have only dependencies and no action to act as a pipeline.

The [`Task.Parallel`](https://pkg.go.dev/github.com/goyek/goyek/v2#Task.Parallel)
can be set to allow a task to be run in parallel with other parallel tasks.

A default task can be assigned using [`SetDefault`](https://pkg.go.dev/github.com/goyek/goyek/v2#SetDefault).

## Running programs

You can use the [`cmd.Exec`](https://pkg.go.dev/github.com/goyek/x/cmd#Exec)
convenient function from [goyek/x](https://github.com/goyek/x)
that should cover most use cases.

Alternatively, you may prefer create your own helpers
like `Exec` in [build/exec.go](build/exec.go).

[#60](https://github.com/goyek/goyek/issues/60) and [#307](https://github.com/goyek/goyek/issues/307)
explain why this feature is not out-of-the-box.

## Wrapper scripts

Instead of executing `go run ./build`,
you may create wrapper scripts,
which you can invoke from any location.

Bash - `goyek.sh`:

```bash
#!/bin/bash
set -euo pipefail

DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null && pwd )"
cd "$DIR"
go run ./build "$@"
```

PowerShell - `goyek.ps1`:

```powershell
& go run .\build $args
exit $global:LASTEXITCODE
```

If `/build` is a separate Go module,
check the [goyek.sh](goyek.sh) and [goyek.ps1](goyek.ps1) scripts.

## Using middlewares

Call the [`Use`](https://pkg.go.dev/github.com/goyek/goyek/v2#Use) function
or [`UseExecutor`](https://pkg.go.dev/github.com/goyek/goyek/v2#UseExecutor)
to setup a task runner or flow executor interceptor (middleware).

You can use a middleware, for example to:
generate a task execution report,
add retry logic,
export task execution telemetry, etc.

You can use some reusable middlewares from the
[`middleware`](https://pkg.go.dev/github.com/goyek/goyek/v2/middleware)
package. [`ReportStatus`](https://pkg.go.dev/github.com/goyek/goyek/v2/middleware#ReportStatus)
is the most commonly used middleware.

Notice that the [`boot.Main`](https://pkg.go.dev/github.com/goyek/x/boot#Main)
convenient function from [goyek/x](https://github.com/goyek/x)
sets the most commonly used middlewares and defines flags to configure them.

## Customizing

You can customize the default output by using:

- [`SetOutput`](https://pkg.go.dev/github.com/goyek/goyek/v2#SetOutput)
- [`SetLogger`](https://pkg.go.dev/github.com/goyek/goyek/v2#SetLogger)
- [`SetUsage`](https://pkg.go.dev/github.com/goyek/goyek/v2#SetUsage)
- [`Execute`](https://pkg.go.dev/github.com/goyek/goyek/v2#Execute)
  (instead of [`Main`](https://pkg.go.dev/github.com/goyek/goyek/v2#Main))

You can also study how [github.com/goyek/x](https://github.com/goyek/x)
is customizing the default behavior.

## Alternatives

### Make

While [Make (Makefile)](https://www.gnu.org/software/make/) is currently
the _de facto_ standard, it has some pitfalls:

- Requires to learn Make (and often Bash).
- It is hard to develop a Makefile which is truly cross-platform.
- Debugging and testing Make targets is not fun.

**goyek** is intended to be simpler, easier to learn,
more portable, while still being able to handle most use cases.

### Mage

[Mage](https://github.com/magefile/mage) is a framework/tool which magically discovers
the [targets](https://magefile.org/targets/) from [magefiles](https://magefile.org/magefiles/),
which results in some drawbacks.

- It requires using [build tags](https://magefile.org/magefiles/).
- Reusing tasks is [hacky](https://magefile.org/importing/).
- It needs installation or use of [zero install option](https://magefile.org/zeroinstall/),
  which is slow.
- Debugging is [complex](https://github.com/magefile/mage/issues/280).
- It is magical by design (of course, one may like it).

**goyek** is a non-magical alternative for [Mage](https://github.com/magefile/mage).
It is easier to customize and extend as it is a library that offers extension points.
Write regular Go code without build tags and tricky imports.

### Task

While [Task](https://taskfile.dev/) is simpler and easier to use
than [Make](https://www.gnu.org/software/make/),
but it still has similar problems:

- Requires to learn Task's YAML structure and
  the [minimalistic, cross-platform interpreter](https://github.com/mvdan/sh#gosh).
- Debugging and testing tasks is not easy.
- Hard to make reusable tasks.
- Requires to install the tool.

### Bazel

[Bazel](https://bazel.build/) is a very sophisticated tool which is
[created to efficiently handle complex and long-running build pipelines](https://en.wikipedia.org/wiki/Bazel_(software)#Rationale).
It requires the build target inputs and outputs to be fully specified.

**goyek** is just a simple Go library.
However, nothing prevents you from, for example,
using the [github.com/magefile/mage/target](https://pkg.go.dev/github.com/magefile/mage/target)
package to make your automation more efficient.

## Contributing

See [CONTRIBUTING.md](CONTRIBUTING.md) if you want to help us.

## License

**goyek** is licensed under the terms of the [MIT license](LICENSE).

Note: **goyek** was named **taskflow** before v0.3.0.


goyek

Mage is a make/rake-like build tool using Go.

[![Built with Mage](https://magefile.org/badge.svg)](https://magefile.org)
[![Build Status](https://travis-ci.org/magefile/mage.svg?branch=master)](https://travis-ci.org/magefile/mage) [![Build status](https://ci.appveyor.com/api/projects/status/n6h146y79xgxkidl/branch/master?svg=true)](https://ci.appveyor.com/project/natefinch/mage/branch/master)

<p align="center"><img src="https://user-images.githubusercontent.com/3185864/32058716-5ee9b512-ba38-11e7-978a-287eb2a62743.png"/></p>

## About

Mage is a make-like build tool using Go.  You write plain-old go functions,
and Mage automatically uses them as Makefile-like runnable targets.

## Installation

Mage has no dependencies outside the Go standard library, and builds with Go 1.7
and above (possibly even lower versions, but they're not regularly tested).

**Using GOPATH**

```
go get -u -d github.com/magefile/mage
cd $GOPATH/src/github.com/magefile/mage
go run bootstrap.go
```

**Using Go Modules**

```
git clone https://github.com/magefile/mage
cd mage
go run bootstrap.go
```

This will download the code and then run the bootstrap script to build mage with
version infomation embedded in it.  A normal `go get` (without -d) or `go
install` will build the binary correctly, but no version info will be embedded.
If you've done this, no worries, just go to `$GOPATH/src/github.com/magefile/mage`
and run `mage install` or `go run bootstrap.go` and a new binary will be created
with the correct version information.

The mage binary will be created in your $GOPATH/bin directory.

You may also install a binary release from our
[releases](https://github.com/magefile/mage/releases) page.

## Demo

[![Mage Demo](https://img.youtube.com/vi/GOqbD0lF-iA/maxresdefault.jpg)](https://www.youtube.com/watch?v=GOqbD0lF-iA)

## Discussion

Join the `#mage` channel on [gophers slack](https://gophers.slack.com/messages/general/)
or post on the [magefile google group](https://groups.google.com/forum/#!forum/magefile)
for discussion of usage, development, etc.

# Documentation

See [magefile.org](https://magefile.org) for full documentation.

See [pkg.go.dev/github.com/magefile/mage/mage](https://pkg.go.dev/github.com/magefile/mage/mage)
for instructions on how to use Mage as a library.

# Why?

Makefiles are hard to read and hard to write.  Mostly because makefiles are
essentially fancy bash scripts with significant white space and additional
make-related syntax.

Mage lets you have multiple magefiles, name your magefiles whatever you want,
and they're easy to customize for multiple operating systems.  Mage has no
dependencies (aside from go) and runs just fine on all major operating systems,
whereas make generally uses bash which is not well supported on Windows. Go is
superior to bash for any non-trivial task involving branching, looping, anything
that's not just straight line execution of commands.  And if your project is
written in Go, why introduce another language as idiosyncratic as bash?  Why not
use the language your contributors are already comfortable with?

# Thanks

If you use mage and like it, or any of my other software, and you'd like to show your appreciation, you can do so on my patreon:

[<img src=https://user-images.githubusercontent.com/3185864/49846051-64eddf80-fd97-11e8-9f59-d09f5652d214.png>](https://www.patreon.com/join/natefinch?)



mage

# Modern Make

## About

Mmake is a small program which wraps `make` to provide additional functionality, such as user-friendly help output, remote includes,
and eventually more. It otherwise acts as a pass-through to standard make.

## Installation

Via [gobinaries.com](https://gobinaries.com):

```sh
$ curl -sf https://gobinaries.com/tj/mmake/cmd/mmake | sudo sh
```

Build from source:
```
$ go get github.com/tj/mmake/cmd/mmake
```

Homebrew:
```
$ brew tap tj/mmake https://github.com/tj/mmake.git
$ brew install tj/mmake/mmake
```

Next add the following alias to your profile:

```
alias make=mmake
```

## Features

### Help output

Make's primary function is not to serve as a "task runner", however it's often used for that scenario due to its ubiquitous nature, and if you're already using it, why not! Make is however lacking a built-in mechanism for displaying help information.

Here's an example Makefile:

```Makefile
# Start the dev server.
#
# Note that the API server must
# also be running.
start:
	@gopherjs -m -v serve --http :3000 github.com/tj/docs/client
.PHONY: start

# Start the API server.
api:
	@go run server/cmd/api/api.go
.PHONY: api

# Display dependency graph.
deps:
	@godepgraph github.com/tj/docs/client | dot -Tsvg | browser
.PHONY: deps

# Display size of dependencies.
#- Any comment preceded by a dash is omitted.
size:
	@gopherjs build client/*.go -m -o /tmp/out.js
	@du -h /tmp/out.js
	@gopher-count /tmp/out.js | sort -nr
.PHONY: size

```

Mmake provides a `help` command to display all target comments in short form:

```
$ alias make=mmake
$ make help

  start      Start the dev server.
  api        Start the API server.
  deps       Display dependency graph.
  size       Display size of dependencies.

```

You can optionally filter which commands to view the help dialogue for (this supports [standard Unix glob patterns](https://en.wikipedia.org/wiki/Glob_(programming)#Syntax)):

```
$ make help start

  start   Start the dev server.

$ make help s*

  size    Display size of dependencies.
  start   Start the dev server.

```

The `help` command also supports displaying longer output with the verbose flag (`-v` / `--verbose`):

```
$ make help -v start

  Start the dev server.

  Note that the API server must
  also be running.

```

```
$ make help -v

  start:
    Start the dev server.

    Note that the API server must
    also be running.

  api:    
    Start the API server.

  deps:       
    Display dependency graph.

  size:
    Display size of dependencies.
    
```

The default behaviour of Make is of course preserved:

```
$ make
serving at http://localhost:3000 and on port 3000 of any available addresses

$ make size
...
```

### Remote includes

Includes may specify a URL (http, https, or github shortcut) for inclusion, which are automatically downloaded to `/usr/local/include` and become available to Make. Note that make resolves includes to this directory by default, so the Makefile will still work for regular users.

Includes are resolved recursively. For example you may have a standard set of includes for your team to run tests, lint, and deploy:

```Makefile
include github.com/apex/make/deploy
include github.com/apex/make/lint
include github.com/apex/make/test
include https://github.com/apex/make/test/Makefile
include https://github.com/apex/make/test/make.mk
```

This can be a lot to remember, so you could also provide a file which includes the others:

```Makefile
include github.com/apex/make/all
```

If the given repository contains an `index.mk` file, you can just declare:

```Makefile
include github.com/apex/make
```

Or perhaps one per dev environment such as Node or Golang:

```Makefile
include github.com/apex/make/node
include github.com/apex/make/golang
```

If you're worried about arbitrary code execution, then simply fork a project and maintain control over it.

#### Update

Once the remote includes are downloaded to `/usr/local/include`, `mmake` will not try to fetch them again. In order to get an updated copy of the remote includes, `mmake` provides an `update` target that will download them again:

```
$ make update
```

## Registry

If you're looking to find or share makefiles check out the [Wiki](https://github.com/tj/mmake/wiki/Registry), and feel free to add a category if it is missing.

## Links

- [GNU Make](https://www.gnu.org/software/make/manual/make.html) documentation
- [Wiki](https://github.com/tj/mmake/wiki/Registry) registry
- [Announcement](https://medium.com/@tjholowaychuk/modern-make-b55d53cf80d9#.q1u1knrf5) blog post
- [Introduction](https://www.youtube.com/watch?v=NLS_gbg4_wI) youtube video
- [AUR Package](https://aur.archlinux.org/packages/mmake-bin/) Arch Linux Package

## Badges

[![GoDoc](https://godoc.org/github.com/tj/mmake?status.svg)](https://godoc.org/github.com/tj/mmake)
![](https://img.shields.io/badge/license-MIT-blue.svg)
![](https://img.shields.io/badge/status-stable-green.svg)
[![](http://apex.sh/images/badge.svg)](https://apex.sh/ping/)

---

> [tjholowaychuk.com](http://tjholowaychuk.com) &nbsp;&middot;&nbsp;
> GitHub [@tj](https://github.com/tj) &nbsp;&middot;&nbsp;
> Twitter [@tjholowaychuk](https://twitter.com/tjholowaychuk)


mmake

Go build a system with file watchers and live to reload. Run, build and watch file changes with custom paths.

<p align="center">
  <img src="https://i.imgur.com/vJfIiId.png" width="125px">
</p>
<p align="center">
  <a href="https://travis-ci.org/oxequa/realize"><img src="https://img.shields.io/travis/oxequa/realize.svg?style=flat-square" alt="Build status"></a>
  <a href="https://goreportcard.com/report/github.com/oxequa/realize"><img src="https://goreportcard.com/badge/github.com/oxequa/realize?style=flat-square" alt="GoReport"></a>
  <a href="http://godoc.org/github.com/oxequa/realize"><img src="http://img.shields.io/badge/go-documentation-blue.svg?style=flat-square" alt="GoDoc"></a>
  <a href="https://raw.githubusercontent.com/oxequa/realize/master/LICENSE"><img src="https://img.shields.io/aur/license/yaourt.svg?style=flat-square" alt="License"></a>
  <a href="https://gitter.im/oxequa/realize?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge"><img src="https://img.shields.io/gitter/room/oxequa/realize.svg?style=flat-square" alt="Gitter"></a>
</p>
<hr>
<h3 align="center">#1 Golang live reload and task runner</h3>
<hr>

<p align="center">
    <img src="https://i.imgur.com/Css8pHr.png">
</p>


## Content

### - ⭐️ [Top Features](#top-features)
### - 💃🏻 [Get started](#get-started)
### - 📄 [Config sample](#config-sample)
### - 📚 [Commands List](#commands-list)
### - 🛠 [Support and Suggestions](#support-and-suggestions)
### - 😎 [Backers and Sponsors](#backers)

## Top Features

- High performance Live Reload.
- Manage multiple projects at the same time.
- Watch by custom extensions and paths.
- All Go commands supported.
- Switch between different Go builds.
- Custom env variables for project.
- Execute custom commands before and after a file changes or globally.
- Export logs and errors to an external file.
- Step-by-step project initialization.
- Redesigned panel that displays build errors, console outputs and warnings.
- Any suggestion? [Suggest an amazing feature! 🕺🏻](https://github.com/oxequa/realize/issues/new)

## Supporters
<p align="center"><br>
    <img src="https://i.imgur.com/0puJ3Ow.png" width="180px">
</p>

## Quickstart
```
go get github.com/oxequa/realize
```

## Commands List

### Run Command
From **project/projects** root execute:

    $ realize start


It will create a **.realize.yaml** file if doesn't already exist, add the working directory as project and run your workflow.

***start*** command supports the following custom parameters:

    --name="name"               -> Run by name on existing configuration
    --path="realize/server"     -> Custom Path (if not specified takes the working directory name)
    --generate                  -> Enable go generate
    --fmt                       -> Enable go fmt
    --test                      -> Enable go test
    --vet                       -> Enable go vet
    --install                   -> Enable go install
    --build                     -> Enable go build
    --run                       -> Enable go run
    --server                    -> Enable the web server
    --open                      -> Open web ui in default browser
    --no-config                 -> Ignore an existing config / skip the creation of a new one

Some examples:

    $ realize start
    $ realize start --path="mypath"
    $ realize start --name="realize" --build
    $ realize start --path="realize" --run --no-config
    $ realize start --install --test --fmt --no-config
    $ realize start --path="/Users/username/go/src/github.com/oxequa/realize-examples/coin/"

If you want, you can specify additional arguments for your project:

	✅ $ realize start --path="/print/printer" --run yourParams --yourFlags // right
    ❌ $ realize start yourParams --yourFlags --path="/print/printer" --run // wrong

⚠️ The additional arguments **must go after** the params:
<br>
💡 The ***start*** command can be used with a project from its working directory without make a config file (*--no-config*).

### Add Command
Add a project to an existing config file or create a new one.

    $ realize add
💡 ***add*** supports the same parameters as ***start*** command.
### Init Command
This command allows you to create a custom configuration step-by-step.

    $ realize init

💡 ***init*** is the only command that supports a complete customization of all supported options.
### Remove Command
Remove a project by its name

    $ realize remove --name="myname"


## Color reference
💙 BLUE: Outputs of the project.<br>
💔 RED: Errors.<br>
💜 PURPLE: Times or changed files.<br>
💚 GREEN: Successfully completed action.<br>


## Config sample

*** there is no more a .realize dir, but only a .realize.yaml file ***

For more examples check: [Realize Examples](https://github.com/oxequa/realize-examples)

    settings:
        legacy:
            force: true             // force polling watcher instead fsnotifiy
            interval: 100ms         // polling interval
        resources:                  // files names
            outputs: outputs.log
            logs: logs.log
            errors: errors.log
    server:
        status: false               // server status
        open: false                 // open browser at start
        host: localhost             // server host
        port: 5001                  // server port
    schema:
    - name: coin
      path: coin              // project path
      env:            // env variables available at startup
            test: test
            myvar: value
      commands:               // go commands supported
        vet:
            status: true
        fmt:
            status: true
            args:
            - -s
            - -w
        test:
            status: true
            method: gb test    // support different build tools
        generate:
            status: true
        install:
            status: true
        build:
            status: false
            method: gb build    // support differents build tool
            args:               // additional params for the command
            - -race
        run:
            status: true
      args:                     // arguments to pass at the project
      - --myarg
      watcher:
          paths:                 // watched paths
          - /
          ignore_paths:          // ignored paths
          - vendor
          extensions:                  // watched extensions
          - go
          - html
          scripts:
          - type: before
            command: echo before global
            global: true
            output: true
          - type: before
            command: echo before change
            output: true
          - type: after
            command: echo after change
            output: true
          - type: after
            command: echo after global
            global: true
            output: true
          errorOutputPattern: mypattern   //custom error pattern

## Support and Suggestions
💬 Chat with us [Gitter](https://gitter.im/oxequa/realize)<br>
⭐️ Suggest a new [Feature](https://github.com/oxequa/realize/issues/new)

## Backers

Support us with a monthly donation and help us continue our activities. [[Become a backer](https://opencollective.com/realize#backer)]

<a href="https://opencollective.com/realize" target="_blank"><img src="https://opencollective.com/realize/backer/0/avatar.svg"></a>
<a href="https://opencollective.com/realize" target="_blank"><img src="https://opencollective.com/realize/backer/1/avatar.svg"></a>
<a href="https://opencollective.com/realize" target="_blank"><img src="https://opencollective.com/realize/backer/2/avatar.svg"></a>
<a href="https://opencollective.com/realize" target="_blank"><img src="https://opencollective.com/realize/backer/3/avatar.svg"></a>

## Sponsors

Become a sponsor and get your logo here! [[Become a sponsor](https://opencollective.com/realize#sponsor)]


realize

<div align="center">
  <a href="https://taskfile.dev">
    <img src="website/static/img/logo.svg" width="200px" height="200px" />
  </a>

  <h1>Task</h1>

  <p>
    Task is a task runner / build tool that aims to be simpler and easier to use than, for example, <a href="https://www.gnu.org/software/make/">GNU Make<a>.
  </p>

  <p>
    <a href="https://taskfile.dev/installation/">Installation</a> | <a href="https://taskfile.dev/usage/">Documentation</a> | <a href="https://twitter.com/taskfiledev">Twitter</a> | <a href="https://fosstodon.org/@task">Mastodon</a> | <a href="https://discord.gg/6TY36E39UK">Discord</a>
  </p>
</div>


Task

<p align="center">
<img width="400" src="https://raw.githubusercontent.com/taskctl/taskctl/master/docs/logo.png" alt="taskctl - developer's routine tasks automation toolkit" title="taskctl - developer's routine tasks automation toolkit" />
</p>

# taskctl - concurrent task runner, developer's routine tasks automation toolkit
[![pkg.go.dev reference](https://img.shields.io/badge/go.dev-reference-007d9c?logo=go&logoColor=white&style=flat)](https://pkg.go.dev/github.com/taskctl/taskctl?tab=doc)
![GitHub tag (latest SemVer)](https://img.shields.io/github/v/tag/taskctl/taskctl)
![GitHub go.mod Go version](https://img.shields.io/github/go-mod/go-version/taskctl/taskctl)
![GitHub closed issues](https://img.shields.io/github/issues-closed/taskctl/taskctl)
![GitHub issues](https://img.shields.io/github/issues/taskctl/taskctl)
![Licence](https://img.shields.io/github/license/taskctl/taskctl)

![Tests](https://github.com/taskctl/taskctl/workflows/Test/badge.svg)
[![Requirements Status](https://requires.io/github/taskctl/taskctl/requirements.svg?branch=master)](https://requires.io/github/taskctl/taskctl/requirements/?branch=master)
![GitHub top language](https://img.shields.io/github/languages/top/taskctl/taskctl)
[![Go Report Card](https://goreportcard.com/badge/github.com/taskctl/taskctl)](https://goreportcard.com/report/github.com/taskctl/taskctl)
[![Test Coverage](https://codecov.io/gh/taskctl/taskctl/branch/master/graph/badge.svg)](https://codecov.io/gh/taskctl/taskctl/tree/master/pkg)
[![Maintainability](https://api.codeclimate.com/v1/badges/a99a88d28ad37a79dbf6/maintainability)](https://codeclimate.com/github/codeclimate/codeclimate/maintainability)
[![PRs Welcome](https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat)](https://github.com/taskctl/taskctl/pulls)

# Stand with Ukraine!

---
<p align="center">
   <img align="center" src="https://github.blog/wp-content/uploads/2022/03/1200x630-GitHub-1.png?resize=320%2C240">
</p>

While Russia is destroying my home and my country, killing my friends and neighbors - any russian company, organization, or citizen, who do nothing about it,
is prohibited from using this package.
For others - please, pray for us, share information about war crimes Russia is conducting in Ukraine, do everything you can
to urge your governments to be on the right side of history.
Ukraine will prevail! Good triumph over evil! Русский военный корабль, иди нах#й!

---

Simple modern alternative to GNU Make. *taskctl* is concurrent task runner that allows you to design you routine tasks and development pipelines in nice and neat way in human-readable format (YAML, JSON or TOML). 
Given a pipeline (composed of tasks or other pipelines) it builds a graph that outlines the execution plan. Each task my run concurrently or cascade.
Beside pipelines, each single task can be started manually or triggered by built-in filesystem watcher.

## Features
- human-readable configuration format (YAML, JSON or TOML)
- concurrent tasks execution
- highly customizable execution plan
- cross platform
- import local or remote configurations
- integrated file watcher (live reload)
- customizable execution contexts
- different output types
- embeddable task runner
- interactive prompt
- handy autocomplete
- and many more...

```yaml
tasks:
  lint:
    command:
      - golint $(go list ./... | grep -v /vendor/)
      - go vet $(go list ./... | grep -v /vendor/)
  
  test:
    allow_failure: true
    command: go test ./....
        
  build:
    command: go build -o bin/app ./...
    env: 
      GOOS: linux
      GOARCH: amd64
    before: rm -rf bin/*

pipelines:
  release:
    - task: lint
    - task: test
    - task: build
      depends_on: [lint, test]
```
According to this plan `lint` and `test` will run concurrently, `build` will start only when both `lint` and `test` finished.


[![asciicast](https://asciinema.org/a/326726.svg)](https://asciinema.org/a/326726)

## Contents  
- [Getting started](#getting-started)
  - [Installation](#install)
  - [Usage](#usage)
- [Configuration](#configuration)
    - [Global configuration](#global-configuration)
    - [Example](#example)
- [Tasks](#tasks)
    - [Pass CLI arguments to task](#pass-cli-arguments-to-task)
    - [Task's variations](#tasks-variations)
    - [Task's variables](#tasks-variables)
    - [Storing task's output](#storing-tasks-output) 
    - [Conditional execution](#task-conditional-execution) 
- [Pipelines](#pipelines)
- [Filesystem watchers](#filesystem-watchers)
    - [Patterns](#patterns)
- [Contexts](#contexts)
- [Output formats](#taskctl-output-formats)
- [Embeddable task runner](#embeddable-task-runner)
    - [Runner](#runner)
    - [Scheduler](#scheduler)
- [FAQ](#faq)
  - [How does it differ from go-task/task?](#how-does-it-differ-from-go-tasktask)
- [Autocomplete](#autocomplete)
- [Similar projects](#similar-projects)
- [How to contribute?](#how-to-contribute)
- [License](#license)

## Getting started
### Install
#### MacOS
```
brew tap taskctl/taskctl
brew install taskctl
```
#### Linux
```
sudo wget https://github.com/taskctl/taskctl/releases/latest/download/taskctl_linux_amd64 -O /usr/local/bin/taskctl
sudo chmod +x /usr/local/bin/taskctl
```
#### Ubuntu Linux
```
sudo snap install --classic taskctl
```

#### deb/rpm:
Download the .deb or .rpm from the [releases](https://github.com/taskctl/taskctl/releases) page and install with `dpkg -i` 
and `rpm -i` respectively.

#### Windows
```
scoop bucket add taskctl https://github.com/taskctl/scoop-taskctl.git
scoop install taskctl
```
#### Installation script
```
curl -sL https://raw.githubusercontent.com/taskctl/taskctl/master/install.sh | sh
```
#### From sources
```
git clone https://github.com/taskctl/taskctl
cd taskctl
go build -o taskctl .
```
#### Docker images
Docker images available on [Docker hub](https://hub.docker.com/repository/docker/taskctl/taskctl)

### Usage
- `taskctl` - run interactive task prompt
- `taskctl pipeline1` - run single pipeline
- `taskctl task1` - run single task
- `taskctl pipeline1 task1` - run one or more pipelines and/or tasks
- `taskctl watch watcher1 watcher2` - start one or more watchers

## Configuration
*taskctl* uses config file (`tasks.yaml` or `taskctl.yaml`) where your tasks and pipelines stored. 
Config file includes following sections:
- tasks
- pipelines
- watchers
- contexts
- variables

Config file may import other config files, directories or URLs.
```yaml
import:
- .tasks/database.yaml
- .tasks/lint/
- https://raw.githubusercontent.com/taskctl/taskctl/master/docs/example.yaml
```

### Example
Config file [example](https://github.com/taskctl/taskctl/blob/master/docs/example.yaml)

### Global configuration
*taskctl* has global configuration stored in ``$HOME/.taskctl/config.yaml`` file. It is handy to store system-wide tasks, reusable contexts, defaults etc. 

## Tasks
Task is a foundation of *taskctl*. It describes one or more commands to run, their environment, executors and attributes such as working directory, execution timeout, acceptance of failure, etc.
```yaml
tasks:
    lint:
        allow_failure: true
        command:
          - golint $(go list ./... | grep -v /vendor/)
          - go vet $(go list ./... | grep -v /vendor/)
          
    build:
        command: go build ./...
        env: 
          GOOS: linux
          GOARCH: amd64
        env_file: /data/.env
        after: rm -rf tmp/*
        variations:
          - GOARCH: amd64
          - GOARCH: arm
            GOARM: 7
```
Task definition takes following parameters:
- `command` - one or more commands to run
- `variations` - list of variations (env variables) to apply to command
- `context` - execution context's name
- `env` - environment variables. All existing environment variables will be passed automatically
- `env_file` - env file in `k=v` format to read variables from
- `dir` - working directory. Current working directory by default
- `timeout` - command execution timeout (default: none)
- `allow_failure` - if set to `true` failed commands will not interrupt execution (default: `false`)
- `after` - command that will be executed after command completes
- `before` - command that will be executed before task starts
- `exportAs` - env variable name to store task's output (default: `TASK_NAME_OUTPUT`, where `TASK_NAME` is actual task's name)
- `condition` - condition to check before running task
- `variables` - task's variables
- `interactive` - if `true` provides STDIN to commands (default: `false`)

### Tasks variables
Each task, stage and context has variables to be used to render task's fields  - `command`, `dir`.
Along with globally predefined, variables can be set in a task's definition.
You can use those variables according to `text/template` [documentation](https://golang.org/pkg/text/template/).

Predefined variables are:
- `.Root` - root config file directory
- `.Dir` - config file directory
- `.TempDir` - system's temporary directory
- `.Args` - provided arguments as a string
- `.ArgsList` - array of provided arguments
- `.Task.Name` - current task's name
- `.Context.Name` - current task's execution context's name
- `.Stage.Name` - current stage's name
- `.Output` - previous command's output
- `.Tasks.Task1.Output` - `task1` last command output

Variables can be used inside task definition. For example:
```yaml
tasks:
    task1:
        dir: "{{ .Root }}/some-dir"
        command:
          - echo "My name is {{ .Task.Name }}"
          - echo {{ .Output }} # My name is task1
          - echo "Sleep for {{ .sleep }} seconds"
          - sleep {{ .sleep | default 10 }}
          - sleep {{ .sleep }}
        variables:
          sleep: 3
```

### Pass CLI arguments to task
Any command line arguments succeeding `--` are passed to each task via `.Args`, `.ArgsList` variables or `ARGS` environment variable.

Given this definition:
```yaml
lint1:
  command: go lint {{.Args}}

lint2:
  command: go lint {{index .ArgsList 1}}
```
the resulting command is:
```
$ taskctl lint1 -- package.go
# go lint package.go

$ taskctl lint2 -- package.go main.go
# go lint main.go
```

### Storing task's output
Task output automatically stored to the variable named like this - ``.Tasks.TaskName.Output``, where `TaskName` is the actual task's name.
It is also stored to `TASK_NAME_OUTPUT` environment variable. It's name can be changed by a task's `exportAs` parameter.
Those variables will be available to all dependent stages.

### Tasks variations
Task may run in one or more variations. Variations allows to reuse task with different env variables:
```yaml
tasks:
  build:
    command:
      - GOOS=${GOOS} GOARCH=amd64 go build -o bin/taskctl_${GOOS} ./cmd/taskctl
    env:
      GOFLAGS: -ldflags=-s -ldflags=-w
    variations:
      - GOOS: linux
      - GOOS: darwin
      - GOOS: windows
```
this config will run build 3 times with different GOOS

### Task conditional execution
The following task will run only when there are any changes that are staged but not committed:
```yaml
tasks:
  build:
    command:
      - ...build...
    condition: git diff --exit-code
```

## Pipelines
Pipeline is a set of stages (tasks or other pipelines) to be executed in a certain order. Stages may be executed in parallel or one-by-one. 
Stage may override task's environment, variables etc. 

This pipeline:
```yaml
pipelines:
    pipeline1:
        - task: start task
        - task: task A
          depends_on: "start task"
        - task: task B
          depends_on: "start task"
        - task: task C
          depends_on: "start task"
        - task: task D
          depends_on: "task C"
        - task: task E
          depends_on: ["task A", "task B", "task D"]
        - task: finish
          depends_on: ["task E"]    
```
will result in an execution plan like this:
![execution plan](https://raw.githubusercontent.com/taskctl/taskctl/master/docs/pipeline.svg)

Stage definition takes following parameters:
- `name` - stage name. If not set - referenced task or pipeline name will be used.
- `task` - task to execute on this stage
- `pipeline` - pipeline to execute on this stage
- `env` - environment variables. All existing environment variables will be passed automatically
- `depends_on` - name of stage on which this stage depends on. This stage will be started only after referenced stage is completed.
- `allow_failure` - if `true` failing stage will not interrupt pipeline execution. ``false`` by default
- `condition` - condition to check before running stage
- `variables` - stage's variables

## Taskctl output formats
Taskctl has several output formats:
- `raw` - prints raw commands output
- `prefixed` - strips ANSI escape sequences where possible, prefixes command output with task's name
- `cockpit` - tasks dashboard

## Filesystem watchers
Watcher watches for changes in files selected by provided patterns and triggers task anytime an event has occurred.
```yaml
watchers:
  watcher1:
    watch: ["README.*", "pkg/**/*.go"] # Files to watch
    exclude: ["pkg/excluded.go", "pkg/excluded-dir/*"] # Exclude patterns
    events: [create, write, remove, rename, chmod] # Filesystem events to listen to
    task: task1 # Task to run when event occurs
```
### Patterns
Thanks to [doublestar](https://github.com/bmatcuk/doublestar) *taskctl* supports the following special terms within include and exclude patterns:

Special Terms | Meaning
------------- | -------
`*`           | matches any sequence of non-path-separators
`**`          | matches any sequence of characters, including path separators
`?`           | matches any single non-path-separator character
`[class]`     | matches any single non-path-separator character against a class of characters ([details](https://github.com/bmatcuk/doublestar/blob/master/README.md#character-classes))
`{alt1,...}`  | matches a sequence of characters if one of the comma-separated alternatives matches

Any character with a special meaning can be escaped with a backslash (`\`).

## Contexts
Contexts allow you to set up execution environment, variables, binary which will run your task, up/down commands etc.
```yaml
contexts:
  local:
    executable:
      bin: /bin/zsh
      args:
        - -c
    env:
      VAR_NAME: VAR_VALUE
    variables:
      sleep: 10
    quote: "'" # will quote command with provided symbol: "/bin/zsh -c 'echo 1'"
    before: echo "I'm local context!"
    after: echo "Have a nice day!"
```

Context has hooks which may be triggered once before first context usage or every time before task with this context will run.
```yaml
context:
    docker-compose:
      executable:
        bin: docker-compose
        args: ["exec", "api"]
      up: docker-compose up -d api
      down: docker-compose down api

    local:
      after: rm -rf var/*
```

### Docker context
```yaml
  alpine:
    executable:
      bin: /usr/local/bin/docker
      args:
        - run
        - --rm
        - alpine:latest
    env:
      DOCKER_HOST: "tcp://0.0.0.0:2375"
    before: echo "SOME COMMAND TO RUN BEFORE TASK"
    after: echo "SOME COMMAND TO RUN WHEN TASK FINISHED SUCCESSFULLY"

tasks:
  mysql-task:
    context: alpine
    command: uname -a
```

## Embeddable task runner
*taskctl* may be embedded into any go program. 
Additional information may be found on taskctl's [pkg.go.dev](https://pkg.go.dev/github.com/taskctl/taskctl?tab=overview) page

### Runner
```go
t := task.FromCommands("go fmt ./...", "go build ./..")
r, err := NewTaskRunner()
if err != nil {
    return
}
err  = r.Run(t)
if err != nil {
    fmt.Println(err, t.ExitCode, t.ErrorMessage())
}
fmt.Println(t.Output())
```

### Scheduler
```go
format := task.FromCommands("go fmt ./...")
build := task.FromCommands("go build ./..")
r, _ := runner.NewTaskRunner()
s := NewScheduler(r)

graph, err := NewExecutionGraph(
    &Stage{Name: "format", Task: format},
    &Stage{Name: "build", Task: build, DependsOn: []string{"format"}},
)
if err != nil {
    return
}

err = s.Schedule(graph)
if err != nil {
    fmt.Println(err)
}
```

## FAQ
### How does it differ from go-task/task?
It's amazing how solving same problems lead to same solutions. *taskctl* and go-task have a lot of concepts in common but also have some differences. 
1. Main is pipelines. Pipelines and stages allows more precise workflow design because same tasks may have different dependencies (or no dependencies) in different scenarios.
2. Contexts allow you to set up execution environment and binary which will run your task.

## Autocomplete
### Bash
Add to  ~/.bashrc or ~/.profile
```
. <(taskctl completion bash)
```

### ZSH
Add to  ~/.zshrc
```
. <(taskctl completion zsh)
```
### Similar projects
- [GNU Make](https://github.com/mirror/make)
- [go-task/task](https://github.com/go-task/task)
- [mage](https://github.com/magefile/mage)
- [tusk](https://github.com/rliebz/tusk)
- [just](https://github.com/casey/just)
- [cr](https://github.com/cirocosta/cr)
- [realize](https://github.com/oxequa/realize)

## How to contribute?
Feel free to contribute in any way you want. Share ideas, submit issues, create pull requests. 
You can start by improving this [README.md](https://github.com/taskctl/taskctl/blob/master/README.md) or suggesting new [features](https://github.com/taskctl/taskctl/issues)
Thank you! 

## License
This project is licensed under the GNU GPLv3 - see the [LICENSE.md](LICENSE.md) file for details

## Authors
 - Yevhen Terentiev - [trntv](https://github.com/trntv)
See also the list of [contributors](https://github.com/taskctl/taskctl/contributors) who participated in this project.


taskctl

Task runner with README.md defined tasks, executable markdown.

# xc - Simple, Convenient, Markdown-based task runner.

<div align="center">

![xc](https://user-images.githubusercontent.com/19927761/156772881-10065864-ff4d-4225-ab2b-5adbbe628845.png)
[Docs](https://xcfile.dev/) | [Getting Started](https://xcfile.dev/getting-started/) | [Github](https://github.com/joerdav/xc)

[![xc compatible](https://xcfile.dev/badge.svg)](https://xcfile.dev)
[![test](https://github.com/joerdav/xc/actions/workflows/test.yaml/badge.svg)](https://github.com/joerdav/xc/actions/workflows/test.yaml) 
[![docs](https://github.com/joerdav/xc/actions/workflows/docs.yml/badge.svg)](https://github.com/joerdav/xc/actions/workflows/docs.yml)
[![Go Reference](https://pkg.go.dev/badge/github.com/joerdav/xc.svg)](https://pkg.go.dev/github.com/joerdav/xc)
[![Mentioned in Awesome Go](https://awesome.re/mentioned-badge.svg)](https://github.com/avelino/awesome-go)
[![Go Report Card](https://goreportcard.com/badge/github.com/joerdav/xc)](https://goreportcard.com/report/github.com/joerdav/xc)
[![Coverage Status](https://coveralls.io/repos/github/joerdav/xc/badge.svg?branch=main)](https://coveralls.io/github/joerdav/xc?branch=main)

</div>

`xc` is a task runner similar to `Make` or `npm run`, that aims to be more discoverable and approachable.

The problem `xc` is intended to solve is scripts maintained separately from their documentation.
Often a `Makefile` or a `package.json` will contain some useful scripts for developing on a project,
then the `README.md` will surface and describe these scripts.
In such a case, since the documentation is separate, it may not be updated when scripts are changed or added.
`xc` aims to solve this by defining the scripts [inline with the documentation](https://en.wikipedia.org/wiki/Literate_programming).

`xc` is designed to maximise convenience, and minimise complexity.
Each `xc` task is defined in simple, human-readable Markdown.
This means that even people without the `xc` tool installed can use the README.md
(or whatever Markdown file contains the tasks)
as a source of useful commands for the project.

# Installation

Installation instructions are described at <https://xcfile.dev/getting-started/#installation>.

# Features

- Tasks defined in Markdown files as code blocks.
- Editor integration:
	- [VSCode](https://marketplace.visualstudio.com/items?itemName=xc-vscode.xc-vscode) (list and run `xc` tasks)
	  ![vscode demo](https://user-images.githubusercontent.com/19927761/214538057-963f9a47-ff95-486c-8856-b90bd358be3f.png)
	- [Vim](https://xcfile.dev/ide-support/#vim) (recommended config for listing and running `xc` tasks)

# Example

Take the `tag` task in the [README.md](https://github.com/joerdav/xc#tag) of the `xc` repository:

````
## tag

Deploys a new tag for the repo.

Requires: test

```
export VERSION=`git rev-list --count HEAD`
echo Adding git tag with version v0.0.${VERSION}
git tag v0.0.${VERSION}
git push origin v0.0.${VERSION}
```
````

The task could be run simply with `xc tag`, but a side-effect of it being an `xc` task is that the steps for pushing a tag without the use of `xc` are clearly documented too.

```
$ xc tag
+ go test ./...
?       github.com/joerdav/xc/cmd/xc   [no test files]
?       github.com/joerdav/xc/models   [no test files]
ok      github.com/joerdav/xc/parser   (cached)
ok      github.com/joerdav/xc/run      (cached)
+ export VERSION=78
+ echo Adding git tag with version v0.0.78
Adding git tag with version v0.0.78
+ git tag v0.0.78
+ git push origin v0.0.78 Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:joerdav/xc
 * [new tag]         v0.0.78 -> v0.0.78
```

# Tasks

## test

Test the project.

```
go test ./...
```

## lint

Run linters.

```
golangci-lint run
```

## build

Builds the `xc` binary.

```
go build ./cmd/xc
```

## tag

Deploys a new tag for the repo.

Specify major/minor/patch with VERSION

Inputs: VERSION

Requires: test

```
# https://github.com/unegma/bash-functions/blob/main/update.sh

CURRENT_VERSION=`git describe --abbrev=0 --tags 2>/dev/null`
CURRENT_VERSION_PARTS=(${CURRENT_VERSION//./ })
VNUM1=${CURRENT_VERSION_PARTS[0]}
VNUM2=${CURRENT_VERSION_PARTS[1]}
VNUM3=${CURRENT_VERSION_PARTS[2]}

if [[ $VERSION == 'major' ]]
then
  VNUM1=$((VNUM1+1))
  VNUM2=0
  VNUM3=0
elif [[ $VERSION == 'minor' ]]
then
  VNUM2=$((VNUM2+1))
  VNUM3=0
elif [[ $VERSION == 'patch' ]]
then
  VNUM3=$((VNUM3+1))
else
  echo "Invalid version"
  exit 1
fi

NEW_TAG="$VNUM1.$VNUM2.$VNUM3"

echo Adding git tag with version ${NEW_TAG}
git tag ${NEW_TAG}
git push origin ${NEW_TAG}
```

## update-nix
Updates nix flake.
```
sh ./update-nix.sh
```

## install-hugo

Install hugo via `go install`.

```sh
go install github.com/gohugoio/hugo@latest
```

## run-docs

Run the hugo development server.

Directory: doc

```sh
hugo serve
```

## build-docs

Build production docs site.

Directory: doc

```sh
./build.sh
```


The Best Go Libraries For Build Automation - Libraries and tools help with build automation. (12)