Go to file
Will Sinatra 3272e352a8 convert to mariadb install 2024-04-15 20:31:31 -04:00
Generated convert to mariadb install 2024-04-15 20:31:31 -04:00
Tasks convert to mariadb install 2024-04-15 20:31:31 -04:00
Templates convert to mariadb install 2024-04-15 20:31:31 -04:00
src add some prototypal lxd integration 2024-01-25 08:52:18 -05:00
.gitignore fix typo, ignore binary 2024-04-16 00:06:44 +00:00
LICENSE GPL 2023-03-29 19:53:20 -04:00
README.md re-simplify lc template and document feature 2024-01-20 22:47:42 -05:00

README.md

What?

Verkos: (Esperanto) will compose

Verkos will compose your shell snippets into functional monolithic setup scripts!

Build

Deps:

nim, nimble
cd src
nimble install yaml
make build

Usage:

Verkos arguments

Generate a Verkos Template:

verkos new template Templates/example.yaml

Generate a Task Template:

verkos new task pkgs

Generate a script from a template:

verkos compose Templates/something.yaml

Writing a Task

Here's a simple example, really you just need a task to be a simple shell function.

pkgs() {
	apk add $1
}

You can source and use that snippet like this:

Script: Generated/example.sh
Shell: '#!/bin/ash'
Variables:
Tasks:
  - Path: Tasks/apk_pkgs
    Invo: 'pkgs "emacs htop tmux"'

And the resulting script should come out like this:

#!/bin/ash

pkgs() {
	apk add $1
}

pkgs "emacs htop tmux"

You can also include variables in your tasks. The same task could look like this:

pkgs() {
	apk add $packages
}

In your template file you'd then need to provide a variable with your packages:

Script: Generated/example.sh
Shell: '#!/bin/ash'
Variables:
  - Name: packages
    Value: "emacs htop tmux"
Tasks:
  - Path: Tasks/apk_pkgs
    Invo: apk_pkgs

And the resulting script should come out like this:

#!/bin/ash
packages="emacs htop tmux"

pkgs() {
	apk add $packages
}

pkgs

A very simple difference, but intermingling these two paradigms allows you to build either reusable tasks you can import ubiquitously, or more complicated tasks you can provide flexible configuration for easily.

There is also a shell escape for passing in raw shell commands, like if you wanted to define a one off configuration file at a point, or run a series of ad hoc shell commands. A lot like how Ansible does it.

  - Path: sh
    Invo:
      - |
        cat > /etc/init.d/lambdacreate <<EOF
        #!/sbin/openrc-run
        description="Initialize Lambdacreate"
        lver=5.1
        command="/usr/bin/lapis\$lver"
        command_args="server production"
        pidfile="/var/run/nginx/nginx.pid"
        lapis_path="/usr/share/lapis"

        depend() {
          need net
        }

        start_pre() {
          checkpath --directory --owner nginx:nginx \${pidfile%/*}
        }

        start() {
          ebegin "Starting Lambdacreate"
          start-stop-daemon --start \\
            --chdir \${lapis_path} \\
            --exec \${command} \${command_args} \\
            -b --make-pidfile \\
            --pidfile "\${pidfile}"
          eend $?
        }

        stop() {
          ebegin "Stopping Lambdacreate"
          start-stop-daemon --stop \\
            --exec \${command} \\
            --pidfile "\${pidfile}"
          # Temporary workaround for lapis term not stopping the nginx process.
          nginx_pid=\$(ps x | grep nginx.*lambdacreate | head -n 1 | cut -d" " -f2-3)
          kill \${nginx_pid}
          eend \$?
        }
        EOF
        chmod +x /etc/init.d/lambdacreate'

TODO

- Some sort of lint/checker for the template & task files?
- A variable checker, so if a task has a $var that isn't defined it warns during generation
- Vault style secret substitutions, or post generation modifier