the frontend for the frischmuth project. deployed at https://frischmuth-frontend.acdh-ch-dev.oeaw.ac.at/. development version deployed at https://frischmuth-frontend-dev.acdh-ch-dev.oeaw.ac.at/.
prerequisites:
Tip
you can use pnpm
to install the required node.js version with pnpm env use 20 --global
set required environment variables in .env.local
:
cp .env.local.example .env.local
also, set environment variables required by github actions. use
"variables" for every
environment variable prefixed with NUXT_PUBLIC_
, and
"secrets" for all
others.
install dependencies:
pnpm install
run a development server on http://localhost:3000:
pnpm run dev
- ask a sysadmin to create a new acdh-ch kubernetes project.
- create a new namespace in that project via rancher, and set
the
KUBE_NAMESPACE
github variable to that namespace. - adjust the
app_name
, which will be the name of the deployment in the above namespace. - set the
PUBLIC_URL
github variable to the application's public url (e.g. "https://my-app.acdh-ch-dev.oeaw.ac.at"), and set theKUBE_INGRESS_BASE_DOMAIN
to the public url's base domain (e.g. "acdh-ch-dev.oeaw.ac.at"). - create a service issue in the acdh-ch redmine issue tracker,
and set the
SERVICE_ID
github variable to the issue number. this should match theNUXT_PUBLIC_REDMINE_ID
variable in your.env.local
file. - ensure required build args (prefixed with
NUXT_PUBLIC_
) are referenced in both theDockerfile
, as well as the validation and deployment pipelines, and set as github variables. - ensure required runtime environment variables are referenced in the
validation and
deployment pipelines, and set as github secrets. github
secrets need to be prefixed with
K8S_SECRET_
to be automatically copied to the runtime environment. in case you need secrets in the docker build context, you can mount a secret in the Dockerfile. - to enable runtime override of public
runtimeConfig
build values through runtime env vars note the naming conventions.
Important
this is a feature exclusive to nuxt 3. for most deployment scenarios it is not needed, but it can be useful for deploying multiple instances from a single build.
- ensure both the github repository, and the package registry is set to public.
if everything is set up correctly, every git push to the main
branch will create a new deployment
if the validation pipeline passes.
you can reference the template repository for a working setup.