Add R API container to dev dependencies script, and consume R API from app

.env.example

@@ -1,2 +1,2 @@
-CI=0
 DATABASE_URL="postgresql://daedalus-web-app-user:changeme@localhost:5432/daedalus-web-app"
+NUXT_R_API_BASE=http://localhost:8001/

.github/workflows/integration-tests.yml

@@ -0,0 +1,36 @@
+name: Integration tests
+on:
+  push:
+    branches:
+      - main
+  pull_request:
+    branches:
+      - '*'
+jobs:
+  test:
+    timeout-minutes: 60
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+      - name: Set up Node
+        uses: actions/setup-node@v4
+        with:
+          node-version: 20
+          cache: npm
+      - name: Install dependencies
+        run: npm ci
+      - name: Start API server with Mockoon to mock R API
+        uses: mockoon/cli-action@v2
+        with:
+          data-file: ./mocks/mockoon.json
+          port: 8001
+      - name: Check mocked R API server is running
+        run: curl -s http://localhost:8001/mock-smoke
+      - name: Set environment variables for app
+        run: scripts/ci/copy-env-vars-to-dot-env-file
+        env:
+          NUXT_R_API_BASE: ${{ vars.NUXT_R_API_BASE }}
+          # Note - non-secret variables are stored under the 'vars' context, while secrets will be stored under the 'secrets' context
+      - name: Test
+        run: npm run test:integration

.github/workflows/playwright.yml

@@ -1,4 +1,4 @@
-name: Playwright Tests
+name: Playwright tests
 on:
   push:
     branches:
@@ -13,12 +13,19 @@ jobs:
     steps:
       - name: Checkout
         uses: actions/checkout@v4
+      - name: Set environment variables for app
+        run: scripts/ci/copy-env-vars-to-dot-env-file
+        env:
+          NUXT_R_API_BASE: ${{ vars.NUXT_R_API_BASE }}
+          # Note - non-secret variables are stored under the 'vars' context, while secrets will be stored under the 'secrets' context
+      - name: Run service dependencies
+        run: scripts/run-dependencies
       - name: Set up Node
         uses: actions/setup-node@v4
         with:
           node-version: 20
           cache: npm
-      - name: Install dependencies
+      - name: Install npm dependencies
         run: npm ci
       - name: Install Playwright Browsers
         run: npx playwright install --with-deps && npx playwright install msedge

.github/workflows/unit-tests.yml

@@ -1,4 +1,4 @@
-name: Test
+name: Unit tests
 on:
   push:
     branches:
@@ -20,6 +20,11 @@ jobs:
           cache: npm
       - name: Install dependencies
         run: npm ci
+      - name: Set environment variables for app
+        run: scripts/ci/copy-env-vars-to-dot-env-file
+        env:
+          NUXT_R_API_BASE: ${{ vars.NUXT_R_API_BASE }}
+          # Note - non-secret variables are stored under the 'vars' context, while secrets will be stored under the 'secrets' context
       - name: Test
         run: npm run test:unit:coverage
       - name: Upload coverage to codecov

.nvmrc

@@ -0,0 +1 @@
+v20

README.md

@@ -2,79 +2,96 @@
 
 npx nuxi analyze
 
-# Env vars
-
-CI=0 or CI=1
-
 # Tests
 
-Run unit tests and component tests:
+To run unit tests:
 ```bash
 npm run test:unit
 # Or with coverage:
 npm run test:unit:coverage
 ```
 
+To run integration tests, first start the Mockoon server:
+```bash
+npx mockoon-cli start --data ./mocks/mockoon.json
+```
+Then run:
+```bash
+npm run test:integration
+```
+
 Run server-side rendering tests:
 ```bash
 npm run test:ssr
 ```
 
 Run full-stack tests:
+
+1. Ensure Mockoon server is not running
+1. Run:
 ```bash
 npm run test:e2e
 ```
 
 The tests under e2e, which are run by playwright, are for testing the full-stack (client app and server app) in a browser environment. Since the server-rendered page may be different from the client-rendered page, for example, when some elements are configured to only render on the client side, relevant tests should wait for the elements to be present.
 
-## Local development
+# Local development
 
-### Setup
+## <a id="first-time"></a> Your first time setting up
 
 Use Node 20.
-Have Docker installed.
-Copy `.env.example` to `.env`.
-Build and run the database container:
+
+Make sure Docker is installed.
+
+Build and run the database container and R API container using this script:
 
 ```bash
-./db/scripts/build
-./db/scripts/run
+scripts/run-dev-dependencies
 ```
 
-Install the JS dependencies:
+If you have trouble with the R API image, there might be helpful information in [its own README](https://github.com/jameel-institute/daedalus.api).
+
+Run the below to copy `.env.example` to `.env` and then run the `dev:init` command, which installs the JS dependencies, runs any pending database migrations, and starts up the server in development mode on `http://localhost:3000`:
 
 ```bash
-npm install
+cp .env.example .env
+npm run dev:init
 ```
 
-Prisma ORM can only query the database once you 'generate' the Prisma Client, which generates into `node_modules/.prisma/client`. This should happen when you install the JS dependencies and whenever you run a migration, but if the Prisma client gets out of sync or doesn't generate, you can manually generate it:
+## Everyday development workflow
+
+If you've already done ['Your first time setting up'](#first-time), you can quickly get back to work by:
 
 ```bash
-npx prisma generate
+# In one terminal window
+scripts/run-dev-dependencies --db-build-skip # Skips the build step for the db container, and tries to run an existing image
 ```
 
-Start the development server on `http://localhost:3000`:
-
 ```bash
+# In another terminal window
 npm run dev
 ```
 
-You can also expose it to your local network, so that you can try it out on a mobile device, using:
+## Other ways of serving the app and dependencies
+
+You can also expose the app to your local network, so that you can try it out on a mobile device, using:
 
 ```bash
 npm run dev -- --host
 ```
 
 The QR code shown will allow you to quickly access the app.
 
-### DB
+See the 'production' section of this README for how to run the app in production mode.
+
+# DB
 
 Our ORM is [Prisma](https://www.prisma.io/).
 
 To create migrations to the database, first update the Prisma schema at ./prisma/schema.prisma as required, then run the below command to generate the corresponding SQL migration and to apply it to the database. [You should commit both](https://www.prisma.io/docs/orm/prisma-migrate/workflows/team-development#source-control) the Prisma schema and the migration file to Git.
 
 ```bash
-npx prisma migrate dev
+npm run db:dev:migrate
 ```
 
 The same command is also used to apply migrations that already exist in ./prisma/migrations but which have not been applied to the database.
@@ -87,15 +104,15 @@ npx prisma generate
 
 More helpful information about Prisma [development workflows](https://www.prisma.io/docs/orm/prisma-migrate/workflows/development-and-production#customizing-migrations) and resolving issues in [production environments](https://www.prisma.io/docs/orm/prisma-migrate/workflows/patching-and-hotfixing#fixing-failed-migrations-with-migrate-diff-and-db-execute).
 
-#### For your IDE
+## For your IDE
 
 In VSCode, you can use the extension with ID 'Prisma.prisma' to get syntax highlighting etc.
 
-## Linting and formatting
+# Linting and formatting
 
 Linting and formatting are handled jointly by [@nuxt/eslint](https://eslint.nuxt.com/packages/module) (an "all-in-one" ESLint "integration" for Nuxt) and by the more frequently-updated, conventionally- and widely-used [@antfu/eslint-config](https://github.com/antfu/eslint-config) (antfu works at NuxtLabs, and the package is given as an example in the `@nuxt/eslint` docs). The former handles linting only, while the latter also handles formatting, based on ESLint Stylistic.
 
-### Commit hook
+## Commit hook
 
 You should install the lint-fixing commit hook (which will apply to this repo only) using:
 
@@ -105,24 +122,24 @@ npx simple-git-hooks
 
 This will help us keep git history tidy, avoiding clogging up `git blame`s with linting-only commits.
 
-### Inspecting the linting rules
+## Inspecting the linting rules
 
 This is a helpful tool for inspecting your config setup, so you can check which rules are applied, in which order:
 ```bash
 npx @eslint/config-inspector
 ```
 
-### For your IDE
+## For your IDE
 
 In VSCode, [make sure](https://eslint.nuxt.com/packages/module#vs-code) your ESlint VS Code extension (vscode-eslint) is at least v3.0.10 (released June 2024). Turn on the 'Format on Save' setting.
 
-## CI
+# CI
 
 Playwright tests produce HTML reports when they run, whether on CI or not, showing visual snapshots at each timestep in each test. If you need to open these, follow the instructions [here](https://playwright.dev/docs/ci-intro#html-report), particularly '[Viewing the HTML report](https://playwright.dev/docs/ci-intro#viewing-the-html-report)'.
 
-## Production
+# Production
 
-Build the application for production:
+Build the Nuxt application for production:
 
 ```bash
 npm run build

components/SideBar.vue

@@ -42,7 +42,13 @@
       <!-- Use CoreUI Sidebar Header component instead of footer so that stylings for CoreUI Sidebar Brand component work -->
       <CSidebarBrand>
         <div class="sidebar-brand-full">
-          <img class="img-fluid mb-1" src="~/assets/img/IMPERIAL_JAMEEL_INSTITUTE_LOCKUP-p-500.png" alt="Imperial College and Community Jameel logo">
+          <img
+            data-testid="logo"
+            class="img-fluid mb-1"
+            :title="versionTooltipContent"
+            src="~/assets/img/IMPERIAL_JAMEEL_INSTITUTE_LOCKUP-p-500.png"
+            alt="Imperial College and Community Jameel logo"
+          >
         </div>
       </CSidebarBrand>
     </CSidebarHeader>
@@ -51,38 +57,47 @@
 
 <script lang="ts" setup>
 import { CIcon } from "@coreui/icons-vue";
+import type { VersionData } from "@/types/daedalusApiResponseTypes";
+
+const { data: versionData } = useFetch("/api/versions") as { data: Ref<VersionData> };
+
+const versionTooltipContent = computed(() => {
+  if (versionData.value) {
+    return `Model version: ${versionData.value.daedalusModel} \nR API version: ${versionData.value.daedalusApi} \nWeb app version: ${versionData.value.daedalusWebApp}`;
+  } else {
+    return undefined;
+  }
+});
 
 const visible = defineModel("visible", { type: Boolean, required: true });
 const largeScreen = ref(true);
 
+const breakpoint = 992; // CoreUI's "lg" breakpoint
+const resetSidebarPerScreenSize = () => {
+  // Set the default values for the sidebar based on the screen size.
+  if (window.innerWidth < breakpoint) {
+    visible.value = false;
+    largeScreen.value = false;
+  } else {
+    visible.value = true;
+    largeScreen.value = true;
+  }
+};
+
 const hideHasNeverBeenEmitted = ref(true);
-function handleHide() {
+const handleHide = () => {
   if (hideHasNeverBeenEmitted.value) {
     // If this is the first 'hide', which is emitted on page load, we un-do it.
     // This is because the CoreUI Sidebar component emits a 'hide' event on page load, which we
     // don't want to obey for larger screen sizes.
     resetSidebarPerScreenSize();
     hideHasNeverBeenEmitted.value = false;
-  }
-  else {
+  } else {
     // If this is not the first 'hide', emitted on page load, we obey it and sync
     // the parent component's value.
     visible.value = false;
   }
-}
-
-const breakpoint = 992; // CoreUI's "lg" breakpoint
-function resetSidebarPerScreenSize() {
-  // Set the default values for the sidebar based on the screen size.
-  if (window.innerWidth < breakpoint) {
-    visible.value = false;
-    largeScreen.value = false;
-  }
-  else {
-    visible.value = true;
-    largeScreen.value = true;
-  }
-}
+};
 
 onMounted(() => {
   window.addEventListener("resize", resetSidebarPerScreenSize);

components/WebsocketConnection.client.vue

@@ -23,8 +23,7 @@
 function checkConnectionStatus() {
   if (socket.connected) {
     onConnect();
-  }
-  else {
+  } else {
     onDisconnect();
   }
 }

db/Dockerfile

@@ -20,8 +20,5 @@ RUN chown -R postgres:postgres /etc/daedalus-web-app
 ENV PATH="/usr/local/bin:$PATH"
 RUN docker-entrypoint.sh --version
 
-# Ensure the start script is executable
-RUN chmod +x /daedalus-web-app-bin/start-with-config.sh
-
 ENTRYPOINT ["/daedalus-web-app-bin/start-with-config.sh"]
 CMD ["/etc/daedalus-web-app/postgresql.conf"]

db/bin/wait-for-db

@@ -0,0 +1,37 @@
+#!/usr/bin/env bash
+
+# Copied from https://github.com/mrc-ide/packit/blob/main/db/bin/wait-for-db
+
+wait_for()
+{
+    echo "waiting up to $TIMEOUT seconds for postgres"
+    start_ts=$(date +%s)
+    for i in $(seq $TIMEOUT); do
+        # Using pg_ready as:
+        #
+        #   pg_isready -U $POSTGRES_USER -d $POSTGRES_DB
+        #
+        # seems heaps nicer but does not actually work properly
+        # because it pulls us up to soon.
+        psql -U $POSTGRES_USER -d $POSTGRES_DB -c "select 1;" > /dev/null 2>&1
+        result=$?
+        if [[ $result -eq 0 ]]; then
+            end_ts=$(date +%s)
+            echo "postgres is available after $((end_ts - start_ts)) seconds"
+            break
+        fi
+        sleep 1
+        echo "...still waiting"
+    done
+    return $result
+}
+
+# The variable expansion below is 100s by default, or the argument provided
+# to this script
+TIMEOUT="${1:-100}"
+wait_for
+RESULT=$?
+if [[ $RESULT -ne 0 ]]; then
+  echo "postgres did not become available in time"
+fi
+exit $RESULT

db/conf/postgresql.test.conf.in

@@ -1,4 +1,4 @@
-# Copied from db/conf/postgresql.test.conf.in
+# Copied from https://github.com/mrc-ide/packit/blob/main/db/conf/postgresql.test.conf.in
 # ----------------------------------------------------------------------------
 # Test database config begins here.
 # Values here override those earlier in the file