Crates.io | rox-cli |
lib.rs | rox-cli |
version | 0.8.2 |
source | src |
created_at | 2023-09-10 17:29:14.996666 |
updated_at | 2024-05-12 15:47:40.698624 |
description | Composable build tool inspired by Make |
homepage | |
repository | https://github.com/ThomasLaPiana/rox |
max_upload_size | |
id | 968935 |
size | 362,951 |
Rox is a robust developer workflow framework inspired by Nox, Make & cargo-make
Rox gives you the ability to build your own devtools CLI using YAML files, check CI pipeline statuses from your terminal, and even read documentation. Tasks and Pipelines are dynamically added to the CLI as subcommands at runtime. The flexibility of rox
intends to makes it easier for dev teams to standardize their workflows without writing endless "glue" scripts.
The subcommands and their help messages are automatically populated at runtime from the name
and description
of each task
or pipeline
.
See synthesizer for an example of usage in a real project.
Rox was created for the purpose of making building and developing applications easier. It is designed to focus on extensiblity, performance, and documentation. Here are a few of the key features that help Rox achieve that goal:
Tasks
, Pipelines
and Templates
, etc.) it is possible to handle virtually any use-case with minimal boilerplate.help
command is always accurate. This helps developers understand what various tasks and pipelines do without needing to dive into the code or understand complex bash.Rox can be installed via binaries provided with each release here. As an alternative, it can also be installed via cargo
with cargo install rox-cli
.
Rox requires a YAML
file with the correct format and syntax to be parsed into a CLI. This file is expected to be at ./roxfile.yml
by default but that can be overriden with the -f
flag at runtime.
Rox allows developers to see CI pipeline results from their terminal with some minimal configuration.
It will automatically get the CI pipeline for the current branch.
ci:
# The CI provider to use. Currently only GitHub Actions is supported.
provider: github_actions
repo_owner: ThomasLaPiana
repo_name: rox
# The name of the env var with the stored PAT (Personal Access Token)
token_env_var: GITHUB_TOKEN
Specifying docs
within your roxfile
allows you to keep track of various types of documentation for your project.
url
-> Opens a webbrowser pointed at the URL
provided in the path
markdown
-> Opens the file at path
in a special in-terminal Markdown viewer. This allows the developer to navigate around a Markdown document without leaving the terminal.text
-> Prints a text file to the terminal.docs:
- name: testing
description: Docs around testing
kind: markdown # [markdown|url|text]
path: docs/testing.md
Templates allow you to specify templated commands that can be reused by tasks
. Values are injected positionally. These are intended to facilitate code reuse and uniformity across structurally similar commands.
templates:
- name: docker_build
command: "docker build {path} -t rox:{image_tag}"
symbols: ["{path}", "{image_tag}"]
Tasks are discrete units of execution. They're intended to be single shell commands that can then be composed via pipelines
. They are also able to leverage templates
by specifying one with uses
and injecting values with values
.
tasks:
- name: build-prod
description: "Build the application dockerfile"
uses: docker_build
values: [".", "latest"]
- name: "watch-run"
description: "Run the application, restarting on file changes"
command: "cargo watch -c -x run"
Pipelines are the canonical way to chain together multiple tasks into a single unit of execution. Note that the stages
object expects a list of lists, which we'll expand upon below.
pipelines:
- name: example-pipeline
description: Composes a few tasks
stages:
- ["task-a"]
- ["task-b", "task-c"]
To make execution more efficient, Pipelines support a simple scheduling syntax that allows tasks
within the same stage to be executed in parallel. This gives user more fine-grained control over how multiple tasks are executed while still keeping the syntax relatively lightweight.
Note: Parallel execution is not used by default, and requires using the --parallel
or -p
flag on invocation.
The stages
field expects a list of lists to facilitate this. Each stage
is like a small pipeline in and of itself, and each stage's tasks must all finish executing before work starts on the next stage.
In the following example, the parallel execution pattern would look like this:
a
is executedb
and c
are executed, potentially in parallele
and d
are executed, potentially in parallel.f
is executed.pipelines:
- name: example-pipeline
description: Composes a few tasks
stages:
- ["task-a"]
- ["task-b", "task-c"]
- ["task-e", "task-d"]
- ["task-f"]
There isn't a specific roxfile
section for it, but the logs
subcommand is very useful for quickly viewing recent logs.
Now that we've seen each individual piece of the Rox puzzle, we can put them all together into a full roxfile
. See the example roxfile.yml in this repo for a working example!