Review apps and index.html pages (and cors)

Hi there,

I’m using Gitlab pages and review apps for a couple of static site generators for myself and my day job. pages works great, but we’re having trouble with review apps. They deploy to specified URLs without difficulty, but they’re not that usable for two reasons:

  1. whatever webserver serves review apps does not default to index.html when a url specifies a directory,
  2. in some cases, the server also seems to send all resources (including *.css and *.js files) with a mime type of text/html, which causes CORS errors.

So my questions basically are:

  1. are review apps served from the image specified in the .gitlab-ci.yml file (In which case, we should be able to configure the server to solve these issues)?
  2. or are they served from some gitlab.com infrastructure (and if so, can we influence the above issues)?

Hi,

can you share the .gitlab-ci.yml configuration for the review apps you are using? Review apps can be deployed in different environments (Kubernetes, OpenShift, Nginx VM, etc.) hence the question to clarify this first.

Cheers,
Michael

Hi there,

The one I was working on when I created the post looks like this (adapted from the Gatsby Pages example since it’s also an npm-based static app):

---
image: "node:lts-alpine"

stages:
  - build
  - review

cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - .cache/
    - node_modules/
    - public/

yarn:install:
  stage: build
  script:
    - yarn install --frozen-lockfile --check-files --non-interactive
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - if: $CI_MERGE_REQUEST_ID

review:
  stage: review
  needs: ["yarn:install"]
  script:
    - echo '🤖 Starting review app'
    - echo "🤖 https://${CI_PROJECT_NAMESPACE}.gitlab.io/-/${CI_PROJECT_NAME}/-/jobs/${CI_JOB_ID}/artifacts/public/index.html"
    - yarn build
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_MERGE_REQUEST_ID
  environment:
    name: preview/${CI_PROJECT_NAME}/${CI_COMMIT_REF_NAME}
    url: https://${CI_PROJECT_NAMESPACE}.gitlab.io/-/${CI_PROJECT_NAME}/-/jobs/${CI_JOB_ID}/artifacts/public/index.html
    on_stop: review:stop

review:stop:
  stage: review
  rules:
    - if: $CI_MERGE_REQUEST_ID
      when: manual
  allow_failure: true
  environment:
    name: preview/${CI_PROJECT_NAME}/${CI_COMMIT_REF_NAME}
    action: stop
  script:
    - echo '🤖 Terminating review app'

Thanks, so the review app uses GitLab pages with

url: https://${CI_PROJECT_NAMESPACE}.gitlab.io/-/${CI_PROJECT_NAME}/-/jobs/${CI_JOB_ID}/artifacts/public/index.html

and the project has Pages enabled/configured. It makes assumptions on URL resolving.

A more fine granular webserver configuration can be used when running the app in your own container, or provide a web server up front in a VM. This is where container platforms like Kubernetes come in handy, or a dedicated VM which manages the NGinx webserver in front of your app deployment. This is something you’ll need to bring in yourself, and replace the pages config in the review apps setup. Here are more review app examples.

Cheers,
Michael

Thanks for the examples! I hadn’t found those. Route maps are also feature we may be able to make use of.

Actually, this is exactly what I do not see: pages works as expected, review apps work as I described in the OP (i.e. CORS errors, not defaulting to index.html when given a url containing a directory path).

In fact, now that I look closely, there are two static sites with identical Pages and Review configuration, and with them:

  • neither defaults to index.html in Review,
  • only one has CORS errors in Review,
  • both work perfectly in Pages

Given they do work in production (i.e. on Pages), review apps not working is no big emergency. I’m mostly trying to figure out what Review apps can be used for on Gitlab infrastructure (since even these plain static sites don’t work very well).

There’s an open feature request around Review apps and Pages. “Merging” both in the way you have shown is not officially supported to my knowledge, and the problems you are seeing might be related to that “untested scenario”.

Recommend sharing your ideas in the issue too :slight_smile:

Ahh, thanks. I don’t think we knew this.

Is there a supported way to do review apps on Gitlab infrastructure at all?