- Global navigation
- Using YAML data files
- Archived documentation banner
- Linking to source files
- Algolia search engine
- Monthly release process (versions)
- Review Apps for documentation merge requests
While the source of the documentation content is stored in the repositories for each GitLab product, the source that is used to build the documentation site from that content is located at https://gitlab.com/gitlab-org/gitlab-docs.
The following diagram illustrates the relationship between the repositories
from where content is sourced, the
gitlab-docs project, and the published output.
GitLab docs content isn’t kept in the
All documentation files are hosted in the respective repository of each
product, and all together are pulled to generate the docs website:
Learn more about the docs folder structure.
To provide an optimized site structure, design, and a search-engine friendly website, along with a discoverable documentation, we use a few assets for the GitLab Documentation website.
GitLab Docs is built with a combination of external:
Read through the global navigation documentation to understand:
- How the global navigation is built.
- How to add new navigation items.
The pipeline in the
- Tests changes to the docs site code.
- Builds the Docker images used in various pipeline jobs.
- Builds and deploys the docs site itself.
- Generates the review apps when the
review-docs-deployjob is triggered.
Once a week on Mondays, a scheduled pipeline runs and rebuilds the Docker images
used in various pipeline jobs, like
docs-lint. The Docker image configuration files are
located in the Dockerfiles directory.
If you need to rebuild the Docker images immediately (must have maintainer level permissions):
gitlabrepository as well as in
gitlab-docs. Create an image with a different name first and test it to ensure you do not break the pipelines.
gitlab-docs, go to CI/CD > Pipelines.
- Click the Run pipeline button.
- See that a new pipeline is running. The jobs that build the images are in the first
build-images. You can click the pipeline number to see the larger pipeline graph, or click the first (
build-images) stage in the mini pipeline graph to expose the jobs that build the images.
- Click the play () button next to the images you want to rebuild.
- Normally, you do not need to rebuild the
image:gitlab-docs-baseimage, as it rarely changes. If it does need to be rebuilt, be sure to only run
image:docs-lintafter it is finished rebuilding.
- Normally, you do not need to rebuild the
Every four hours a scheduled pipeline builds and deploys the docs site. The pipeline fetches the current docs from the main project’s main branch, builds it with Nanoc and deploys it to https://docs.gitlab.com.
To build and deploy the site immediately (must have the Maintainer role):
gitlab-docs, go to CI/CD > Schedules.
- For the
Build docs.gitlab.com every 4 hoursscheduled pipeline, click the play () button.
Read more about documentation deployments.
The data file must be placed inside the
content/ directory and then it can
be referenced in an ERB template.
Suppose we have the
content/_data/versions.yaml file with the content:
versions: - 10.6 - 10.5 - 10.4
We can then loop over the
versions array with something like:
<% @items['/_data/versions.yaml'][:versions].each do | version | %> <h3><%= version %></h3> <% end &>
Note that the data file must have the
yaml extension (not
yml) and that
we reference the array with a symbol (
A banner is displayed on archived documentation pages with the text
This is archived documentation for
GitLab. Go to the latest. when either:
- The version of the documentation displayed is not the first version entry in
- The documentation was built from the default branch (
For example, if the
online entries for
online: - "14.4" - "14.3" - "14.2"
In this case, the archived documentation banner isn’t displayed:
- For 14.4, the docs built from the
14.4branch. The branch name is the first entry in
- For 14.5-pre, the docs built from the default project branch (
The archived documentation banner is displayed:
- For 14.3.
- For 14.2.
- For any other version.
make sure to bump their version in the front matter. This method guarantees that
your changes take effect by clearing the cache of previous files.
Always use Nanoc’s way of including those files, do not hardcode them in the layouts. For example use:
The links pointing to the files should be similar to:
<%= @items['/path/to/assets/file.*'].path %>
Nanoc then builds and renders those links correctly according with what’s
A helper called
edit_on_gitlab can be used
to link to a page’s source file. We can link to both the simple editor and the
web IDE. Here’s how you can use it in a Nanoc layout:
- Default editor:
<a href="<%= edit_on_gitlab(@item, editor: :simple) %>">Simple editor</a>
- Web IDE:
<a href="<%= edit_on_gitlab(@item, editor: :webide) %>">Web IDE</a>
If you don’t specify
editor:, the simple one is used by default.
The docs site uses Algolia DocSearch for its search function. This is how it works:
- GitLab is a member of the DocSearch program, which is the free tier of Algolia.
- Algolia hosts a DocSearch configuration for the GitLab docs site, and we’ve worked together to refine it.
- That configuration is parsed by their crawler every 24h and stores the DocSearch index on Algolia’s servers.
- On the docs side, we use a DocSearch layout which
is present on pretty much every page except https://docs.gitlab.com/search/,
which uses its own layout. In those layouts,
and an index name (
gitlab) that are needed for Algolia to show the results.
If you’re a GitLab team member, find credentials for the Algolia dashboard
in the shared GitLab 1Password account.
To receive weekly reports of the search usage, search the Google doc with
Email, Slack, and GitLab Groups and Aliases, search for
and add a comment with your email to be added to the alias that gets the weekly
The docs website supports versions and each month we add the latest one to the list. For more information, read about the monthly release process.
If you are contributing to GitLab docs read how to create a Review App with each merge request.