The App lifecycle
How humus.Main builds a humus.App, and how the App reads its settings, builds its telemetry and its dependencies, runs its Services, drains and shuts them down within a grace period and turns the outcome into an exit status.
Fundamentals
What every humus service has, whatever it serves: the App lifecycle that runs it, its configuration, its telemetry, its health and its tests.
Every humus service, whatever it serves, runs the same App. These pages cover
what that App does, in the order a service meets it: the lifecycle that
builds and runs it, how its settings get their values, the OpenTelemetry
providers it hands to Init, the health Service that owns its readiness, and
how to run the whole App inside a test.
Configuring a humus service
How a humus service’s settings get their values: humus packages take plain Go values, and the service’s Init sources each one, usually with bedrock’s config package, so that a bad value fails startup with exit 78 and an error naming the variable.
Telemetry
How a humus service gets its OpenTelemetry providers: the end user’s Builder sources telemetry.Settings and calls telemetry.New, the App hands the SDK to Init, and humus never reads or sets OpenTelemetry’s globals.
Health
How a humus service reports its health: monitors and how they combine, what liveness and readiness each check, the health Service that owns an App’s readiness through the lifecycle, and how httphealth and grpchealth expose the probes to Kubernetes, attached to a server the pod runs or on a probes port, with their answers, manifests, startup probes and tests.
Testing a humus App
How to run a whole humus App inside a test with humustest.Start: the App humus.Main would run, under synctest, with no real socket, no file outside the test’s temp directory and no secret in the repository.