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.

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.

This namespace provides low-level functions.  For more user-friendly functionality,
check out the `monkey.ci.build.v2` namespace.

Low-level API functions to invoke shells from your build scripts.

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.  It provides some defaults and
accessor functions.  It mainly uses aero to reduce duplication in the configuration
and merge multiple config files into one.

Functionality for printing to the console, probably using ANSI coloring.

Generic functionality for running containers

Kubernetes implementation to run container jobs.

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

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

The container dispatcher is responsible for picking pending container jobs or builds
from a table, and assigning them to one of the available runners (either build or
job).  Since builds and container jobs both require containers, and as such compete
for the same resources, they are merged into one by this dispatcher.  Pending tasks
(as we could call them) are saved in a table.  This table is checked by the dispatcher
whenever a `job/pending`, `build/pending`, `job/end` or `build/end` event is received.
Depending on its strategy, it picks the next task (or tasks) to start and dispaches
them to the registered runners, according to the available resources and requirements.

For example, some runners only support certain architectures, while others only have
limited resources available.  Some runners can have priority over others, probably to
reduce costs (i.e. we would use the k8s runner before an oci runner).

The table is required to be able to pick from multiple waiting tasks, as opposed to
an event queue, which will only allow to process them in sequence.  Storing this
in memory is not an option, since multiple replicas also mean multiple dispatchers.
So this table is a way for them to sync up.  It also keeps data over restarts.

Both builds and container jobs require infra resources to run, so it's logical that
there is some sort of coordination.  Various approaches are possible, but for now we
have chosen the simplest approach: a single process is responsible for allocating the
resources.  It polls from the job and build topics as long as resources are available.
If no more resources are available, it stops polling.  Normally resources should become
available again, and polling can resume.  Any containers that are unassignable because
they make requirements that can never be met (e.g. too many cpu's), are immediately 
marked as failed.

The available resources can be requested by the dispatcher, but for efficiency's sake
it would be better that this information is kept locally, and updated by received
events (`build/start`, `job/start`, `build/end` and `job/end`).

Http endpoints for the dispatcher.  Mainly for monitoring.

Main class for the dispatcher, used when running as a microservice

Runtime components for executing the dispatcher

Event state management functions

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.

Common event builders

Functions for doing events over http

Mailman-style event handling

Mailman implementation that uses the build api for event posting and
receiving.  This is used by the build script.

Event handlers that write stuff to the database

General purpose interceptors

JMS-specific functionality for handling events.  This has mainly to do with
queue and topic configurations and listeners.

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

Kubernetes functionality, used by build and container runners.

Configuration management functions for local builds

Event handlers for console reporting

Event routes for local build runners.  When running a build locally via cli,
these routes will be registered in mailman and will perform all necessary
build steps.

Running a local build uses the same event flow as server-side builds.
Depending on the configuration, routes may differ (e.g. different handlers
or interceptors).  A local build can either run in a child process, or it
can run in a container.  In any case, the container jobs are run in containers
and action jobs are run by the script process.

Blobs (artifacts, caches) are always stored locally, but this can vary
depending on configuration.  If run in a container, a volume can be used.

The build controller, responsible for managing build params and events, is
run in the main process.  Builds connect to it using http, same as for 
server-side builds.

Set up runtime for local builds

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.

Event handlers that update metrics

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.

Functions for running the application as a controller.

Another implementation of a job runner that uses OCI container instances.
This one uses mailman-style events instead of manifold.  This should make
it more robust and better suited for multiple replicas.  Instead of waiting
for a container instance to complete, we just register multiple event 
handlers that follow the flow.

Creates a runtime component that is used by the controller.

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.

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

This namespace is being phased out in favor of passing specific information
to components directly, since passing around too much information is an
antipattern.

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

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

Mailman event routes for scripts

Functions for creating a runtime for build scripts

Functions for working with storage ids

Functions for handling sidecar configuration

Sidecar specific functions

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

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

Custom spec generators

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

Functions related to encryption/decryption of data using a vault

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

Http server component

Middleware for web requests.  Could be that we move this to interceptors later.

OAuth2 flow support handlers