app: Update template-application-flask to version 0.2.0.post33.dev0…

…+6c6ec54

.template-application-flask/app.yml

@@ -1,5 +1,5 @@
 # Changes here will be overwritten by Copier
-_commit: v0.2.0-32-g5e43ed2
+_commit: v0.2.0-33-g6c6ec54
 _src_path: https://github.com/navapbc/template-application-flask
 app_local_port: 8080
 app_name: app

docs/app/getting-started.md

@@ -32,7 +32,7 @@ A very simple [docker-compose.yml](/app/docker-compose.yml) has been included to
 
 ## (Optional) Configure local secrets
 
-If you need to pass secrets to the application via environment variables, copy the provided [/app/docker-compose.override.yml.example](/docker-compose.override.yml.example) to `/app/docker-compose.override.yml`. Then create an `/app/.env` file with your secrets. The override will pass this file to the Docker container with your application.
+If you need to pass secrets to the application via environment variables, copy the provided [docker-compose.override.yml.example](/app/docker-compose.override.yml.example) to `/app/docker-compose.override.yml`. Then create an `/app/.env` file with your secrets. The override will pass this file to the Docker container with your application.
 
 ```bash
 cp docker-compose.override.yml.example docker-compose.override.yml

docs/decisions/0003-keep-generated-openapi-spec-to-source-control.md

@@ -18,6 +18,6 @@ With the switch from Connexion to APIFlask (see [Connection replacement ADR](./0
 
 We chose to keep the openapi.yml file in source control because we want changes to the API to be called out explicitly so that developers do not accidentally make backwards-incompatible changes to the API as part of a code change. This is particularly important since the API spec is now implicit as the OpenAPI specification is automatically generated from the code.
 
-We chose to keep the openapi.yml file in sync with the API application automatically using a [CI workflow that generates the OpenAPI and pushes and changes to the PR branch](../../.github/workflows/ci-openapi.yml). This reduces the amount of manual work required by the engineer compared to a CI check that only checks for diffs but does not make the change. That said, we don't feel strongly about this decision so are open to changes in the future.
+We chose to keep the openapi.yml file in sync with the API application automatically using a CI workflow that generates the OpenAPI and pushes and changes to the PR branch (`.github/workflows/ci-<APP_NAME>-openapi.yml`). This reduces the amount of manual work required by the engineer compared to a CI check that only checks for diffs but does not make the change. That said, we don't feel strongly about this decision so are open to changes in the future.
 
 To minimize developer confusion, we chose to rename the `openapi.yml` file to `openapi.generated.yml` to clearly indicate that it is a generated file and not something that the developer should manually adjust.