You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .milpa/commands/itself/command-tree.yaml
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
summary: Prints a tree of known commands
2
2
description: |
3
-
Prints out command names and descriptions, or optionally a nested representation of all properties of commands, serialized as `json` or `yaml`. Custom textual representations of commands can be obtained by using the `--template` option and specifying a [go-template](https://pkg.go.dev/text/template#hdr-Actions) to be applied to every command. See [chinampa/pkg.Command](https://pkg.go.dev/git.rob.mx/nidito/chinampa@v0.0.0-20230324015136-6ec1c56f0fc5/pkg/command#Command) and [milpa/internal/command.Meta](https://pkg.go.dev/github.com/unrob/milpa@v0.0.0-20230321064607-ee1825c67af7/internal/command#Meta) for references on the structs available during template rendering.
3
+
Prints out command names and descriptions, or optionally a nested representation of all properties of commands, serialized as `json` or `yaml`. Custom textual representations of commands can be obtained by using the `--template` option and specifying a [go-template](https://pkg.go.dev/text/template#hdr-Actions) to be applied to every command. See [chinampa/pkg.Command](https://pkg.go.dev/git.rob.mx/nidito/chinampa/pkg/command#Command) and [milpa/internal/command.Meta](https://pkg.go.dev/github.com/unrob/milpa/internal/command#Meta) for references on the structs available during template rendering.
Copy file name to clipboardExpand all lines: .milpa/docs/milpa/support.md
+2-6Lines changed: 2 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,15 +4,11 @@ description: how to deal with bugs in milpa
4
4
weight: 99
5
5
---
6
6
7
-
`milpa` is currently alpha software. This means that while I've personally tested it for over a year:
8
-
9
-
- test coverage is pretty lacking,
10
-
- the command spec and script environment is subject to change, and,
11
-
- there's **no guarantee of stability** of any internal command or utility.
7
+
`milpa` is currently beta software: the tool is mostly feature-complete, but these features are likely to contain bugs, not be properly covered by the test suite nor fully documented. Bug reports, code contributions and general questions are welcome!
12
8
13
9
## ℹ️ Requesting help
14
10
15
-
Please [open a support request](https://github.com/unRob/milpa/issues/new?assignees=&labels=help-requested&template=help-request.yml&title=%5Bhelp%5D%3A+) on github, and I'll do my best to help.
11
+
Please [open a support request](https://github.com/unRob/milpa/issues/new?assignees=&labels=help-requested&template=help-request.yml&title=%5Bhelp%5D%3A+) on Github, and I'll do my best to help.
Copy file name to clipboardExpand all lines: .milpa/docs/milpa/use-case.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,14 +22,14 @@ My goal with `milpa` is to make following the [Command Line Interface Guidelines
22
22
23
23
Tasks like bootstrapping development environments are usually left out for the user to accomplish by following through a README or wiki with likely outdated links; `milpa` is great when these tasks can be accomplished by prompting for information, querying identity providers and then running configuration commands or modifying the filesystem directly.
24
24
25
-
> ⚠️ `milpa` is still under development and is currently on alpha!
25
+
> ⚠️ `milpa` is still under development and is currently on beta!
26
26
27
27
### Examples
28
28
29
29
Here's some examples of how I've used used `milpa` so far:
30
30
31
31
- for **managing homelab services** (i.e. [unRob/nidito](https://github.com/unRob/nidito/tree/master/.milpa)): building and deploying them, looking at their status and logs. From my personal device or CI.
32
-
-**bootstrapping engineering laptops** (i.e. [unRob/dotfiles](https://github.com/unRob/dotfiles/tree/master/.milpa/commands/computar)): no need to follow a README, you get the right development environment for your os/arch, your credentials setup and the code ready for you to dive in.
32
+
-**bootstrapping workstations** (i.e. [unRob/dotfiles](https://github.com/unRob/dotfiles/tree/master/.milpa/commands/computar)): no need to follow a README, you get the right development environment for your os/arch, your credentials setup and the code ready for you to dive in.
33
33
-**every-day dev workflow** (i.e. [unRob/milpa](https://github.com/unRob/milpa/tree/main/repos/internal/commands/)): lint and test a codebase, connect to vpn, get credentials to resources, maybe `--connect` to them, abstract away APIs (internal, cloud provider and SaaS) and CLIs, toggle feature gates, build reports and update google sheets with the results.
34
34
- as a way to organize all those odd, one-off-but-not-really commands: found a nice home for [shell scripts](https://github.com/unRob/dotfiles/blob/master/.milpa/commands/code/todo.sh), quick ruby scripts, perl hacks and [jq monstrosities](https://github.com/unRob/dotfiles/blob/master/.milpa/commands/creds.sh) that used to live in my `~/.zsh_history`.
35
35
@@ -77,7 +77,7 @@ That being said, organizing makefiles and dealing with arguments is not somethin
77
77
78
78
### BYOCLI
79
79
80
-
Building your own CLI is usually what ends up happening given a team with enough time and direction to invest in building a proper CLI with whatever language is already at use. Some teams use more than one language, which may complicate this approach. In the microservices world, many codebases come with their own CLIs that may follow slightly different conventions, are seldomly documented and often just end up calling other binaries through `exec`.
80
+
Building your own CLI is usually what ends up happening given a team with enough time and direction to invest in building a proper CLI with whatever language is already at use. Some teams use more than one language, which may complicate this approach. In the micro-services world, many codebases come with their own CLIs that may follow slightly different conventions, are seldomly documented and often just end up calling other binaries through `exec`.
81
81
82
82
In my limited experience with engineering teams of less than 300 folks, many of the bootstrapping tasks will involve operations that can easily (and more succinctly) be expressed with a shell scripting language. `milpa` could also be a useful intermediate step, that could help teams avoid the dread of confluence/notion/google-docs runbooks until it's a good time to build your own CLI.
0 commit comments