# GitLab Documentation guidelines
> 原文：[https://docs.gitlab.com/ee/development/documentation/](https://docs.gitlab.com/ee/development/documentation/)
* [Source files and rendered web locations](#source-files-and-rendered-web-locations)
* [Branch naming](#branch-naming)
* [Contributing to docs](#contributing-to-docs)
* [Markdown and styles](#markdown-and-styles)
* [Folder structure and files](#folder-structure-and-files)
* [Metadata](#metadata)
* [Stage and group metadata](#stage-and-group-metadata)
* [Page type metadata](#page-type-metadata)
* [Redirection metadata](#redirection-metadata)
* [Comments metadata](#comments-metadata)
* [Additional page metadata](#additional-page-metadata)
* [Changing document location](#changing-document-location)
* [Redirections for pages with Disqus comments](#redirections-for-pages-with-disqus-comments)
* [Merge requests for GitLab documentation](#merge-requests-for-gitlab-documentation)
* [GitLab `/help`](#gitlab-help)
* [Linking to `/help`](#linking-to-help)
* [GitLab `/help` tests](#gitlab-help-tests)
* [Docs site architecture](#docs-site-architecture)
* [Global navigation](#global-navigation)
* [Previewing the changes live](#previewing-the-changes-live)
* [Troubleshooting review apps](#troubleshooting-review-apps)
* [Technical aspects](#technical-aspects)
* [Testing](#testing)
* [Running tests](#running-tests)
* [Nanoc tests](#nanoc-tests)
* [Lint checks](#lint-checks)
* [Local linters](#local-linters)
* [markdownlint](#markdownlint)
* [Vale](#vale)
* [Install linters](#install-linters)
* [Configure editors](#configure-editors)
* [Disable Vale tests](#disable-vale-tests)
* [Danger Bot](#danger-bot)
# GitLab Documentation guidelines[](#gitlab-documentation-guidelines "Permalink")
GitLab 的文檔[旨在作為唯一的真實來源（SSOT）](https://about.gitlab.com/handbook/documentation/) ，提供有關如何配置，使用 GitLab 以及對其進行故障排除的信息. 該文檔包含按產品領域和主題組織的每個 GitLab 功能的用例和使用說明. 這包括跨多個 GitLab 功能的主題和工作流程，以及將 GitLab 與其他應用程序一起使用.
除了此頁面之外，以下資源還可以幫助您編寫文檔并做出貢獻：
* [樣式指南](styleguide.html) -文檔，語言指南，要遵循的 Markdown 標準，鏈接等內容.
* [結構和模板](structure.html) -了解文檔頁面的典型部分以及如何編寫每一部分.
* [Documentation process](workflow.html).
* [Markdown 指南](../../user/markdown.html) -有關 GitLab 支持的所有 Markdown 語法的參考.
* [網站架構](site_architecture/index.html) -https [://docs.gitlab.com](https://s0docs0gitlab0com.icopy.site)的構建方式.
* [功能標記的文檔](feature_flags.html) -如何編寫和更新部署在功能標記后面的 GitLab 功能的文檔.
## Source files and rendered web locations[](#source-files-and-rendered-web-locations "Permalink")
有關 GitLab，GitLab Runner，Omnibus GitLab 和 Charts 的文檔已發布到[https://docs.gitlab.com](https://s0docs0gitlab0com.icopy.site) . GitLab 的文檔也發布在 GitLab 實例域的`/help`內的應用程序中. 在`/help` ，僅包含當前版本和版本的幫助. 有關其他版本的幫助，請訪問[https://docs.gitlab.com/archives/](https://docs.gitlab.com/archives/) .
文檔的源位于以下倉庫位置的每個 GitLab 應用程序的代碼庫中：
| Project | Path |
| --- | --- |
| [GitLab](https://gitlab.com/gitlab-org/gitlab/) | [`/doc`](https://gitlab.com/gitlab-org/gitlab/tree/master/doc) |
| [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/) | [`/docs`](https://gitlab.com/gitlab-org/gitlab-runner/tree/master/docs) |
| [Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/) | [`/doc`](https://gitlab.com/gitlab-org/omnibus-gitlab/tree/master/doc) |
| [Charts](https://gitlab.com/gitlab-org/charts/gitlab) | [`/doc`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/doc) |
文檔問題和合并請求是它們各自存儲庫的一部分，都帶有標簽`Documentation` .
### Branch naming[](#branch-naming "Permalink")
[GitLab 主項目](../pipelines.html)的[CI 管道](../pipelines.html)配置為僅自動運行與貢獻類型匹配的作業. 如果您的貢獻**僅**包含文檔更改，那么將僅運行與文檔相關的作業，并且管道的完成將比代碼貢獻更快.
如果要向 Runner，Omnibus 或 Charts 提交僅文檔更改，則不會自動確定快速管道. 相反，請使用以下指南為僅文檔合并請求創建分支：
| 分店名稱 | 有效的例子 |
| --- | --- |
| 從`docs/`開始 | `docs/update-api-issues` |
| 從`docs-`開始 | `docs-update-api-issues` |
| 以`-docs` | `123-update-api-issues-docs` |
## Contributing to docs[](#contributing-to-docs "Permalink")
整個 GitLab 社區都歡迎[對 GitLab 文檔做出貢獻](workflow.html) .
為確保 GitLab 文檔是最新的，所有[功能更改](feature-change-workflow.html)都有特殊的流程和職責，即影響功能外觀，使用或管理的開發工作.
但是，任何人都可以貢獻與功能更改無關的[文檔改進](improvement-workflow.html) . 例如，添加有關如何完成用例的新文檔，這可以通過 GitLab 或第三方工具和 GitLab 完成.
## Markdown and styles[](#markdown-and-styles "Permalink")
[GitLab 文檔](https://gitlab.com/gitlab-org/gitlab-docs)使用[GitLab Kramdown](https://gitlab.com/gitlab-org/gitlab_kramdown)作為其 Markdown 渲染引擎. 有關完整的 Kramdown 參考，請參閱《 [GitLab Markdown 指南》](https://about.gitlab.com/handbook/markdown-guide/) .
遵守[文檔樣式指南](styleguide.html) . 如果缺少樣式標準，歡迎您通過合并請求提出建議.
## Folder structure and files[](#folder-structure-and-files "Permalink")
請參閱" [文檔樣式指南"](styleguide.html)的" [結構"](styleguide.html#structure)部分.
## Metadata[](#metadata "Permalink")
為了提供其他指令或有用的信息，我們將 YAML 格式的元數據添加到每個產品文檔頁面的開頭（YAML 開頭）. 所有值均視為字符串，僅用于[docs 網站](site_architecture/index.html) .
### Stage and group metadata[](#stage-and-group-metadata "Permalink")
理想情況下，每個頁面都應具有與其所屬的階段和組相關的元數據，以及如下所述的信息塊：
* `stage` ：頁面大部分內容所屬的[Stage](https://about.gitlab.com/handbook/product/product-categories/#devops-stages) .
* `group` ：頁面大部分內容所屬的[Group](https://about.gitlab.com/company/team/structure/#product-groups) .
* `info` ：下一行，為與該頁面的舞臺和小組相關的技術作家聯系提供指導，以幫助參與者：
```
To determine the technical writer assigned to the Stage/Group
associated with this page, see
https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
```
例如，以下元數據將位于產品文檔頁面的開始，其內容主要與"審核事件"功能相關：
```
---
stage: Monitor
group: APM
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
---
```
### Page type metadata[](#page-type-metadata "Permalink")
最初在[此史詩中](https://gitlab.com/groups/gitlab-org/-/epics/1280)討論過，每個頁面應該具有`type`元數據. 可以是以下一項或多項：
* `index` ：索引/概述頁面. 它們充當其他頁面的列表. 不一定意味著頁面應命名為`index.md` . [示例頁面](../../install/README.html) .
* `concepts` ：使用產品之前需要了解的內容. 信息性的，非指導性的. 例如，抽象的想法，解釋含義或收益，支持對任務的理解. 閱讀它們以獲取背景信息，例如"為什么 X 很重要". [示例頁面](../../topics/autodevops/index.html) .
* `howto` ：特定用例說明. [示例頁面](../../ssh/README.html) .
* `tutorial` ：邊做邊學過程/概念. [示例頁面](../../gitlab-basics/start-using-git.html) .
* `reference` ：介紹什么是/做什么. 諸如特定設置，沒有太多解釋的事實之類的東西可以閱讀以獲取詳細信息. [示例頁面](../../ci/yaml/README.html) .
### Redirection metadata[](#redirection-metadata "Permalink")
將頁面移到另一個位置時，應添加以下元數據：
* `redirect_to` ：訪問者應將移動頁面重定向到的相對路徑和文件名（擴展名為`.md` ）. [了解更多](#changing-document-location) .
* `disqus_identifier` ：Disqus 評論系統的標識符. 用于保留已被移至新 URL 的頁面的注釋. [了解更多](#redirections-for-pages-with-disqus-comments) .
### Comments metadata[](#comments-metadata "Permalink")
[docs 網站](site_architecture/index.html)上默認啟用了注釋（由 Disqus 提供）. 如果要禁用它們（例如在索引頁面中），請將其設置為`false` ：
```
---
comments: false
---
```
### Additional page metadata[](#additional-page-metadata "Permalink")
每個頁面可以具有其他（可選）元數據（在[default.html](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/fc3577921343173d589dfa43d837b4307e4e620f/layouts/default.html#L30-52) Nanoc 布局中設置），如果定義，這些元數據將顯示在頁面頂部：
* `author` ：頁面`author`的名稱，通常是教程. 它需要`author_gitlab`才能顯示.
* `author_gitlab` ：GitLab.com 上作者的用戶名. 它需要`author`才能顯示.
* `date` ：頁面的創建日期，通常用于教程.
* `article_type` ：文章的類型. 可以是`tutorial`或`user guide` .
* `level` ：操作方法或教程的復雜程度. 可以是`beginner` ， `advanced`或`intermediate` .
* `last_updated` ：頁面上次更新時的 ISO 格式日期. 例如`2020-02-14` .
* `reading_time` ：如果要添加頁面的大概閱讀時間的指示，可以將`reading_time`設置為`true` . 這使用簡單的[算法](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/master/lib/helpers/reading_time.rb)根據單詞數計算閱讀時間.
## Changing document location[](#changing-document-location "Permalink")
更改文檔的位置需要特定的步驟，以確保用戶可以無縫訪問新的文檔頁面，無論他們是通過`/help`還是通過[https://docs.gitlab.com](https://s0docs0gitlab0com.icopy.site)訪問 GitLab 實例域上的內容. 如果您在此過程中有任何疑問（例如是否需要搬遷），請務必指派一名技術作家，并確保在合并之前技術作家會對此更改進行審查.
如果確實需要更改文檔的位置，請不要刪除舊文檔，而應將所有內容替換為以下內容：
```
---
redirect_to: '../path/to/file/index.md'
---
This document was moved to [another location](../path/to/file/index.md).
```
其中`../path/to/file/index.md`通常是舊文檔的相對路徑.
所述`redirect_to`變量同時支持完整或相對 URL，例如`https://docs.gitlab.com/ee/path/to/file.html` ， `../path/to/file.html` ， `path/to/file.md` . 它確保重定向將對[https://docs.gitlab.com](https://s0docs0gitlab0com.icopy.site)起作用，并且任何`*.md`路徑都將編譯為`*.html` . 前部事項下方的新行通知用戶文檔已更改位置，對于從存儲庫瀏覽該文件的用戶而言非常有用.
例如，如果將`doc/workflow/lfs/index.md`移到`doc/administration/lfs.md` ，則步驟將是：
1. Copy `doc/workflow/lfs/index.md` to `doc/administration/lfs.md`
2. 將`doc/workflow/lfs/index.md`的內容替換為：
```
---
redirect_to: '../../administration/lfs.md'
---
This document was moved to [another location](../../administration/lfs.md).
```
3. 查找并用新位置替換所有出現的舊位置. 查找它們的快速方法是在將文件從以下位置更改的存儲庫中使用`git grep` ：
```
git grep -n "workflow/lfs/lfs_administration"
git grep -n "lfs/lfs_administration"
```
**注意：**如果要移動的文檔上有任何 Disqus 評論，則要執行的其他步驟[如下所示](#redirections-for-pages-with-disqus-comments) .
注意事項：
* 由于除了文檔本身以外，我們還使用內聯文檔，因此該文檔也可能在訪問`/help`時將呈現的 GitLab（ `app/` ）視圖中引用，有時甚至在測試套件（ `spec/` ）中也會引用. 您必須在這些路徑中搜索對文檔的引用并進行更新.
* 上面的`git grep`命令將在您在其中運行它的目錄中以遞歸方式搜索`workflow/lfs/lfs_administration`和`lfs/lfs_administration` ，并將打印文件和提及該文件的行. 您可能會問為什么這兩次抱怨. 由于[我們使用相對路徑鏈接到文檔](styleguide.html#links) ，因此有時更深入地搜索路徑可能很有用.
* 當文檔鏈接到 GitLab 的內置幫助頁面時，不使用`*.md`擴展名，這就是為什么我們在`git grep`忽略它.
* 使用"更改文檔位置" MR 描述模板上的清單.
### Redirections for pages with Disqus comments[](#redirections-for-pages-with-disqus-comments "Permalink")
如果要重定位的文檔頁面已經包含 Disqus 評論，則我們需要保留 Disqus 線程.
Disqus 使用每頁標識符，對于[https://docs.gitlab.com](https://s0docs0gitlab0com.icopy.site) ，頁面標識符被配置為頁面 URL. 因此，當我們更改文檔位置時，我們需要將舊的 URL 保留為相同的 Disqus 標識符.
為此，將變量`disqus_identifier`添加到`disqus_identifier` ，使用舊的 URL 作為值. 例如，假設我們將`https://docs.gitlab.com/my-old-location/README.html`下可用的文檔移到了新位置`https://docs.gitlab.com/my-new-location/index.html` .
在**新文檔的**開頭部分，我們添加了以下內容：
```
---
disqus_identifier: 'https://docs.gitlab.com/my-old-location/README.html'
---
```
注：有必要在文件名中`disqus_identifier` URL，即使它`index.html`或`README.html` .
## Merge requests for GitLab documentation[](#merge-requests-for-gitlab-documentation "Permalink")
在開始之前，請確保您已閱讀上面的" [為文檔做貢獻](#contributing-to-docs) "介紹性部分和[文檔工作流程](workflow.html) .
* 使用當前的[合并請求描述模板](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab/merge_request_templates/Documentation.md)
* 標記 MR `Documentation` （只能由具有`developer`訪問權限的`developer` （例如，GitLab 團隊成員）完成）
* 在下面的每個注釋中分配正確的里程碑（只能由具有`developer`訪問權限的人（例如，GitLab 團隊成員）完成）
如果對現有內容進行了改進，文檔將被合并，這代表了遵循模板和樣式標準的真誠努力，并且被認為是準確的.
對于進一步完善文檔的進一步需求，應在后續的 MR 或問題中立即解決.
**注意：**如果要添加文檔的發行版已經凍結或發行，請使用標簽`~"Pick into XY"`將其合并到正確的發行版中. 盡量避免選擇過去的發行版，因為這樣做會增加發行版管理器的工作量.
## GitLab `/help`[](#gitlab-help "Permalink")
每個 GitLab 實例都包含文檔，該文檔可從`/help` （ `https://gitlab.example.com/help` ）獲得. 例如， [https://gitlab.com/help](https://gitlab.com/help) .
[https://docs.gitlab.com](https://s0docs0gitlab0com.icopy.site)上在線提供的文檔每隔四個小時從 GitLab，Omnibus 和 Runner 的`master`分支進行部署. 因此，合并請求合并后，它將在同一天在線可用. 但是，它將在分配給 MR 的里程碑內發貨（并在`/help`上可用）.
例如，假設您的合并請求的里程碑設置為 11.3，該里程碑將于 2018-09-22 發布. 如果在 2018-09-15 合并，它將在 2018-09-15 聯機提供，但是，隨著功能凍結日期的過去，如果 MR 沒有`~"Pick into 11.3"`標簽，那么該里程碑必須更改為 11.4，并且僅在 2018-10-22 以及 GitLab 11.4 中將與所有 GitLab 軟件包一起提供. 這意味著，它將僅在 GitLab 11.4 及更高版本的`/help`下提供，但在合并的同一天在[https://docs.gitlab.com/](https://docs.gitlab.com/)上提供.
### Linking to `/help`[](#linking-to-help "Permalink")
構建新功能時，可能需要從應用程序 GitLab 鏈接文檔. 通常，這是通過`help_page_path` helper 方法在`app/views/`目錄內的文件中完成的.
以最簡單的形式，用于生成到`/help`頁面的鏈接的 HAML 代碼為：
```
= link_to 'Help page', help_page_path('user/permissions')
```
`help_page_path`使用以下約定包含要鏈接到的文檔的路徑：
* 它相對于 GitLab 存儲庫中的`doc/`目錄
* `.md`擴展名必須省略
* 它不能以斜杠（ `/` ）結尾
以下是根據情況應使用的一些特殊情況. 您可以結合以下一項或多項：
1. **鏈接到錨鏈接.** 使用`anchor`作為`help_page_path`方法的一部分：
```
= link_to 'Help page', help_page_path('user/permissions', anchor: 'anchor-link')
```
2. **在新標簽頁中打開鏈接.** 這應該是默認行為：
```
= link_to 'Help page', help_page_path('user/permissions'), target: '_blank'
```
3. **鏈接到圓圈圖標.** 通常用于無法使用長描述的設置，例如復選框旁邊. 您基本上可以使用任何字體超贊的圖標，但更喜歡使用`question-circle` ：
```
= link_to icon('question-circle'), help_page_path('user/permissions')
```
4. **使用按鈕鏈接.** 在文本與頁面布局其余部分脫離上下文的地方很有用：
```
= link_to 'Help page', help_page_path('user/permissions'), class: 'btn btn-info'
```
5. **使用內聯某些文本的鏈接.**
```
Description to #{link_to 'Help page', help_page_path('user/permissions')}.
```
6. **在句子末尾添加句點.** Useful when you don’t want the period to be part of the link:
```
= succeed '.' do
Learn more in the
= link_to 'Help page', help_page_path('user/permissions')
```
### GitLab `/help` tests[](#gitlab-help-tests "Permalink")
運行了一些[RSpec 測試](https://gitlab.com/gitlab-org/gitlab/blob/master/spec/features/help_pages_spec.rb)以確保 GitLab 文檔能夠呈現并正常工作. 特別是，該[主要文檔的登錄頁面](../../README.html)將從`/help`正確運行. 例如， [GitLab.com 的`/help`](https://gitlab.com/help) .
## Docs site architecture[](#docs-site-architecture "Permalink")
請參閱" [文檔"網站的體系結構](site_architecture/index.html)頁面，以了解我們如何在[https://docs.gitlab.com 上](https://s0docs0gitlab0com.icopy.site)構建和部署該網站，并查看所有正在使用的資產和庫.
### Global navigation[](#global-navigation "Permalink")
有關如何構建和更新左側導航菜單的信息，請參閱[全局導航](site_architecture/global_nav.html)文檔.
## Previewing the changes live[](#previewing-the-changes-live "Permalink")
**注意：**要在本地預覽對文檔的更改，請遵循本[開發指南](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/README.md#development-when-contributing-to-gitlab-documentation)或[GDK 的這些說明](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/gitlab_docs.md) .
當前為以下項目啟用了實時預覽：
* [`gitlab`](https://gitlab.com/gitlab-org/gitlab)
* [`gitlab-runner`](https://gitlab.com/gitlab-org/gitlab-runner)
如果您的合并請求中有 docs 更改，則可以使用手動`review-docs-deploy`作業為合并請求部署 docs review 應用. 您將至少需要維護者權限才能運行它.
[](img/manual_build_docs.png)
**注意：**您將需要將分支推送到這些存儲庫，它不適用于 fork.
`review-docs-deploy*`工作將：
1. 在[`gitlab-docs`](https://gitlab.com/gitlab-org/gitlab-docs)項目中創建一個以該方案命名的新分支： `docs-preview-$DOCS_GITLAB_REPO_SUFFIX-$CI_MERGE_REQUEST_IID` ，其中`DOCS_GITLAB_REPO_SUFFIX`是每個產品的后綴，例如`ee`表示 EE， `omnibus`表示 Omnibus `CI_MERGE_REQUEST_IID` ， `CI_MERGE_REQUEST_IID`等，相應合并請求的 ID.
2. 觸發跨項目管道，并使用您的更改構建文檔站點.
如果評論應用程序 URL 返回 404，則意味著該站點尚未部署，或者遠程管道出了點問題. 給它幾分鐘，它應該在線顯示，否則，您可以從合并請求的作業輸出中的鏈接檢查遠程管道的狀態. 如果管道失敗或阻塞，請在`#docs`聊天頻道中添加一行.
**提示：**對 GitLab 項目沒有合并權限的人（想想貢獻者的分支）不能運行手動作業. 在這種情況下，您可以請 GitLab 團隊的某人授權為您執行此操作.**注意：**確保始終刪除正在處理的合并請求的分支. 如果您不這樣做，那么遠程 docs 分支也不會被刪除，并且承載 Review Apps 的服務器最終將沒有磁盤空間.
### Troubleshooting review apps[](#troubleshooting-review-apps "Permalink")
如果評論應用程序 URL 返回 404，請按照以下步驟進行調試：
1. **您是否遵循了合并請求小部件中的 URL？** 如果是，則檢查鏈接是否與作業輸出中的鏈接相同.
2. **您是否遵循作業輸出中的 URL？** 如果是，則意味著該站點尚未部署或遠程管道出了點問題. 給它幾分鐘，它應該在線顯示，否則，您可以從作業輸出中的鏈接檢查遠程管道的狀態. 如果管道失敗或阻塞，請在`#docs`聊天頻道中添加一行.
### Technical aspects[](#technical-aspects "Permalink")
如果您想了解更深入的細節，這就是實際發生的事情：
1. 您在合并請求中手動運行`review-docs-deploy`作業.
2. The job runs the [`scripts/trigger-build-docs`](https://gitlab.com/gitlab-org/gitlab/blob/master/scripts/trigger-build-docs) script with the `deploy` flag, which in turn:
1. 使用您的分支名稱并應用以下內容：
* `docs-preview-`前綴已添加.
* 產品信息用于了解評論應用所源自的項目.
* 添加了合并請求的編號，以便您可以通過`gitlab-docs`分支名稱知道其源自的合并請求.
2. The remote branch is then created if it doesn’t exist (meaning you can re-run the manual job as many times as you want and this step will be skipped).
3. 在 docs 項目中觸發了新的跨項目管道.
4. 預覽 URL 顯示在作業輸出和合并請求小部件中. 您還將獲得到遠程管道的鏈接.
3. 在 docs 項目中，創建了管道，它[跳過了測試作業](https://gitlab.com/gitlab-org/gitlab-docs/blob/8d5d5c750c602a835614b02f9db42ead1c4b2f5e/.gitlab-ci.yml#L50-55)以減少構建時間.
4. 構建了 docs 網站之后，HTML 文件即作為工件上傳.
5. 僅與 docs 項目相關聯的特定 Runner，運行 Review App 作業，該作業下載工件，并使用`rsync`將文件傳輸到 NGINX 為它們提供文件的位置.
The following GitLab features are used among others:
* [Manual actions](../../ci/yaml/README.html#whenmanual)
* [Multi project pipelines](../../ci/multi_project_pipeline_graphs.html)
* [Review Apps](../../ci/review_apps/index.html)
* [Artifacts](../../ci/yaml/README.html#artifacts)
* [Specific Runner](../../ci/runners/README.html#prevent-a-specific-runner-from-being-enabled-for-other-projects)
* [Pipelines for merge requests](../../ci/merge_request_pipelines/index.html)
## Testing[](#testing "Permalink")
我們將文檔視為代碼，因此在 CI 管道中使用測試來維護文檔的標準和質量. 提交帶有新文檔或更改文檔的合并請求時，當前測試在 CI 作業中運行，它們是：
* [`docs lint`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab/ci/docs.gitlab-ci.yml#L48) ：對 docs 本身的內容運行一些測試：
* [`lint-doc.sh`腳本](https://gitlab.com/gitlab-org/gitlab/blob/master/scripts/lint-doc.sh)運行以下檢查和操作：
* 所有 cURL 示例都使用長標記（例如：-- `--header` ，而不是`-H` ）.
* `CHANGELOG.md`不包含重復的版本.
* `doc/`中沒有文件是可執行文件.
* 沒有添加新的`README.md` .
* [markdownlint](#markdownlint) .
* [谷](#vale)
* Nanoc 測試：
* [`internal_links`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab/ci/docs.gitlab-ci.yml#L67)檢查所有內部鏈接（例如： `[link](../index.md)` ）是否有效.
* [`internal_anchors`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab/ci/docs.gitlab-ci.yml#L69)檢查所有內部錨點（例如： `[link](../index.md#internal_anchor)` ）是否有效.
### Running tests[](#running-tests "Permalink")
除了在[本地預覽更改](#previewing-the-changes-live)之外，您還可以[在本地](#previewing-the-changes-live)運行所有棉絨檢查和 Nanoc 測試.
#### Nanoc tests[](#nanoc-tests "Permalink")
要在本地執行 Nanoc 測試：
1. 導航到[`gitlab-docs`](https://gitlab.com/gitlab-org/gitlab-docs)目錄.
2. Run:
```
# Check for broken internal links
bundle exec nanoc check internal_links
# Check for broken external links (might take a lot of time to complete).
# This test is set to be allowed to fail and is run only in the gitlab-docs project CI
bundle exec nanoc check internal_anchors
```
#### Lint checks[](#lint-checks "Permalink")
Lint 檢查由[`lint-doc.sh`](https://gitlab.com/gitlab-org/gitlab/blob/master/scripts/lint-doc.sh)腳本執行，可以按以下方式執行：
1. 導航到`gitlab`目錄.
2. Run:
```
MD_DOC_PATH=path/to/my_doc.md scripts/lint-doc.sh
```
`MD_DOC_PATH`指向您要運行 lint 檢查的文件或目錄的位置. 如果完全省略它，它將默認為`doc/`目錄. 輸出應類似于：
```
=> Linting documents at path /path/to/gitlab as <user>...
=> Checking for cURL short options...
=> Checking for CHANGELOG.md duplicate entries...
=> Checking /path/to/gitlab/doc for executable permissions...
=> Checking for new README.md files...
=> Linting markdown style...
=> Linting prose...
? 0 errors, 0 warnings and 0 suggestions in 1 file.
? Linting passed
```
請注意，這要求您要么在計算機上安裝了必需的 lint 工具，要么在運行的 Docker 安裝中，在這種情況下，將使用預安裝了這些工具的映像.
### Local linters[](#local-linters "Permalink")
為了幫助您遵守[文檔樣式指南](styleguide.html) ，并改善添加到文檔中的內容， [請安裝文檔短絨](#install-linters) ， [并將其與代碼編輯器集成](#configure-editors) .
在 GitLab，我們主要使用：
* [markdownlint](#markdownlint)
* [Vale](#vale)
#### markdownlint[](#markdownlint "Permalink")
[markdownlint](https://github.com/DavidAnson/markdownlint)檢查 Markdown 語法是否遵循[某些規則](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#rules) ，并由[`docs-lint`測試使用](#testing) .
我們的[文檔樣式指南](styleguide.html#markdown)和[Markdown 指南](https://about.gitlab.com/handbook/markdown-guide/)詳細說明了為 GitLab 文檔選擇 Markdown 語法時必須進行哪些選擇. 該工具有助于發現與這些準則的偏差.
在以下項目中找到 markdownlint 配置：
* [`gitlab`](https://gitlab.com/gitlab-org/gitlab/blob/master/.markdownlint.json)
* [`gitlab-runner`](https://gitlab.com/gitlab-org/gitlab-runner/blob/master/.markdownlint.json)
* [`omnibus-gitlab`](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/.markdownlint.json)
* [`charts`](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/.markdownlint.json)
* [`gitlab-development-kit`](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/master/.markdownlint.json)
在構建管道中也使用此配置.
您可以使用 markdownlint：
* [On the command line](https://github.com/igorshubovych/markdownlint-cli#markdownlint-cli--).
* [Within a code editor](#configure-editors).
#### Vale[](#vale "Permalink")
[淡水河谷](https://errata-ai.gitbook.io/vale/)是英語的語法，樣式和單詞用法慣用語. Vale 的配置存儲在項目根目錄下的[`.vale.ini`](https://gitlab.com/gitlab-org/gitlab/blob/master/.vale.ini)文件中.
Vale 支持創建可擴展多種檢查類型的[自定義測試](https://errata-ai.github.io/vale/styles/) ，我們將這些檢查存儲在項目文檔目錄的`.linting/vale/styles/gitlab`目錄中.
在以下項目中找到 Vale 配置：
* [`gitlab`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/doc/.vale/gitlab)
* [`gitlab-runner`](https://gitlab.com/gitlab-org/gitlab-runner/-/tree/master/docs/.vale/gitlab)
* [`omnibus-gitlab`](https://gitlab.com/gitlab-org/omnibus-gitlab/-/tree/master/doc/.vale/gitlab)
* [`charts`](https://gitlab.com/gitlab-org/charts/gitlab/-/tree/master/doc/.vale/gitlab)
* [`gitlab-development-kit`](https://gitlab.com/gitlab-org/gitlab-development-kit/-/tree/master/doc/.vale/gitlab)
在構建管道中也使用此配置.
您可以使用 Vale：
* [On the command line](https://errata-ai.gitbook.io/vale/getting-started/usage).
* [Within a code editor](#configure-editors).
#### Install linters[](#install-linters "Permalink")
至少要安裝[markdownlint](#markdownlint)和[Vale](#vale)以匹配在構建管道中運行的檢查：
1. 使用以下任一方法安裝`markdownlint-cli` ：
* `npm`:
```
npm install -g markdownlint-cli
```
* `yarn`:
```
yarn global add markdownlint-cli
```
我們建議安裝 linting [Docker image](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/master/dockerfiles/Dockerfile.gitlab-docs-lint#L38)文檔中當前使用的`markdownlint-cli`版本.
2. 安裝[`vale`](https://github.com/errata-ai/vale/releases) . 例如，要使用`brew` for macOS 安裝，請運行：
```
brew install vale
```
We recommend installing the version of Vale currently used in the documentation linting [Docker image](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/master/dockerfiles/Dockerfile.gitlab-docs-lint#L16).
除了在命令行上使用 markdownlint 和 Vale 之外，這些工具還可以[與代碼編輯器集成](#configure-editors) .
#### Configure editors[](#configure-editors "Permalink")
要在編輯器中配置 markdownlint，請根據需要安裝以下之一：
* [Sublime Text](https://packagecontrol.io/packages/SublimeLinter-contrib-markdownlint)
* [Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint)
* [Atom](https://atom.io/packages/linter-node-markdownlint)
要在編輯器中配置 Vale，請根據需要安裝以下任一程序：
* Sublime Text [`SublimeLinter-contrib-vale`插件](https://packagecontrol.io/packages/SublimeLinter-contrib-vale)
* Visual Studio Code [`testthedocs.vale`擴展](https://marketplace.visualstudio.com/items?itemName=testthedocs.vale)
我們不使用[Vale Server](https://errata-ai.github.io/vale/#using-vale-with-a-text-editor-or-another-third-party-application) .
#### Disable Vale tests[](#disable-vale-tests "Permalink")
您可以為文檔的任何部分禁用特定的 Vale 棉絨規則或所有 Vale 棉絨規則：
* 要禁用特定規則，添加`<!-- vale gitlab.rulename = NO -->`文本之前標記和`<!-- vale gitlab.rulename = YES -->`后的文字標簽，更換`rulename`與[GitLab 樣式](https://gitlab.com/gitlab-org/gitlab/-/tree/master/doc/.linting/vale/styles/gitlab)目錄中測試的文件名.
* 要禁用所有淡水河谷棉絨規則，請在文本前添加`<!-- vale off -->`淡水`<!-- vale off -->`標簽，并在文本后添加`<!-- vale off -->`淡水`<!-- vale on -->`標簽.
只要有可能，僅排除有問題的規則和行. 在某些情況下，例如列表項，您可能需要禁用整個列表的絨毛，直到[Vale 問題＃175](https://github.com/errata-ai/vale/issues/175)得到解決.
有關更多信息，請參見[Vale 的文檔](https://errata-ai.gitbook.io/vale/getting-started/markup#markup-based-configuration) .
## Danger Bot[](#danger-bot "Permalink")
GitLab 在代碼審查中的某些元素上使用了[Danger](https://github.com/danger/danger) . 對于文檔在合并請求中的更改，每當對`/doc`下的文件進行更改時，Danger Bot 都會在注釋中留下有關文檔處理的進一步說明. 這是在 GitLab 存儲庫中的`Dangerfile`中[/ danger / documentation /下配置的](https://gitlab.com/gitlab-org/gitlab/tree/master/danger/documentation) .
- GitLab Docs
- Installation
- Requirements
- GitLab cloud native Helm Chart
- Install GitLab with Docker
- Installation from source
- Install GitLab on Microsoft Azure
- Installing GitLab on Google Cloud Platform
- Installing GitLab on Amazon Web Services (AWS)
- Analytics
- Code Review Analytics
- Productivity Analytics
- Value Stream Analytics
- Kubernetes clusters
- Adding and removing Kubernetes clusters
- Adding EKS clusters
- Adding GKE clusters
- Group-level Kubernetes clusters
- Instance-level Kubernetes clusters
- Canary Deployments
- Cluster Environments
- Deploy Boards
- GitLab Managed Apps
- Crossplane configuration
- Cluster management project (alpha)
- Kubernetes Logs
- Runbooks
- Serverless
- Deploying AWS Lambda function using GitLab CI/CD
- Securing your deployed applications
- Groups
- Contribution Analytics
- Custom group-level project templates
- Epics
- Manage epics
- Group Import/Export
- Insights
- Issues Analytics
- Iterations
- Public access
- SAML SSO for GitLab.com groups
- SCIM provisioning using SAML SSO for GitLab.com groups
- Subgroups
- Roadmap
- Projects
- GitLab Secure
- Security Configuration
- Container Scanning
- Dependency Scanning
- Dependency List
- Static Application Security Testing (SAST)
- Secret Detection
- Dynamic Application Security Testing (DAST)
- GitLab Security Dashboard
- Offline environments
- Standalone Vulnerability pages
- Security scanner integration
- Badges
- Bulk editing issues and merge requests at the project level
- Code Owners
- Compliance
- License Compliance
- Compliance Dashboard
- Create a project
- Description templates
- Deploy Keys
- Deploy Tokens
- File finder
- Project integrations
- Integrations
- Atlassian Bamboo CI Service
- Bugzilla Service
- Custom Issue Tracker service
- Discord Notifications service
- Enabling emails on push
- GitHub project integration
- Hangouts Chat service
- Atlassian HipChat
- Irker IRC Gateway
- GitLab Jira integration
- Mattermost Notifications Service
- Mattermost slash commands
- Microsoft Teams service
- Mock CI Service
- Prometheus integration
- Redmine Service
- Slack Notifications Service
- Slack slash commands
- GitLab Slack application
- Webhooks
- YouTrack Service
- Insights
- Issues
- Crosslinking Issues
- Design Management
- Confidential issues
- Due dates
- Issue Boards
- Issue Data and Actions
- Labels
- Managing issues
- Milestones
- Multiple Assignees for Issues
- Related issues
- Service Desk
- Sorting and ordering issue lists
- Issue weight
- Associate a Zoom meeting with an issue
- Merge requests
- Allow collaboration on merge requests across forks
- Merge Request Approvals
- Browser Performance Testing
- How to create a merge request
- Cherry-pick changes
- Code Quality
- Load Performance Testing
- Merge Request dependencies
- Fast-forward merge requests
- Merge when pipeline succeeds
- Merge request conflict resolution
- Reverting changes
- Reviewing and managing merge requests
- Squash and merge
- Merge requests versions
- Draft merge requests
- Members of a project
- Migrating projects to a GitLab instance
- Import your project from Bitbucket Cloud to GitLab
- Import your project from Bitbucket Server to GitLab
- Migrating from ClearCase
- Migrating from CVS
- Import your project from FogBugz to GitLab
- Gemnasium
- Import your project from GitHub to GitLab
- Project importing from GitLab.com to your private GitLab instance
- Import your project from Gitea to GitLab
- Import your Jira project issues to GitLab
- Migrating from Perforce Helix
- Import Phabricator tasks into a GitLab project
- Import multiple repositories by uploading a manifest file
- Import project from repo by URL
- Migrating from SVN to GitLab
- Migrating from TFVC to Git
- Push Options
- Releases
- Repository
- Branches
- Git Attributes
- File Locking
- Git file blame
- Git file history
- Repository mirroring
- Protected branches
- Protected tags
- Push Rules
- Reduce repository size
- Signing commits with GPG
- Syntax Highlighting
- GitLab Web Editor
- Web IDE
- Requirements Management
- Project settings
- Project import/export
- Project access tokens (Alpha)
- Share Projects with other Groups
- Snippets
- Static Site Editor
- Wiki
- Project operations
- Monitor metrics for your CI/CD environment
- Set up alerts for Prometheus metrics
- Embedding metric charts within GitLab-flavored Markdown
- Embedding Grafana charts
- Using the Metrics Dashboard
- Dashboard YAML properties
- Metrics dashboard settings
- Panel types for dashboards
- Using Variables
- Templating variables for metrics dashboards
- Prometheus Metrics library
- Monitoring AWS Resources
- Monitoring HAProxy
- Monitoring Kubernetes
- Monitoring NGINX
- Monitoring NGINX Ingress Controller
- Monitoring NGINX Ingress Controller with VTS metrics
- Alert Management
- Error Tracking
- Tracing
- Incident Management
- GitLab Status Page
- Feature Flags
- GitLab CI/CD
- GitLab CI/CD pipeline configuration reference
- GitLab CI/CD include examples
- Introduction to CI/CD with GitLab
- Getting started with GitLab CI/CD
- How to enable or disable GitLab CI/CD
- Using SSH keys with GitLab CI/CD
- Migrating from CircleCI
- Migrating from Jenkins
- Auto DevOps
- Getting started with Auto DevOps
- Requirements for Auto DevOps
- Customizing Auto DevOps
- Stages of Auto DevOps
- Upgrading PostgreSQL for Auto DevOps
- Cache dependencies in GitLab CI/CD
- GitLab ChatOps
- Cloud deployment
- Docker integration
- Building Docker images with GitLab CI/CD
- Using Docker images
- Building images with kaniko and GitLab CI/CD
- GitLab CI/CD environment variables
- Predefined environment variables reference
- Where variables can be used
- Deprecated GitLab CI/CD variables
- Environments and deployments
- Protected Environments
- GitLab CI/CD Examples
- Test a Clojure application with GitLab CI/CD
- Using Dpl as deployment tool
- Testing a Phoenix application with GitLab CI/CD
- End-to-end testing with GitLab CI/CD and WebdriverIO
- DevOps and Game Dev with GitLab CI/CD
- Deploy a Spring Boot application to Cloud Foundry with GitLab CI/CD
- How to deploy Maven projects to Artifactory with GitLab CI/CD
- Testing PHP projects
- Running Composer and NPM scripts with deployment via SCP in GitLab CI/CD
- Test and deploy Laravel applications with GitLab CI/CD and Envoy
- Test and deploy a Python application with GitLab CI/CD
- Test and deploy a Ruby application with GitLab CI/CD
- Test and deploy a Scala application to Heroku
- GitLab CI/CD for external repositories
- Using GitLab CI/CD with a Bitbucket Cloud repository
- Using GitLab CI/CD with a GitHub repository
- GitLab Pages
- GitLab Pages
- GitLab Pages domain names, URLs, and baseurls
- Create a GitLab Pages website from scratch
- Custom domains and SSL/TLS Certificates
- GitLab Pages integration with Let's Encrypt
- GitLab Pages Access Control
- Exploring GitLab Pages
- Incremental Rollouts with GitLab CI/CD
- Interactive Web Terminals
- Optimizing GitLab for large repositories
- Metrics Reports
- CI/CD pipelines
- Pipeline Architecture
- Directed Acyclic Graph
- Multi-project pipelines
- Parent-child pipelines
- Pipelines for Merge Requests
- Pipelines for Merged Results
- Merge Trains
- Job artifacts
- Pipeline schedules
- Pipeline settings
- Triggering pipelines through the API
- Review Apps
- Configuring GitLab Runners
- GitLab CI services examples
- Using MySQL
- Using PostgreSQL
- Using Redis
- Troubleshooting CI/CD
- GitLab Package Registry
- GitLab Container Registry
- Dependency Proxy
- GitLab Composer Repository
- GitLab Conan Repository
- GitLab Maven Repository
- GitLab NPM Registry
- GitLab NuGet Repository
- GitLab PyPi Repository
- API Docs
- API resources
- .gitignore API
- GitLab CI YMLs API
- Group and project access requests API
- Appearance API
- Applications API
- Audit Events API
- Avatar API
- Award Emoji API
- Project badges API
- Group badges API
- Branches API
- Broadcast Messages API
- Project clusters API
- Group clusters API
- Instance clusters API
- Commits API
- Container Registry API
- Custom Attributes API
- Dashboard annotations API
- Dependencies API
- Deploy Keys API
- Deployments API
- Discussions API
- Dockerfiles API
- Environments API
- Epics API
- Events
- Feature Flags API
- Feature flag user lists API
- Freeze Periods API
- Geo Nodes API
- Group Activity Analytics API
- Groups API
- Import API
- Issue Boards API
- Group Issue Boards API
- Issues API
- Epic Issues API
- Issues Statistics API
- Jobs API
- Keys API
- Labels API
- Group Labels API
- License
- Licenses API
- Issue links API
- Epic Links API
- Managed Licenses API
- Markdown API
- Group and project members API
- Merge request approvals API
- Merge requests API
- Project milestones API
- Group milestones API
- Namespaces API
- Notes API
- Notification settings API
- Packages API
- Pages domains API
- Pipeline schedules API
- Pipeline triggers API
- Pipelines API
- Project Aliases API
- Project import/export API
- Project repository storage moves API
- Project statistics API
- Project templates API
- Projects API
- Protected branches API
- Protected tags API
- Releases API
- Release links API
- Repositories API
- Repository files API
- Repository submodules API
- Resource label events API
- Resource milestone events API
- Resource weight events API
- Runners API
- SCIM API
- Search API
- Services API
- Application settings API
- Sidekiq Metrics API
- Snippets API
- Project snippets
- Application statistics API
- Suggest Changes API
- System hooks API
- Tags API
- Todos API
- Users API
- Project-level Variables API
- Group-level Variables API
- Version API
- Vulnerabilities API
- Vulnerability Findings API
- Wikis API
- GraphQL API
- Getting started with GitLab GraphQL API
- GraphQL API Resources
- API V3 to API V4
- Validate the .gitlab-ci.yml (API)
- User Docs
- Abuse reports
- User account
- Active sessions
- Deleting a User account
- Permissions
- Personal access tokens
- Profile preferences
- Threads
- GitLab and SSH keys
- GitLab integrations
- Git
- GitLab.com settings
- Infrastructure as code with Terraform and GitLab
- GitLab keyboard shortcuts
- GitLab Markdown
- AsciiDoc
- GitLab Notification Emails
- GitLab Quick Actions
- Autocomplete characters
- Reserved project and group names
- Search through GitLab
- Advanced Global Search
- Advanced Syntax Search
- Time Tracking
- GitLab To-Do List
- Administrator Docs
- Reference architectures
- Reference architecture: up to 1,000 users
- Reference architecture: up to 2,000 users
- Reference architecture: up to 3,000 users
- Reference architecture: up to 5,000 users
- Reference architecture: up to 10,000 users
- Reference architecture: up to 25,000 users
- Reference architecture: up to 50,000 users
- Troubleshooting a reference architecture set up
- Working with the bundled Consul service
- Configuring PostgreSQL for scaling
- Configuring GitLab application (Rails)
- Load Balancer for multi-node GitLab
- Configuring a Monitoring node for Scaling and High Availability
- NFS
- Working with the bundled PgBouncer service
- Configuring Redis for scaling
- Configuring Sidekiq
- Admin Area settings
- Continuous Integration and Deployment Admin settings
- Custom instance-level project templates
- Diff limits administration
- Enable and disable GitLab features deployed behind feature flags
- Geo nodes Admin Area
- GitLab Pages administration
- Health Check
- Job logs
- Labels administration
- Log system
- PlantUML & GitLab
- Repository checks
- Repository storage paths
- Repository storage types
- Account and limit settings
- Service templates
- System hooks
- Changing your time zone
- Uploads administration
- Abuse reports
- Activating and deactivating users
- Audit Events
- Blocking and unblocking users
- Broadcast Messages
- Elasticsearch integration
- Gitaly
- Gitaly Cluster
- Gitaly reference
- Monitoring GitLab
- Monitoring GitLab with Prometheus
- Performance Bar
- Usage statistics
- Object Storage
- Performing Operations in GitLab
- Cleaning up stale Redis sessions
- Fast lookup of authorized SSH keys in the database
- Filesystem Performance Benchmarking
- Moving repositories managed by GitLab
- Run multiple Sidekiq processes
- Sidekiq MemoryKiller
- Switching to Puma
- Understanding Unicorn and unicorn-worker-killer
- User lookup via OpenSSH's AuthorizedPrincipalsCommand
- GitLab Package Registry administration
- GitLab Container Registry administration
- Replication (Geo)
- Geo database replication
- Geo with external PostgreSQL instances
- Geo configuration
- Using a Geo Server
- Updating the Geo nodes
- Geo with Object storage
- Docker Registry for a secondary node
- Geo for multiple nodes
- Geo security review (Q&A)
- Location-aware Git remote URL with AWS Route53
- Tuning Geo
- Removing secondary Geo nodes
- Geo data types support
- Geo Frequently Asked Questions
- Geo Troubleshooting
- Geo validation tests
- Disaster Recovery (Geo)
- Disaster recovery for planned failover
- Bring a demoted primary node back online
- Automatic background verification
- Rake tasks
- Back up and restore GitLab
- Clean up
- Namespaces
- Maintenance Rake tasks
- Geo Rake Tasks
- GitHub import
- Import bare repositories
- Integrity check Rake task
- LDAP Rake tasks
- Listing repository directories
- Praefect Rake tasks
- Project import/export administration
- Repository storage Rake tasks
- Generate sample Prometheus data
- Uploads migrate Rake tasks
- Uploads sanitize Rake tasks
- User management
- Webhooks administration
- X.509 signatures
- Server hooks
- Static objects external storage
- Updating GitLab
- GitLab release and maintenance policy
- Security
- Password Storage
- Custom password length limits
- Restrict allowed SSH key technologies and minimum length
- Rate limits
- Webhooks and insecure internal web services
- Information exclusivity
- How to reset your root password
- How to unlock a locked user from the command line
- User File Uploads
- How we manage the TLS protocol CRIME vulnerability
- User email confirmation at sign-up
- Security of running jobs
- Proxying assets
- CI/CD Environment Variables
- Contributor and Development Docs
- Contribute to GitLab
- Community members & roles
- Implement design & UI elements
- Issues workflow
- Merge requests workflow
- Code Review Guidelines
- Style guides
- GitLab Architecture Overview
- CI/CD development documentation
- Database guides
- Database Review Guidelines
- Database Review Guidelines
- Migration Style Guide
- What requires downtime?
- Understanding EXPLAIN plans
- Rake tasks for developers
- Mass inserting Rails models
- GitLab Documentation guidelines
- Documentation Style Guide
- Documentation structure and template
- Documentation process
- Documentation site architecture
- Global navigation
- GitLab Docs monthly release process
- Telemetry Guide
- Usage Ping Guide
- Snowplow Guide
- Experiment Guide
- Feature flags in development of GitLab
- Feature flags process
- Developing with feature flags
- Feature flag controls
- Document features deployed behind feature flags
- Frontend Development Guidelines
- Accessibility & Readability
- Ajax
- Architecture
- Axios
- Design Patterns
- Frontend Development Process
- DropLab
- Emojis
- Filter
- Frontend FAQ
- GraphQL
- Icons and SVG Illustrations
- InputSetter
- Performance
- Principles
- Security
- Tooling
- Vuex
- Vue
- Geo (development)
- Geo self-service framework (alpha)
- Gitaly developers guide
- GitLab development style guides
- API style guide
- Go standards and style guidelines
- GraphQL API style guide
- Guidelines for shell commands in the GitLab codebase
- HTML style guide
- JavaScript style guide
- Migration Style Guide
- Newlines style guide
- Python Development Guidelines
- SCSS style guide
- Shell scripting standards and style guidelines
- Sidekiq debugging
- Sidekiq Style Guide
- SQL Query Guidelines
- Vue.js style guide
- Instrumenting Ruby code
- Testing standards and style guidelines
- Flaky tests
- Frontend testing standards and style guidelines
- GitLab tests in the Continuous Integration (CI) context
- Review Apps
- Smoke Tests
- Testing best practices
- Testing levels
- Testing Rails migrations at GitLab
- Testing Rake tasks
- End-to-end Testing
- Beginner's guide to writing end-to-end tests
- End-to-end testing Best Practices
- Dynamic Element Validation
- Flows in GitLab QA
- Page objects in GitLab QA
- Resource class in GitLab QA
- Style guide for writing end-to-end tests
- Testing with feature flags
- Translate GitLab to your language
- Internationalization for GitLab
- Translating GitLab
- Proofread Translations
- Merging translations from CrowdIn
- Value Stream Analytics development guide
- GitLab subscription
- Activate GitLab EE with a license