Skip to content

Read and pass configuration values to Static Site Editor

Problem to solve

Passing the configuration values from the configuration file to the Static Site Editor component.

Proposal

In this first iteration (which will be broken down in to further sub-iterations), we will read a single value from the configuration file and pass it to the component on the frontend.

The first simple value which will be supported is static_site_generator (from #241168 (closed)). Note that this value will is not yet currently used by the client, and thus will not be passed in the client data payload. It is simply a scalar value to drive the plumbing and architecture for config file processing.

Architecture

The overall architecture will be similar to that used by the GitLab Web IDE Configuration. This will allow us to maximize reuse of existing patterns for services, error handling, validation, and configuration, and all corresponding specs and tests. It will also put in place standard architectural components for future backend feature support.

Specifically:

  1. The StaticSiteEditorController will depend upon a StaticSiteEditorConfigService, which will be a subclass of BaseContainerService. This will be very similar to WebIdeConfigService.
  2. StaticSiteEditorConfigService will coordinate retrieving all the necessary configuration values. It will also handle all associated authorization, http-level error reporting, logging, etc.
  3. The configuration will be of two types:
  4. Generated by the system (e.g. branch, sha, path)
  5. User-provided values out of the config file
  6. These two types of config will be handled by the classes ...::Config::GeneratedConfig and ...::Config::FileConfig, respectively, and their instantiation and execution will be coordinated by StaticSiteEditorConfigService.
  7. The ...::Config::FileConfig will use the standard GitLab config file API provided by ::Gitlab::Config, ::GitLab::Config::Entry, etc., which is used throughout the app for other config files. The FileConfig implementation will be very similar to Gitlab::WebIde::Config and its associated Entry classes, e.g. ...:Entry::Global and ...::Entry::Terminal

This will leave us in a good position to easily add additional configuration values and associated validation by simply adding additional new additional Entry classes.

This architecture will be implemented in three incremental iterations, described below.

Architecture Iteration 1: Incremental refactoring of Static Site Editor controller and config

MR: #41620

This first iteration will consist of some refactoring, cleanup, and restructuring.

  • There's two "types" of config values we will be dealing with:
    1. The auto-generated ones (such as the branch, path, commit, etc), for which support already existed in lib/gitlab/static_site_editor/config.rb
    2. The ones which are specified by the user in the config file.
  • For the frontend, all these values will be merged into in a single flat object to be passed to the client, rather than having the ones from the config file under a separate key. The reasoning being that the frontend client doesn't need (AFAIK) to distinguish between the different types of values, and a flat object is simpler to work with.
  • For the backend, the following cohesive/decoupled approach will be used for the auto-generated vs. file-based config values, and all responsibility for handling/merging the values will be removed from the controller ("skinny controllers"):
    1. Refactor the existing Gitlab::StaticSiteEditor::Config, which is responsible for all the auto-generated values, to Gitlab::StaticSiteEditor::Config::GeneratedConfig
    2. Introduce a new Gitlab::StaticSiteEditor::Config::FileConfig, which is responsible for handling the config file, using the existing support in ::Gitlab::Config::... for loading/parsing/validating YAML config files.
    3. Merge the two sets of values into a single flat set of values to be passed to the client, in Gitlab::StaticSiteEditor::Config::CombinedConfig

Architecture Iteration 2: Introduce StaticSiteEditorConfigService

MR: !41923 (merged)

This second iteration will introduce StaticSiteEditorConfigService (replacing CombinedConfig), with a stub placeholder implementation of FileConfig which returns a hardcoded hash of {static_site_generator: 'middleman'}.

Architecture Iteration 3: Fully Implement FileConfig

MR: !41957 (merged)

This third iteration will replace the stub placeholder FileConfig implementation with a full implementation similar to Gitlab::WebIde::Config and its associated Entry classes, e.g. ...:Entry::Global and ...::Entry::Terminal.

There will still only be a single string config entry supported, static_site_generator, with a single valid value of middleman.

Further details

When the SSE URL (/-/sse/) is requested we should parse and transform the configuration file entries, merge it with the default values, and pass it to the SSE component on the frontend.

If there is no configuration file defined, then the default values will be passed to the SSE component.

Edited by Chad Woolley