Skip to content

Expose root_directory as part of a pages deployment's lookup_path

What does this MR do and why?

Resolves #398144 (closed)

This MR adds a new property root_directory to the Pages Deployment table and the API response.

Why is this change being made?

The full context: &10126

TL;DR: Currently the static files that GitLab Pages exposes need to be an artifact that contains a folder named public. Since artifacts are a generic pipeline feature (not specific to pages) they will happily accept any path. But Pages itself is more strict and will only expose files if they're in a root folder named public. This info is not included in the pipeline validation. This has always caused a lot of confusion.

But rather than simply adding a pipeline validation, this MR is the second step in removing the requirement altogether (with !115340 (merged) being the first).

How is it implemented?

This MR introduces the root_directory property as part of a PagesDeployment::LookupPath.

The value is a single string. It is being defined as part of the pages job inside the CI/CD Config. It is subsequently stored as a property of the pages_deployment and exposed via the internal Pages API.

A separate MR in GitLab Pages will have Pages use this value to determine the root folder within the stored artifact to deliver Pages from (at this time the root directory is hardcoded as public)

How to set up and validate locally

  1. Ensure all migrations have run with bin/rails db:migrate RAILS_ENV=development
  2. Ensure your Pages installation is running locally.
  3. Create a pages deployment, for example by cloning this example repository: https://gitlab.com/pages/plain-html
  4. Wait for the Pipeline to be completed.
  5. Verify that the database table pages_deployments now includes a column root_directory, and your newly created deployment contains the default value "public" in this column
  6. Access the internal API and verify the following request contains the value public at lookup_paths[0].root_directory:
GET /api/v4/internal/pages?host=<the project's pages domain> HTTP/1.1
Gitlab-Pages-Api-Request: <API Token>
Host: gdk.test:3000
  1. Change the value in the database and verify the API response changes accordingly.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

(this MR has been re-created to avoid an issue with a changed DB column in the same migration)

Edited by Janis Altherr

Merge request reports