Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Deployment

How the Disability Registry is packaged, where its source and artifacts live, and what each published image contains.

The Disability Registry is not a registry built from scratch. It is a thin extension of the OpenG2P Registry Platform, which publishes the runnable Docker images and the openg2p-registry Helm chart. This repository adds only the disability domain on top.

The packaging model — why the platform publishes the artifacts and a domain registry extends them — is described once, in the platform docs: Deployment and Extension. This section covers only what is disability-specific.

Where everything lives

Artifact
Location

Source code

github.com/OpenG2P/disability-registry

Docker images

openg2p/openg2p-disability-registry-<name> on Docker Hub

Helm chart

openg2p-disability-registry, published to the shared openg2p-helm Helm repository

Platform chart it extends

openg2p-registry, same registry, pinned as a dependency

CI

GitHub Actions, calling openg2p-packaging@v1 — all versioning, build and publish logic is central

One pipeline derives one version from git for the whole commit, builds every image, rewrites the chart's image tags to that version, generates questions.yaml from the pinned platform chart, and publishes. Images and chart therefore always ship at the same version.

Published images

Five images are built here. Each is a ~10-line FROM of the matching platform image plus the domain package; the runtime, entrypoint and CMD are inherited.

Image
Runs as
Contains

staff-api

Staff Portal API

The domain model + the platform's staff API. Serves the staff portal; runs the database migration on start

partner-api

Partner API

The domain model + the platform's partner API. Answers DCI searches — renders records through the outbound template and clamps them to the consented scopes

celery

Worker and beat

Both celery codebases; which one runs is chosen at deploy time by CELERY_APP. Drains the completion-score queue and computes the SUPPORT_NEED score

db-seed

Install/upgrade Job

The seed SQL (registers, screens, code lists, approval policies), the DCI templates, the sample-data loader, and this registry's reporting views + reporting.yaml

sanity-tests

Post-install Job

The platform's test harness and generic tests, overlaid with this registry's field-specific e2e tests

Two more are consumed as-is from the platform, because they carry no domain code: staff-ui (the staff portal front end) and bene-api.

db-seed ships its own sample-data loader and image uploader. The platform's are written against the reference registry's tables and would crash-loop here. Genuinely generic parts — the entrypoint, geo loader, code-list loader, geo-widget sync, template uploader — are inherited unchanged.

The chart

openg2p-disability-registry is a wrapper: a pinned dependency on openg2p-registry plus a values overlay. It owns no service templates — deployments, services, ingress, IAM/Keycloak wiring and the db-seed machinery all come from the subchart.

It does own the analytics layer, because the reporting views and dashboards are written against this registry's schema and the platform has no concept of them:

Template
Purpose

analytics-jobs.yaml

Reporting-views and dashboard-import Jobs

reporting-views-refresh.yaml

CronJob refreshing the materialized views hourly

dashboard-bundle-configmap.yaml

Ships dr-dashboards.zip into the cluster

maps-content-configmap.yaml

Map queries and page for G2P Insights

superset-service-account-secret.yaml

The Superset service account

Version pinning

The platform version is pinned in two places that move together: RP_VERSION in each Dockerfile (the base image tag) and the openg2p-registry dependency in Chart.yaml. Nothing about the platform is vendored or copied.

test/test_rp_pin_lockstep.py fails the build if they ever drift — a chart on one platform version with images built against another lands the sanity overlay on a harness it does not match.

Install order

Helm hook weights sequence the whole install:

Weight
Job
Does

10

db-seed

Registers, screens, code lists, templates, approval policies, sample data

19–20

iam-register

Registers the roles→permissions catalogue into IAM

25

sanity

The e2e suite

45

reporting-views

Hand-written views, then the generated ones

49–50

dashboards

Imports the Superset bundle and enables embedding

The analytics chain sits above the sanity suite deliberately: the suite asserts against its own injected fixture, and rebuilding the views underneath it would change what it is checking.

The db-seed Job waits for AWE to be healthy before it runs. If AWE is down, db-seed blocks, Helm's install timeout expires, and the release is marked failed before the sanity Job is ever created. If you see no sanity Job at all, check db-seed and commons-services first.

Next

PreviousDashboards and maps
NextDeploying on Rancher

Last updated

Was this helpful?