chore(release): 0.14.0

See merge request !81

feat: correct password app reset token call and handle missing users

See merge request !80

chore(release): 0.13.0

See merge request !79

Resolve "Add an endpoint that gets a new reset token for the authenticated user"

Closes #25

See merge request !77

chore(release): 0.12.0

See merge request !75

Allow data-manager API to be read only

See merge request !74

Adds a setting to set the data manager internal API to read-only
mode. This updates that API to be read-only by default. Environments
have to explicitly configure the data manager API to allow write.

chore(release): 0.11.1

See merge request !72

fix: ensure OpenAPI packages are published for tagged releases

See merge request !73

The default OpenAPI package publication rules do not trigger for us
since we do not ship a static OpenAPI schema. Override the publication
rules to match our needs.

fix: docker build by explicitly installing poetry-plugin-export

See merge request !71

chore(release): 0.11.0

See merge request !70

feat: add endpoint for data manager to create/update/delete accounts

See merge request !69

chore(release): 0.10.0

See merge request !67

feat: move to upstream OpenAPI generator template

Closes #22

See merge request !68

Now that uis/devops/continuous-delivery/ci-templates#93 is closed, we
have a generic OpenAPI generator template. Make use of it.

Closes #22

auto-generate API clients, package them, publish them and publish docs to GitLab pages

See merge request !66

The common CI pipeline has support for mkdocs-based documentation and so
add a basic generated mkdocs config. Base the mkdocs config on the
config which is likely to land in the copier template to minimise future
disruption.

We need to override some parts of the standard jobs to "inject" the
documentation generated by the OpenAPI templates into them. We also need
to add "fake" index.html files which take the place of the real
documentation which will be injected in.

Add jobs which publish generated OpenAPI clients to GitLab's own package
registry. In time we may add ones which publish directly to npm and/or
PyPI but for the moment keep things simple.

Packages are only published if the git ref name matches a specific
value. By default it is the default branch but it can be customised for
advanced users.

Generate documentation for each of the OpenAPI clients along with
redoc-based documentation for the schema itself. Downstream projects
should arrange to copy this documentation to some appropriate place.

We add generic "document a TypeScript project" and "document a Python
project" jobs along with specialisations for each of the clients we
generate.

All documentation ends up in `OPENAPI_GENERATOR_DOCS_ARTIFACT_DIR` which
can be overridden by consuming projects.

Use the openapi-generator CLI to generate and package a TypeScript
client using axios for HTTP transport and a Python package using urllib3
for transport. The version numbers of the generated packages match the
version number of the generated OpenAPI schema.

As the OpenAPI generator is intended to be generic, we configure a
reasonable set of defaults for generated artefact names, etc. Show how
these can be customised in local configuration to specify alternate
locations for schema files and source packages to be added as release
assets. Add the generated API clients as release assets.

The list of generated clients is supposed to be slightly opaque to the
consuming project so that we may add additional clients over time.
Should that prove troublesome, each client may be explicitly disabled by
setting a generator-specific `..._DISABLED` variable.

The package name is generated from the GitLab project name but can be
overridden. We do so in our case since the project name ("api") is a
little under-descriptive.

As with generation, we support per-client overriding of the package name
which we demonstrate with the Python package.