A small agent to run CI scripts
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
root 76a6432865 added support for secret files and spork lib, runner metadata 5 months ago
.editorconfig Base commit 5 months ago
.gitignore Base commit 5 months ago
LICENSE Base commit 5 months ago
README.md added support for secret files and spork lib, runner metadata 5 months ago
archetype.janet added support for secret files and spork lib, runner metadata 5 months ago
runner.janet added support for secret files and spork lib, runner metadata 5 months ago

README.md

CI-Agent

trans rights!

A small CI runner agent for Arch, Debian, and Alpine systems.

Why?

Because it seems like no current CI system is made for simple git architectures (ie barebones). You either need around 1982738123 daemons or a huge forge like Gitea or worse.

I want a small control daemon that would plug itself on top of git and systemd (+ docker or podman for runner containers), not something that requires 11 databases.

Support and dependencies

This tool supports 3 distros:

  • Arch linux (pacman, no standard AUR support)
  • Debian (apt)
  • Alpine (apk)

The strong dependency is the package manager, so technically, every "alternative" distro shipping those should be able to handle this agent.

This tool requires Janet lang, and has been tested using Janet 1.16.1

Build manifest format

The build manifest is written in Janet for simplicity. It works by defining the rules on top level. You have access to the entirety of the Janet standard library and the spork library, don't shy away from using it.

The build manifest file name should be archetype.janet.

Build manifest example

This document is a pretty basic manifest example.

(def runner 'alpine)

# This marks the REMOTE environment variable as required for execution
(def secrets '(REMOTE))
# This marks the REMOTE_KEY environment variable as the content of a file that will then be located at ~/.ssh/id_25519
# (typically, for ssh-based file transfer)
(def secret-files ~((REMOTE_KEY ,(string (os/getenv "HOME) "/.ssh/id_ed25519"))
					 (KNOWN_HOSTS ,(string (os/getenv "HOME") "/.ssh/known_hosts"))))

(def pkgs '(go tar openssh)) # This will install both packages before starting the build
(def build # This will run two commands, echo and date
	~((:run "echo What day is it?")
	 (:run "date")))

Note that if you use SSH, it is recommended to set your own known_hosts file with your server keys.

Top-level rules

  • The runner symbol (required) should contain the name of the runner you wish to use (dependent on your configuration).
  • The secrets symbol (optional) should contain a tuple of environment variables. Every environment variable inside this tuple will be verified for existence. Example: (def secrets '(HOME USER REMOTE_HOME)).
  • The secret-files symbol (optional) should contain a tuple of environment variables to filesystem paths. Every environment variable inside this tuple will be verified for existence. Example: (def secret-files '((REMOTE_KEY "/home/runner/.ssh/id_25519"))).
  • The pkgs symbol (optional) should contain a tuple of package names. Example: (def pkgs '(go tar)).
  • The build symbol (required) should contain a list of action definitions, of the format (:type args). Example: '((:run "Hello, world") (:upload "build/production" (os/getenv "REMOTE"))).

The build system

The build system provides a few well-known action types for simplicity.

  • run
  • upload

TODO

TODOs

  • Finish this doc
  • ecosystem action ? e.g. for debian and such to automatically pull go, or nvm, and such