Go to file
Will Sinatra fc32edc92b attempt to setup a woodpecker server 2024-07-07 00:23:01 -04:00
Generated attempt to setup a woodpecker server 2024-07-07 00:23:01 -04:00
Tasks attempt to setup a woodpecker server 2024-07-07 00:23:01 -04:00
Templates attempt to setup a woodpecker server 2024-07-07 00:23:01 -04:00
src remove invalid config from server block, add notes to TODO, move tls psk config to zabbix_agent2 task 2024-06-09 10:59:04 -04: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



Verkos: (Esperanto) will compose

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



nim, nimble
cd src
nimble install yaml
make build


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'
  - Path: Tasks/apk_pkgs
    Invo: 'pkgs "emacs htop tmux"'

And the resulting script should come out like this:


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'
  - Name: packages
    Value: "emacs htop tmux"
  - Path: Tasks/apk_pkgs
    Invo: apk_pkgs

And the resulting script should come out like this:

packages="emacs htop tmux"

pkgs() {
	apk add $packages


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
      - |
        cat > /etc/init.d/lambdacreate <<EOF
        description="Initialize Lambdacreate"
        command_args="server production"

        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 \$?
        chmod +x /etc/init.d/lambdacreate'


- 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