Functionality for saving/restoring artifacts.  This is similar to caches, but
where caches are used between the same jobs in different builds, artifacts are
used for different jobs in the same build.  Artifacts can also be exposed to
the outside world.

Blob storage functionality, used to store and restore large files
or entire directories.

Functions for working with the build object in the runtime.  This
represents the current build.

Functions for invoking the script API.

Functions to configure container images on a build step

Core build script functionality.  This is used by build scripts to create
the configuration which is then executed by the configured runner.  Which
runner is configured or active depends on the configuration of the MonkeyCI
application that executes the script.

Functionality for saving/restoring caches.  This uses blobs.

Event handlers for commands

Configuration functionality.  This reads the application configuration from various
sources, like environment vars or command-line args.  The configuration is structured
in a hierarchy and optionally some values are converted.  Then this configuration is
used to add any 'constructor functions', that are then used to create new functions to
do some actual work.  This allows us to change the behaviour of the application with
configuration, but also makes it possible to inject dummy functions for testing 
purposes.

Generic functionality for running containers

Functions for running build jobs using Docker api.

Container runner implementation that uses OCI container instances.

Functions for running containers using Podman.  We don't use the api here, because
it requires a socket, which is not always available.  Instead, we invoke the podman
command as a child process and communicate with it using the standard i/o streams.

Core namespace for the Monkey CI app.  This contains the entrypoint which
processes the configuration.  This configuration determines whether the
application runs as a server, execute a single script, which type of runner
is enabled, etc...

Implementation for events that connect to a HTTP server as a client.  These
cannot be used to receive events from, use websockets instead.

Manifold-based implementation of event poster and receiver

Clone and checkout git repos.  This is mostly a wrapper for `clj-jgit`

Handles job execution and ordering in a build

Handles log configuration and how to process logs from a build script

Oracle cloud specific functionality

Process execution functions.  Executes build scripts in a separate process,
using clojure cli tools.

Contains all (or most of) the protocols used in the app.  This is useful
to avoid circular dependencies.

Provides functions for reporting output.  This can be logging, or printing
to stdout, or formatting as json, etc...

Reporter that prints to the console using coloring.

Defines runner functionality.  These depend on the application configuration.
A runner is able to execute a build script.

The runtime can be considered the 'live configuration'.  It is created
from the configuration, and is passed on to the application modules.  The
runtime provides the information (often in the form of functions) needed
by the modules to perform work.  This allows us to change application 
behaviour depending on configuration, but also when testing.

Thie namespace also provides some utility functions for working with the
context.  This is more stable than reading properties from the runtime 
directly.

Sidecar specific functions

Data storage functionality

Cached storage implementation.  It wraps another storage and adds caching to it.
This currently is a very naive implementation.  It should be expanded with event processing,
in case there are multiple replicas.  Or we should replace it with a 'real' database.

File storage implementation.  Useful for local or develop runs.  It stores all
information in local .edn files.

Authentication and authorization functions

Functionality specific for Github

Handler for the web server

API functionality that can be accessed by the build script.  This can either
be part of the public API, or exposed through a UDS from the build runner.  The
script API does not have security on its own, since the implementation will
take care of this.  The script API exposes an OpenAPI spec, which is then
fetched by the script, so it knows which services are available.