Skip to content

Draft: Expose root_directory as part of a pages deployment's lookup_path

Janis Altherr requested to merge 398144-add-pages-root-directory-to-pages-deployment-db-and-api-2 into master

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.

This is a single string where users can specify the path to the pages root folder using the Pages CI configuration. This does no longer have to be public

Caveats

  • At this time the property needs to be defined in addition to artifacts. A later iteration will have GitLab treat publish as an additional artifacts path entry.

Why is this not behind a feature flag?

Because at this time, it does not change existing behaviour. In fact, it does not change any behaviour at all except pipeline validation. The risk of failure introduced by adding the FF overhead is equal to or even greater than the risk of introducing this feature directly, so I've made the conscious decision to not add a FF.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

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