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 build script API.

Functions for setting up a build script API.  The build runner starts its own
API server, which is only accessible by the build script and any containers it
starts.  This is for security reasons, since the build script is untrusted code.
Restricting access to the API server is done on infra level, by setting up network
security rules.  Piping all traffic through the build runner also ensures that
the global API will not be overloaded by malfunctioning (or misbehaving) builds.

Functions for working with downloaded archives

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.

A group of functions written on top of the more low-level build functions, meant
to improve writing build scripts.  They should make the build scripts more intuitive,
more readable.  And, dare I say it, prettier?

The general intention is to provide functions for most purposes, without the user
having to resort to using keywords and maps.

Functionality for saving/restoring caches.  This uses blobs.

Event handlers for commands

Common predicate functions

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.

Build script configuration functions, used by the process controller to 
create a valid configuration that can then be read by the build script runner.

Functions for handling sidecar configuration

Generic functionality for running containers

Container runner that invokes an endpoint on the build api.  This is meant to
be used by child processes that do not have full infra permissions.

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.

Functions for configuring promtail containers.  This is not a container driver, but
a utility namespace that is in turn used when pushing build logs to Loki.

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...

Credit calculation functions

Functions for working with cuids, which are like uuids but are a bit better
to handle for humans.

Functionality for serializing objects to edn and deserializing them back.

Custom queries for builds

Core functionality for database entities.  Allows to store/retrieve basic entities.

Customer specific query functions

Build parameters queries

Repository specific query functions

Special type treatments for sql

Webhook related functionality

Functions for working with errors and exceptions.  This provides a uniform way
to handle exceptions and convert them into a usable format for internal 
propagation and to give useful feedback to the user.

Events implementation that uses the build api to send events

Functions for doing events over http

Uses JMS to connect to an event broker.  Can also starts its own broker 
server, although this is mostly meant for development and testing purposes.

Manifold-based implementation of event poster and receiver

Events implementation that splits input and output.  Events are read from one
side, and posted to another.

Functionality for working with script extensions.  Extensions are a way
for third party libraries to add functionality to scripts, that is easy
to activate and can also be used in yaml-type scripts.  You could of 
course also add regular functions to invoke, but this is not easy to
use, especially when using container jobs.  Extensions do this by registering
themselves under a specific namespaced keyword.  If this key is found in
job properties, the associated extension code is executed.  Extensions can
be executed before or after a job (or both).

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

Logging implementation that sends to Loki.  This is useful for the container
implementation, where promtail is problematic because it never shuts down.

Oracle cloud specific functionality

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

Functionality to export metrics to prometheus format, or push them to a pushgateway.
Originally we used `micrometer-clj`, but it's really old and incompatible with recent
versions of the Prometheus libs.  Since we're fixed on Prometheus (for now), it's not
necessary to maintain all the other formats, so the micrometer layer was essentially
ballast.  This namespace accesses the Prometheus code directly.

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.

Functions for running the application as a controller.

Variation of the oci runner, that creates a container instance with two containers:
one running the controller process, that starts the build api, and the other that
actually runs the build script.  This is more secure and less error-prone than
starting a child process.

Runner that can be configured to run builds directly from the server.

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.

Functions for setting up a runtime for application (cli or server)

Functions for creating a runtime for build scripts

Functions for creating a runtime for a build-aware environment for the sidecar

Functions for working with storage ids

Sidecar specific functions

Spec definitions for build.  The build object in the runtime and events that contain
builds, scripts or jobs should conform to these specs.

Specs for app configurations

Container related config and context specs

Job context spec

Spec for database entities.  This can be useful to auto-generate database
record entities for testing, but also to validate entities before persisting 
them.

Spec for application entities.

Spec definitions for events

Specs for sidecar configuration

Data storage functionality.  Next to basic storage implementations, this ns also contains
a lot of functions for working with storage entities.  Many of these are overridden by
implementation-specific functions, and so implementations here don't focus on efficiency.
They are merely used in tests.

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.

Storage implementation that uses an SQL database for persistence.  This namespace provides
a layer on top of the entities namespace to perform the required queries whenever a 
document is saved or loaded.

Time related utility functions

API Route definitions for administrative purposes.  These are not available
in the general api and are meant to be used by system administrators or
system processes only.

Specific customer api routes

API functions for customer join requests

Api functions for managing build parameters

Authentication and authorization functions

Bitbucket specific endpoints, mainly for authentication or push callbacks.

Functionality specific for Github

Handler for the web server

OAuth2 flow support handlers