diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2022-08-31 00:09:41 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2022-08-31 00:09:41 +0300 |
commit | 6377fb774cd6bf76ea235c9e07d88cdb014ee1ad (patch) | |
tree | 83c89564ed1a9c24c258f9bcc8b136fa6d57dfcb /doc | |
parent | 6619ed911ffab93b90756bf392d2925fdc0c1ee2 (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc')
-rw-r--r-- | doc/development/code_review.md | 1 | ||||
-rw-r--r-- | doc/development/gitlab_flavored_markdown/specification_guide/index.md | 79 |
2 files changed, 78 insertions, 2 deletions
diff --git a/doc/development/code_review.md b/doc/development/code_review.md index 6c0dcc644d0..a70ec44fd38 100644 --- a/doc/development/code_review.md +++ b/doc/development/code_review.md @@ -144,6 +144,7 @@ with [domain expertise](#domain-experts). | ------------------------------- | ------------------------ | | `~backend` changes (*1*) | [Backend maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_backend). | | `~database` migrations or changes to expensive queries (*2*) | [Database maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_database). Refer to the [database review guidelines](database_review.md) for more details. | +| `~workhorse` changes | [Workhorse maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_workhorse). | | `~frontend` changes (*1*) | [Frontend maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_frontend). | | `~UX` user-facing changes (*3*) | [Product Designer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_reviewers_UX). Refer to the [design and user interface guidelines](contributing/design.md) for details. | | Adding a new JavaScript library (*1*) | <ul><li>[Frontend foundations member](https://about.gitlab.com/direction/ecosystem/foundations/) if the library significantly increases the [bundle size](https://gitlab.com/gitlab-org/frontend/playground/webpack-memory-metrics/-/blob/master/doc/report.md)</li><li>A [legal department member](https://about.gitlab.com/handbook/legal/) if the license used by the new library hasn't been approved for use in GitLab</li></ul> More information about license compatibility can be found in our [GitLab Licensing and Compatibility documentation](licensing.md). | diff --git a/doc/development/gitlab_flavored_markdown/specification_guide/index.md b/doc/development/gitlab_flavored_markdown/specification_guide/index.md index f2d813cb993..c1227e5d33f 100644 --- a/doc/development/gitlab_flavored_markdown/specification_guide/index.md +++ b/doc/development/gitlab_flavored_markdown/specification_guide/index.md @@ -345,8 +345,50 @@ For the [Markdown snapshot testing](#markdown-snapshot-testing) to work properly, you must account for these differences in a way that ensures the tests are reliable, and always behave the same across different test runs or environments. -To account for these differences, there is a process called **_normalization_**. Normalization -allows custom regular expressions with +To account for these differences, there is a process called **_normalization_**. Several ways to approach normalization exist: + +1. Fixture-based normalization +1. Environment-variable-based normalization +1. Regex-based normalization + +#### Fixture-based normalization + +Fixture-based normalization should be used whenever possible, because it is simpler and easier to +understand than regex-based normalization. + +The [Markdown snapshot testing](#markdown-snapshot-testing) uses RSpec to generate the +[example snapshot files](#example-snapshot-files). RSpec enables you to: + +- Use the same powerful fixture support and helpers as all the rest of the GitLab RSpec suite. +- Use fixtures to control the state of the database when the example snapshots are generated. +- Extract this fixture setup to an RSpec shared context. This shared context is used to ensure + the same database state exists wherever the snapshot tests are run, either by the CI suite, or + locally via [`run-snapshot-tests.sh`](#run-snapshot-testssh-script). + +You can see the RSpec shared context containing these fixtures in +[`spec/support/shared_contexts/glfm/example_snapshot_fixtures.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/spec/support/shared_contexts/glfm/example_snapshot_fixtures.rb). + +#### Environment-variable-based normalization + +In some cases, fixtures may not be usable, because they do not provide control over the varying +values. In these cases, we can introduce support for a environment variable into the production +code, which allows us to override the randommness in our test environment when we are +generating the HTML for footnote examples. Even though it is in the production code path, it has +no effect unless it is explicitly set, therefore it is innocuous. It allows us to avoid +the more-complex regex-based normalization described below. + +The current example of this is when normally random footnote IDs are overridden to be deterministic +by setting `GITLAB_TEST_FOOTNOTE_ID`. It is set along with the fixtures setup in the +[`spec/support/shared_contexts/glfm/example_snapshot_fixtures.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/spec/support/shared_contexts/glfm/example_snapshot_fixtures.rb) +shared context. + +#### Regex-based normalization + +If neither fixture-based nor environment-variable-based normalization can be used, use regex-based +normalization. It is powerful, but more complex, and requires more maintenance. +It requires referring to specific examples by name, and crafting the proper regexes. + +Regex-based normalization allows custom regular expressions with [_capturing groups_](https://ruby-doc.org/core-3.1.2/Regexp.html#class-Regexp-label-Capturing) to be applied to two different versions of HTML or JSON for a given Markdown example, and the contents of the captured groups can be replaced with the same fixed values. @@ -813,6 +855,39 @@ to be specified for a Markdown example. 07_01_00_id: *07_01_00_id ``` +##### `glfm_example_metadata.yml` + +[`glfm_specification/input/gitlab_flavored_markdown/glfm_example_metadata.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/glfm_specification/input/gitlab_flavored_markdown/glfm_example_metadata.yml) +allows control over other aspects of the snapshot example generation process. + +- It is manually updated. +- The `ee` fields determine whether the example is an EE-only example. If the `ee` field is `true`, + the example will only be run by `ee/spec/requests/api/markdown_snapshot_spec.rb`, not by + `spec/requests/api/markdown_snapshot_spec.rb`. +- The `api_request_override_path` field overrides the API endpoint path which is used to + generate the `static` HTML for the specifed example. Different endpoints can generate different + HTML in some cases, so we want to be able to exercise different API endpoints for the same + Markdown. By default, the `/markdown` endpoint is used. + +`glfm_specification/input/gitlab_flavored_markdown/glfm_example_metadata.yml` sample entries: + +```yaml +--- +08_01_00__examples_using_internal_extensions__markdown_preview_api_request_overrides__001: + api_request_override_path: /groups/glfm_group/preview_markdown +08_01_00__examples_using_internal_extensions__markdown_preview_api_request_overrides__002: + api_request_override_path: /glfm_group/glfm_project/preview_markdown +08_01_00__examples_using_internal_extensions__markdown_preview_api_request_overrides__003: + api_request_override_path: /glfm_group/glfm_project/preview_markdown +08_01_00__examples_using_internal_extensions__markdown_preview_api_request_overrides__004: + api_request_override_path: /-/snippets/preview_markdown +08_01_00__examples_using_internal_extensions__markdown_preview_api_request_overrides__005: + api_request_override_path: /glfm_group/glfm_project/-/wikis/new_page/preview_markdown +08_01_00__examples_using_internal_extensions__markdown_preview_api_request_overrides__006: + ee: true + api_request_override_path: /groups/glfm_group/-/wikis/new_page/preview_markdown +``` + #### Output specification files The `glfm_specification/output` directory contains the CommonMark standard format |