feat: initialise repository

Marc Brouard
2026-04-30T13:45:16Z

Part of: https://gitlab.developers.cam.ac.uk/uis/devops/iam/admin/-/work_items/354

Description

Initialise repository, uses the standard webapp copier template (at version 5.2.8) to initialise. Note that intialisation was then heavily modified to fit use-case, and therefore the .copier-answers file has been removed as further copier updates would not be valuable.

Changes Made

Supporting files added based on standard webapp copier template

Review Checklist

Reviewers should check each item in the below checklist. At a reviewers discretion, some items can be skipped (e.g. documentation only MRs do not need to have tests).

If you feel you can't completely verify any of the below items, or if you simply want a second pair of eyes on an MR, the initial reviewer should message the dev team or ping potential additional prospective reviewers in a comment.

The changes made meet the acceptance criteria in the linked issue, or the rationale for not meeting the acceptance criteria is appropriate and correct.

The code changes conform to general and our internal style and quality expectations.

Code should be idiomatically consistent with the language.

Function and variable names are correct.

Functions are purposeful, i.e. split down into smaller functions for re-use or to meaningfully improve readability (e.g. avoid single-line functions).

Logical complexity is minimised where possible.

Complex logic is explained with comments.

Changes that will affect the operation or usage of the application from an operational or developer are explained in the README, if they deviate from standard DevOps wide approaches, boilerplate, etc.

The commits are logically self-contained, and conform to conventional commit format.

Commits without the feat or fix type (e.g. chore or ci) are used appropriately, e.g. they are for:

Documentation-only commits.

CI changes that will not affect the built image in any way.

Developer environment changes that will not affect the built image in any way.

If the change will be a breaking change it is marked as such.

Breaking changes should be avoided where possible.

Breaking changes include changes that require updates to the infrastructure in order to be deployed successfully (e.g. new required configuration items)

Correct tests been added to fully exercise new business logic.

No tests have been added which only exercise external/3rd party logic (e.g. testing that a 500 response is returned on exceptions and no other exception handling behaviour is present, etc.). Tests should exist to ensure our wiring and plumbing is correct.

Tests exercise functionality to the logical boundaries, i.e. do not over-mock.

The poe up/npm run up command correctly runs and starts the container.

Migrations run (if present).

The added functionality can be demonstrated locally.