Add latest changes from gitlab-org/gitlab@master

.gitlab-ci.yml

 image: "registry.gitlab.com/gitlab-org/gitlab-build-images:ruby-2.6.3-golang-1.11-git-2.22-chrome-73.0-node-12.x-yarn-1.16-postgresql-9.6-graphicsmagick-1.3.33"
 
 stages:
+  - sync
   - prepare
   - quick-test
   - test
@@ -40,3 +41,4 @@ include:
   - local: .gitlab/ci/setup.gitlab-ci.yml
   - local: .gitlab/ci/test-metadata.gitlab-ci.yml
   - local: .gitlab/ci/yaml.gitlab-ci.yml
+  - local: .gitlab/ci/releases.gitlab-ci.yml

.gitlab/ci/releases.gitlab-ci.yml

+---
+
+# Syncs any changes pushed to a stable branch to the corresponding CE stable
+# branch. We run this prior to any tests so that random failures don't prevent a
+# sync.
+sync-stable-branch:
+  # We don't need/want any global before/after commands, so we overwrite these
+  # settings.
+  image: alpine:edge
+  stage: sync
+  # This job should only run on EE stable branches on the canonical GitLab.com
+  # repository.
+  only:
+    variables:
+      - $CI_SERVER_HOST == "gitlab.com"
+    refs:
+      - /^[\d-]+-stable-ee$/@gitlab-org/gitlab
+  before_script:
+    - apk add --no-cache --update curl bash
+  after_script: []
+  script:
+    - bash scripts/sync-stable-branch.sh

doc/development/documentation/site_architecture/index.md

@@ -4,14 +4,16 @@ description: "Learn how GitLab's documentation website is architectured."
 
 # Documentation site architecture
 
-Learn how we build and architecture [`gitlab-docs`](https://gitlab.com/gitlab-org/gitlab-docs)
-and deploy it to <https://docs.gitlab.com>.
+The [`gitlab-docs`](https://gitlab.com/gitlab-org/gitlab-docs) project hosts
+the repository which is used to generate the GitLab documentation website and
+is deployed to <https://docs.gitlab.com>. It uses the [Nanoc](http://nanoc.ws)
+static site generator.
 
-## Repository
+## Architecture
 
 While the source of the documentation content is stored in GitLab's respective product
-repositories, the source that is used to build the documentation site _from that content_
-is located at <https://gitlab.com/gitlab-org/gitlab-docs>.
+repositories, 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.
@@ -43,8 +45,23 @@ from where content is sourced, the `gitlab-docs` project, and the published outp
     G --> L
 ```
 
-See the [README there](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/README.md)
-for detailed information.
+You will not find any GitLab docs content in the `gitlab-docs` repository.
+All documentation files are hosted in the respective repository of each
+product, and all together are pulled to generate the docs website:
+
+- [GitLab](https://gitlab.com/gitlab-org/gitlab/tree/master/doc)
+- [Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/tree/master/doc)
+- [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/tree/master/docs)
+- [GitLab Chart](https://gitlab.com/charts/gitlab/tree/master/doc)
+
+NOTE: **Note:**
+In September 2019, we [moved towards a single codebase](https://gitlab.com/gitlab-org/gitlab-ee/issues/2952),
+as such the docs for CE and EE are now identical. For historical reasons and
+in order not to break any existing links throughout the internet, we still
+maintain the CE docs (`https://docs.gitlab.com/ce/`), although it is hidden
+from the website, and is now a symlink to the EE docs. When
+[Pages supports redirects](https://gitlab.com/gitlab-org/gitlab-pages/issues/24),
+we will be able to remove this completely.
 
 ## Assets
 
@@ -73,28 +90,112 @@ Read through [the global navigation documentation](global_nav.md) to understand:
 - How the global navigation is built.
 - How to add new navigation items.
 
-## Deployment
+<!--
+## Helpers
 
-The docs site is deployed to production with GitLab Pages, and previewed in
-merge requests with Review Apps.
+TBA
+-->
 
-The deployment aspects will be soon transferred from the [original document](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/README.md)
-to this page.
+## Using YAML data files
 
-<!--
-## Repositories
+The easiest way to achieve something similar to
+[Jekyll's data files](https://jekyllrb.com/docs/datafiles/) in Nanoc is by
+using the [`@items`](https://nanoc.ws/doc/reference/variables/#items-and-layouts)
+variable.
 
-TBA
+The data file must be placed inside the `content/` directory and then it can
+be referenced in an ERB template.
 
-## Search engine
+Suppose we have the `content/_data/versions.yaml` file with the content:
 
-TBA
+```yaml
+versions:
+- 10.6
+- 10.5
+- 10.4
+```
 
-## Versions
+We can then loop over the `versions` array with something like:
 
-TBA
+```erb
+<% @items['/_data/versions.yaml'][:versions].each do | version | %>
 
-## Helpers
+<h3><%= version %></h3>
 
-TBA
--->
+<% end &>
+```
+
+Note that the data file must have the `yaml` extension (not `yml`) and that
+we reference the array with a symbol (`:versions`).
+
+## Bumping versions of CSS and Javascript
+
+Whenever the custom CSS and Javascript files under `content/assets/` change,
+make sure to bump their version in the frontmatter. This method guarantees that
+your changes will 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:
+
+```erb
+<script async type="application/javascript" src="<%= @items['/assets/javascripts/badges.*'].path %>"></script>
+
+<link rel="stylesheet" href="<%= @items['/assets/stylesheets/toc.*'].path %>">
+```
+
+The links pointing to the files should be similar to:
+
+```erb
+<%= @items['/path/to/assets/file.*'].path %>
+```
+
+Nanoc will then build and render those links correctly according with what's
+defined in [`Rules`](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/Rules).
+
+## Linking to source files
+
+A helper called [`edit_on_gitlab`](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/lib/helpers/edit_on_gitlab.rb) 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.
+
+## Algolia search engine
+
+The docs site uses [Algolia docsearch](https://community.algolia.com/docsearch/)
+for its search function. This is how it works:
+
+1. GitLab is a member of the [docsearch program](https://community.algolia.com/docsearch/#join-docsearch-program),
+   which is the free tier of [Algolia](https://www.algolia.com/).
+1. Algolia hosts a [doscsearch config](https://github.com/algolia/docsearch-configs/blob/master/configs/gitlab.json)
+   for the GitLab docs site, and we've worked together to refine it.
+1. That [config](https://community.algolia.com/docsearch/config-file.html) is
+   parsed by their [crawler](https://community.algolia.com/docsearch/crawler-overview.html)
+   every 24h and [stores](https://community.algolia.com/docsearch/inside-the-engine.html)
+   the [docsearch index](https://community.algolia.com/docsearch/how-do-we-build-an-index.html)
+   on [Algolia's servers](https://community.algolia.com/docsearch/faq.html#where-is-my-data-hosted%3F).
+1. On the docs side, we use a [docsearch layout](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/layouts/docsearch.html) which
+   is present on pretty much every page except <https://docs.gitlab.com/search/>,
+   which uses its [own layout](https://gitlab.com/gitlab-org/gitlab-docs/blob/master/layouts/instantsearch.html). In those layouts,
+   there's a javascript snippet which initiates docsearch by using an API key
+   and an index name (`gitlab`) that are needed for Algolia to show the results.
+
+NOTE: **For GitLab employees:**
+The credentials to access the Algolia dashboard are stored in 1Password. If you
+want to receive weekly reports of the search usage, search the Google doc with
+title "Email, Slack, and GitLab Groups and Aliases", search for `docsearch`,
+and add a comment with your email to be added to the alias that gets the weekly
+reports.
+
+## Monthly release process (versions)
+
+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](release_process.md).
+
+## Review Apps for documentation merge requests
+
+If you are contributing to GitLab docs read how to [create a Review App with each
+merge request](../index.md#previewing-the-changes-live).

doc/development/testing_guide/review_apps.md

@@ -189,10 +189,10 @@ that the `review-apps-ce/ee` cluster is unhealthy. Leading indicators may be hea
 
 The following items may help diagnose this:
 
-- [Instance group CPU Utilization in GCP](https://console.cloud.google.com/compute/instanceGroups/details/us-central1-b/gke-review-apps-ee-preemp-n1-standard-8affc0f5-grp?project=gitlab-review-apps&tab=monitoring&graph=GCE_CPU&duration=P30D) - helpful to identify if nodes are problematic or the entire cluster is trending towards unhealthy
-- [Instance Group size in GCP](https://console.cloud.google.com/compute/instanceGroups/details/us-central1-b/gke-review-apps-ee-preemp-n1-standard-8affc0f5-grp?project=gitlab-review-apps&tab=monitoring&graph=GCE_SIZE&duration=P30D) - aids in identifying load spikes on the cluster. Kubernetes will add nodes up to 220 based on total resource requests.
-- `kubectl top nodes --sort-by=cpu` - can identify if node spikes are common or load on specific nodes which may get rebalanced by the Kubernetes scheduler.
-- `kubectl top pods --sort-by=cpu` -
+- [Review Apps Health dashboard](https://app.google.stackdriver.com/dashboards/6798952013815386466?project=gitlab-review-apps&timeDomain=1d)
+  - Aids in identifying load spikes on the cluster, and if nodes are problematic or the entire cluster is trending towards unhealthy.
+- `kubectl top nodes | sort --key 3 --numeric` - can identify if node spikes are common or load on specific nodes which may get rebalanced by the Kubernetes scheduler.
+- `kubectl top pods | sort --key 2 --numeric` -
 - [K9s] - K9s is a powerful command line dashboard which allows you to filter by labels. This can help identify trends with apps exceeding the [review-app resource requests](https://gitlab.com/gitlab-org/gitlab/blob/master/scripts/review_apps/base-config.yaml). Kubernetes will schedule pods to nodes based on resource requests and allow for CPU usage up to the limits.
   - In K9s you can sort or add filters by typing the `/` character
     - `-lrelease=<review-app-slug>` - filters down to all pods for a release. This aids in determining what is having issues in a single deployment

lib/gitlab/experimentation.rb

@@ -43,7 +43,7 @@ module Gitlab
       end
 
       def experiment_enabled?(experiment_key)
-        Experimentation.enabled_for_user?(experiment_key, experimentation_subject_index)
+        Experimentation.enabled_for_user?(experiment_key, experimentation_subject_index) || forced_enabled?(experiment_key)
       end
 
       def track_experiment_event(experiment_key, action)
@@ -94,6 +94,10 @@ module Gitlab
 
         experiment_enabled?(experiment_key) ? 'experimental_group' : 'control_group'
       end
+
+      def forced_enabled?(experiment_key)
+        params.has_key?(:force_experiment) && params[:force_experiment] == experiment_key.to_s
+      end
     end
 
     class << self

qa/qa/resource/user.rb

@@ -93,6 +93,7 @@ module QA
         if Runtime::Env.signup_disabled?
           self.fabricate_via_api! do |user|
             user.username = username
+            user.password = password
           end
         else
           self.fabricate!

scripts/sync-stable-branch.sh

+#!/usr/bin/env bash
+
+# This script triggers a merge train job to sync an EE stable branch to its
+# corresponding CE stable branch.
+
+set -e
+
+if [[ "$MERGE_TRAIN_TRIGGER_TOKEN" == '' ]]
+then
+    echo 'The variable MERGE_TRAIN_TRIGGER_TOKEN must be set to a non-empy value'
+    exit 1
+fi
+
+if [[ "$MERGE_TRAIN_TRIGGER_URL" == '' ]]
+then
+    echo 'The variable MERGE_TRAIN_TRIGGER_URL must be set to a non-empy value'
+    exit 1
+fi
+
+if [[ "$CI_COMMIT_REF_NAME" == '' ]]
+then
+    echo 'The variable CI_COMMIT_REF_NAME must be set to a non-empy value'
+    exit 1
+fi
+
+curl -X POST \
+    -F token="$MERGE_TRAIN_TRIGGER_TOKEN" \
+    -F ref=master \
+    -F "variables[MERGE_FOSS]=1" \
+    -F "variables[SOURCE_BRANCH]=$CI_COMMIT_REF_NAME" \
+    -F "variables[TARGET_BRANCH]=${CI_COMMIT_REF_NAME/-ee/}" \
+    "$MERGE_TRAIN_TRIGGER_URL"

spec/lib/gitlab/experimentation_spec.rb

@@ -71,6 +71,24 @@ describe Gitlab::Experimentation do
           controller.experiment_enabled?(:test_experiment)
         end
       end
+
+      describe 'URL parameter to force enable experiment' do
+        context 'is not present' do
+          it 'returns false' do
+            get :index, params: { force_experiment: :test_experiment2 }
+
+            expect(controller.experiment_enabled?(:test_experiment)).to be_falsey
+          end
+        end
+
+        context 'is present' do
+          it 'returns true' do
+            get :index, params: { force_experiment: :test_experiment }
+
+            expect(controller.experiment_enabled?(:test_experiment)).to be_truthy
+          end
+        end
+      end
     end
 
     describe '#track_experiment_event' do