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 tap gopinath-langote/one-build
brew install one-build
```

Verify the installation:
```console
1build --version
```

<details>
<summary><strong>Troubleshooting: Checksum mismatch error</strong></summary>

If you see "Formula reports different checksum", try clearing the cached formula:
```console
brew untap gopinath-langote/one-build
brew tap gopinath-langote/one-build
brew install one-build
```

This fetches the latest version and clears any cached formula data.
</details>

### 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) | [日本語](README-ja.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
- Configurable `.env` file loading

### Overwrite specify configuration from arguments

Support air config fields as arguments:

You can view the available command-line arguments by running the following commands:  

```
air -h
```
or  
```
air --help
```

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.entrypoint "./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.entrypoint "./bin/api" --build.exclude_dir "templates,build"
```

## Installation

### Via `go install` (Recommended)

With go 1.25 or higher:

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

### Via `go get -tool` (project install)

With go 1.25 or higher:

```shell
go get -tool github.com/air-verse/air@latest

# then use it like so:
go tool air -v
```

### 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
```

### Via [Homebrew](https://github.com/Homebrew/brew)

```shell
brew install go-air
```

### Using software package manager [mise](https://github.com/jdx/mise)

```shell
mise use -g air
```

### 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 to run

```shell
# first tries `.air.toml` in current directory; if not found, uses defaults
air
```

To use a specific config file explicitly, pass `-c`:

```shell
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
```

### Startup banner

Use `misc.startup_banner` to control what Air prints at startup.

```toml
[misc]
# Not set (default): show built-in ASCII banner with version.

# Set to empty string: print nothing.
startup_banner = ""

# Set to custom text: print this text instead of the built-in banner.
# startup_banner = "API watcher"
```

### Entrypoint

Use `build.entrypoint` to point at the binary generated by `build.cmd` and describe how it should be executed. The value can be either a string (just the executable) or an array of strings. When using an array, the first element is the executable (resolved relative to `root` unless it lacks a path separator, in which case `$PATH` is consulted) and every subsequent element is treated as a default argument. Values from `build.args_bin` and the command line are appended after the inline arguments. The legacy `build.bin` field is deprecated and will be removed in a future release, so prefer the entrypoint form going forward.

```toml
[build]
entrypoint = ["./tmp/main"]
args_bin = ["server", ":8080"]

# Inline the default arguments directly after the binary.
entrypoint = ["./tmp/main", "server", ":8080"]

# Use PATH-resolved tools like dlv by omitting path separators.
entrypoint = [
  "dlv", "exec", "--accept-multiclient", "--log", "--headless", "--continue",
  "--listen=:8999", "--api-version", "2", "./tmp/main",
]
```

### Environment Files

Air can automatically load environment variables from `.env` files before both building and running when `env_files` is configured.

```toml
# Loads .env.development and then .env files.
# Values in the lattermost file overwrite any preceding ones.
# Does not overwrite variables that were present before running air.
env_files = [".env.development", ".env"]
```


### Platform-specific build overrides

You can override build settings per OS with `[build.windows]`, `[build.darwin]`, and `[build.linux]`. These blocks override the base `[build]` values when running on the matching platform. Only the fields below are supported in platform blocks: `pre_cmd`, `cmd`, `post_cmd`, `bin`, `entrypoint`, `full_bin`, `args_bin`.

```toml
[build]
cmd = "go build -o ./tmp/main ."
bin = "./tmp/main"

[build.windows]
cmd = "go build -o ./tmp/main.exe ."
bin = "tmp\\main.exe"
entrypoint = ["tmp\\main.exe"]
```

Running `air init` adds a platform block for the current OS when its defaults differ from the base configuration.

### 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.25
FROM golang:1.25-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 your .profile and make sure to source the .profile if you add it!!!
```

### 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.25+ (see `go.mod`).

```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

[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
   ```
`



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

# goyek

[![Go Reference](https://pkg.go.dev/badge/github.com/goyek/goyek.svg)](https://pkg.go.dev/github.com/goyek/goyek/v3)
[![Keep a Changelog](https://img.shields.io/badge/changelog-Keep%20a%20Changelog-%23E05735)](CHANGELOG.md)
[![go.mod](https://img.shields.io/github/go-mod/go-version/goyek/goyek)](go.mod)
[![Go Report Card](https://goreportcard.com/badge/github.com/goyek/goyek/v3)](https://goreportcard.com/report/github.com/goyek/goyek/v3)
[![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)

**goyek** (/ˈɡɔɪæk/ [🔊 listen](https://ipa-reader.com/?text=%CB%88%C9%A1%C9%94%C9%AA%C3%A6k))
is a task automation library intended to be an alternative to
[Make](https://www.gnu.org/software/make/),
[Mage](https://github.com/magefile/mage),
[Task](https://taskfile.dev/).

5-minute video: [Watch here](https://www.youtube.com/watch?v=e-xWEH-fqJ0)
([Slides](https://docs.google.com/presentation/d/1xFAPXeMiOD-92xeIHkUD-SHmJZwc8mSIIgpjuJXEW3U/edit?usp=sharing)).

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

## Usage

For build automation, store your code in the `build` directory.

The following example defines a simple `hello` task that logs a message
and prints the Go version.

Create `build/hello.go`:

```go
package main

import (
	"flag"

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

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

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

Create `build/main.go`:

```go
package main

import (
	"os"

	"github.com/goyek/goyek/v3"
	"github.com/goyek/x/boot"
)

func main() {
	if err := os.Chdir(".."); err != nil {
		panic(err)
	}
	goyek.SetDefault(hello)
	boot.Main()
}
```

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

Run help:

```sh
cd build
go mod tidy
go run . -h
```

Expected output:

```out
Usage of build: [tasks] [flags] [--] [args]
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
```

Run with verbose output:

```sh
go run . -v
```

Example output:

```out
===== TASK  hello
      hello.go:16: greeting message
      hello.go:17: Exec: go version
go version go1.24.0 linux/amd64
----- PASS: hello (0.12s)
ok      0.123s
```

Instead of running `go run .` inside `build`, you can use wrapper scripts:

- Bash: [`goyek.sh`](goyek.sh).
- PowerShell: [`goyek.ps1`](goyek.ps1).

Use [`goyek/template`](https://github.com/goyek/template) when creating
a new repository. For existing repositories, simply copy the relevant files.

See the [documentation](https://pkg.go.dev/github.com/goyek/goyek/v3) for more information.

## Examples

The following repositories demonstrate real-world usage of goyek:

- [goyek/template](https://github.com/goyek/template): a Go application
  repository template using goyek for build automation.
- [build/](build/): this repository dogfoods goyek for its own build
  pipeline.
- [splunk-otel-go](https://github.com/signalfx/splunk-otel-go/tree/main/build):
  a multi-module repository using goyek.
- [curioswitch/go-build](https://github.com/curioswitch/go-build) and projects
  such as [curioswitch/tasuke](https://github.com/curioswitch/tasuke/blob/main/build/main.go):
  an example of extracting reusable build tasks into a shared module consumed by
  multiple repositories.

## Best practices and patterns

- **Keep build code in `build/`**: place your automation in a dedicated
  `build` directory or module so it stays separate from application code.
- **Define tasks at startup**: register tasks with
  `goyek.Define` during package init, before calling `Main` or `Execute`, and
  avoid mutating task definitions afterwards.
- **Use `*goyek.A` for control flow**: prefer `a.Log`, `a.Error`, `a.Fatal`,
  `a.Skip`, `a.Cleanup`, and `a.Context` over manual `log` or `os.Exit` calls.
- **Prefer helpers for external commands**: use
  `github.com/goyek/x/cmd.Exec` or a small helper (like this repo's
  `build/exec.go`) instead of calling `os/exec` directly in actions.
- **Structure pipelines with dependencies**: keep actions small and compose
  them with `Deps` rather than writing one large, monolithic task.
- **Use middlewares for cross-cutting concerns**: plug in middlewares such as
  `middleware.ReportStatus`, `middleware.ReportLongRun`, `middleware.DryRun`,
  `middleware.BufferParallel`, or custom ones via `goyek.Use` and
  `goyek.UseExecutor`.
- **Be deliberate with parallelism**: set `Task.Parallel` only when actions are
  safe to run concurrently and rely on `middleware.BufferParallel` to keep
  output readable.
- **Treat context and cleanup carefully**: start long-running resources using
  `a.Context()` and release them in `a.Cleanup` callbacks, keeping in mind that
  the task context is canceled before cleanups run.
- **Reuse tasks across repositories**: extract common tasks into a shared
  module (as in `curioswitch/go-build`) and import them from other projects to
  keep build logic consistent.

## Rationale

**goyek** was originally built as a small library for expressing Go build
pipelines in Go itself instead of relying on an external DSL or tool.
Keeping build logic as regular Go code makes it easy to reuse existing
packages, refactor with IDE support, and debug tasks with the standard Go
toolchain.

At a high level, goyek has the following properties:

- Small, library-first design (not a standalone binary) with an API
  inspired by [`testing`](https://golang.org/pkg/testing),
  [`cobra`](https://github.com/spf13/cobra),
  [`flag`](https://golang.org/pkg/flag), and
  [`http`](https://golang.org/pkg/http).
- Cross-platform and shell independent.
- No binary installation required.
- Easy to debug, like regular Go code.
- Tasks are defined similarly to
  [`cobra`](https://github.com/spf13/cobra) commands.
- Task actions look like Go tests:
  [`goyek.A`](https://pkg.go.dev/github.com/goyek/goyek/v3#A)
  provides methods similar to [`testing.T`](https://pkg.go.dev/testing#T).
- Can reuse any Go code and library, for example
  [`viper`](https://github.com/spf13/viper).
- Highly customizable via middlewares and composition.
- Zero third-party dependencies in the core module.
- Additional convenience packages are available in
  [`goyek/x`](https://github.com/goyek/x).

Although build automation remains the primary use case, goyek is designed as
a general task runner. Tasks are ordinary Go functions wired together through
dependencies, which makes it suitable for other domains as well. It is known
to be used, for example, by SRE and platform teams to automate deployment
pipelines and other operational workflows.

Compared to [Make](https://www.gnu.org/software/make/) and similar tools,
goyek does not require learning a separate DSL or shell tricks and makes it
easier to keep pipelines portable across platforms. Unlike
[Mage](https://github.com/magefile/mage), it avoids build tags, code
generation, and magic discovery of targets – you just write and compose
ordinary Go functions. In contrast to [Task](https://taskfile.dev/), there is
no YAML to learn or additional binary to install, and debugging tasks is
like debugging any other Go program. Finally, while systems such as
[Bazel](https://bazel.build/) focus on large, hermetic build graphs, goyek
deliberately stays small and library‑like, so you can start with a simple
build script and grow into more advanced pipelines only when needed.

## Contributing

We welcome contributions! See [CONTRIBUTING.md](CONTRIBUTING.md) for details.

## 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 with go version < 1.17**

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

**Using Go Install with go version >= 1.18**

```
go install github.com/magefile/mage@latest
mage -init
```

Instead of the @latest tag, you can specify the desired version, for example:

```
go install github.com/magefile/mage@v1.15.0
```

**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

realize

<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)
![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
```
#### 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
```
#### 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
- `env_file` - file with env variables in `k=v` format to read variables from
- `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)
- [makesure](https://github.com/xonixx/makesure)
- [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, Docs-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](https://en.wikipedia.org/wiki/Markdown) or
[org-mode](https://orgmode.org/). This means that even people without the `xc`
tool installed can use the README (or whatever documentation 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>.

# Contributing
Find our guidelines & HOWTOs at [CONTRIBUTING.md](https://github.com/joerdav/xc/blob/main/CONTRIBUTING.md).

# Features

- Tasks defined in Markdown or org-mode 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)
    - [Emacs](https://codeberg.org/ryanprior/xc.el)
      ![emacs demo](https://codeberg.org/ryanprior/xc.el/media/branch/main/screenshot-v1.png)
- See also: [`org-mode` specific features](https://xcfile.dev/org-mode-features).

# 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
```


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

  <h1>Task: The Modern Task Runner</h1>

  <p>
    A fast, cross-platform build tool inspired by Make, designed for modern workflows.
  </p>

  <p>
    <a href="https://taskfile.dev/docs/installation">Installation</a> &bullet; <a href="https://taskfile.dev/docs/getting-started">Getting Started</a> &bullet; <a href="https://taskfile.dev/docs/guide">Docs</a> &bullet; <a href="https://twitter.com/taskfiledev">Twitter</a> &bullet; <a href="https://bsky.app/profile/taskfile.dev">Bluesky</a> &bullet; <a href="https://fosstodon.org/@task">Mastodon</a> &bullet; <a href="https://discord.gg/6TY36E39UK">Discord</a>
  </p>

  <h1>Gold Sponsors</h1>

  <table>
    <tr>
      <td align="center" valign="middle">
        <a target="_blank" href="https://devowl.io">
          <img src="website/src/public/img/devowl.io.svg" height="100px" width="200px" title="devowl.io" />
        </a>
      </td>
      <td align="center" valign="middle">
        <a target="_blank" href="https://goodx.international/">
          <img src="website/src/public/img/goodx.svg" height="80px" width="200px" title="GoodX" />
        </a>
      </td>
      <td align="center" valign="middle">
        <a target="_blank" href="https://magic.dev/">
          <img src="website/src/public/img/magic.png" height="100px" width="200px" title="Magic" />
        </a>
      </td>
    </tr>
  </table>

  <h2>Community Sponsors</h2>

  <table>
    <tr>
      <td align="center" valign="middle">
        <a target="_blank" href="https://cloudsmith.com/">
          <img src="website/src/public/img/cloudsmith.svg" height="100px" width="200px" title="Cloudsmith" />
        </a>
      </td>
    </tr>
  </table>
</div>


Task

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

The Best Go Libraries For Build Automation (13)

1build

air

anko

gob

gaper

goyek

mage

mmake

realize

taskctl

xc

Task

gaper