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:
- The
StaticSiteEditorController
will depend upon aStaticSiteEditorConfigService
, which will be a subclass ofBaseContainerService
. This will be very similar toWebIdeConfigService
. -
StaticSiteEditorConfigService
will coordinate retrieving all the necessary configuration values. It will also handle all associated authorization, http-level error reporting, logging, etc. - The configuration will be of two types:
- Generated by the system (e.g. branch, sha, path)
- User-provided values out of the config file
- 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 byStaticSiteEditorConfigService
. - 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. TheFileConfig
implementation will be very similar toGitlab::WebIde::Config
and its associatedEntry
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:
- The auto-generated ones (such as the branch, path, commit, etc), for which support already existed in lib/gitlab/static_site_editor/config.rb
- 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"):
- Refactor the existing
Gitlab::StaticSiteEditor::Config
, which is responsible for all the auto-generated values, toGitlab::StaticSiteEditor::Config::GeneratedConfig
- 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. - Merge the two sets of values into a single flat set of values to be passed to the client, in
Gitlab::StaticSiteEditor::Config::CombinedConfig
- Refactor the existing
StaticSiteEditorConfigService
Architecture Iteration 2: Introduce 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'}
.
FileConfig
Architecture Iteration 3: Fully Implement 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.