Add latest changes from gitlab-org/gitlab@master

app/assets/stylesheets/framework/typography.scss

@@ -545,6 +545,24 @@
       }
     }
   }
+
+  /* AsciiDoc(tor) built-in alignment roles */
+
+  .text-left {
+    text-align: left !important;
+  }
+
+  .text-right {
+    text-align: right !important;
+  }
+
+  .text-center {
+    text-align: center !important;
+  }
+
+  .text-justify {
+    text-align: justify !important;
+  }
 }
 
 /**

app/models/concerns/cache_markdown_field.rb

@@ -102,7 +102,7 @@ module CacheMarkdownField
   def updated_cached_html_for(markdown_field)
     return unless cached_markdown_fields.markdown_fields.include?(markdown_field)
 
-    refresh_markdown_cache if attribute_invalidated?(cached_markdown_fields.html_field(markdown_field))
+    refresh_markdown_cache! if attribute_invalidated?(cached_markdown_fields.html_field(markdown_field))
 
     cached_html_for(markdown_field)
   end

app/services/import/github_service.rb

@@ -10,15 +10,26 @@ module Import
         return error(_('This namespace has already been taken! Please choose another one.'), :unprocessable_entity)
       end
 
-      project = Gitlab::LegacyGithubImport::ProjectCreator
+      project = create_project(access_params, provider)
-                  .new(repo, project_name, target_namespace, current_user, access_params, type: provider)
-                  .execute(extra_project_attrs)
 
       if project.persisted?
         success(project)
       else
         error(project_save_error(project), :unprocessable_entity)
       end
+    rescue Octokit::Error => e
+      log_error(e)
+    end
+
+    def create_project(access_params, provider)
+      Gitlab::LegacyGithubImport::ProjectCreator.new(
+        repo,
+        project_name,
+        target_namespace,
+        current_user,
+        access_params,
+        type: provider
+      ).execute(extra_project_attrs)
     end
 
     def repo
@@ -44,6 +55,18 @@ module Import
     def authorized?
       can?(current_user, :create_projects, target_namespace)
     end
+
+    private
+
+    def log_error(exception)
+      Gitlab::Import::Logger.error(
+        message: 'Import failed due to a GitHub error',
+        status: exception.response_status,
+        error: exception.response_body
+      )
+
+      error(_('Import failed due to a GitHub error: %{original}') % { original: exception.response_body }, :unprocessable_entity)
+    end
   end
 end
 

changelogs/unreleased/218745-single-issue-api-performance-regression-degraded-by-8000ms-after-u.yml

@@ -0,0 +1,5 @@
+---
+title: Fix issue and MR API performance regression when Markdown cache is stale
+merge_request: 33235
+author:
+type: fixed

changelogs/unreleased/asciidoc-alignment-roles.yml

@@ -0,0 +1,5 @@
+---
+title: 'AsciiDoc: Add support for built-in alignment roles.'
+merge_request: 32928
+author: mnrvwl
+type: fixed

changelogs/unreleased/fj-bump-lfs-token-default-expiration-time.yml

@@ -0,0 +1,5 @@
+---
+title: Increase LFS token default time to 2 hours
+merge_request: 33140
+author:
+type: changed

doc/.vale/gitlab/CurlStringsQuoted.yml

@@ -0,0 +1,13 @@
+---
+# Error: gitlab.CurlStringsQuoted
+#
+# Ensures all codeblocks using curl quote any URL strings.
+#
+# For a list of all options, see https://errata-ai.github.io/vale/styles/
+extends: existence
+message: 'Curl commands must wrap URLs in double quotes ("): %s'
+link: https://docs.gitlab.com/ee/development/documentation/styleguide.html#code-blocks
+level: warning
+scope: code
+raw:
+  - 'curl.*[^"=]https?://.*'

doc/administration/gitaly/index.md

@@ -6,9 +6,14 @@ components can read or write Git data. GitLab components that access Git
 repositories (GitLab Rails, GitLab Shell, GitLab Workhorse, etc.) act as clients
 to Gitaly. End users do not have direct access to Gitaly.
 
-On this page, *Gitaly server* refers to a standalone node that only runs Gitaly
+On this page:
-and *Gitaly client* is a GitLab Rails app node that runs all other processes
+
-except Gitaly.
+- **Gitaly server** refers to any node that runs Gitaly itself.
+- **Gitaly client** refers to any node that runs a process that makes requests of the
+  Gitaly server. Processes include, but are not limited to:
+  - GitLab Rails application.
+  - GitLab Shell.
+  - GitLab Workhorse.
 
 CAUTION: **Caution:**
 From GitLab 13.0, using NFS for Git repositories is deprecated. In GitLab 14.0,
@@ -43,7 +48,8 @@ This is an optional way to deploy Gitaly which can benefit GitLab
 installations that are larger than a single machine. Most
 installations will be better served with the default configuration
 used by Omnibus and the GitLab source installation guide.
-Follow transition to Gitaly on its own server, [Gitaly servers will need to be upgraded before other servers in your cluster](https://docs.gitlab.com/omnibus/update/#upgrading-gitaly-servers).
+Following transition to Gitaly on its own server,
+[Gitaly servers will need to be upgraded before Gitaly clients in your cluster](https://docs.gitlab.com/omnibus/update/#upgrading-gitaly-servers).
 
 Starting with GitLab 11.4, Gitaly is able to serve all Git requests without
 requiring a shared NFS mount for Git repository data.
@@ -51,7 +57,7 @@ Between 11.4 and 11.8 the exception was the
 [Elasticsearch indexer](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer).
 But since 11.8 the indexer uses Gitaly for data access as well. NFS can still
 be leveraged for redundancy on block level of the Git data. But only has to
-be mounted on the Gitaly server.
+be mounted on the Gitaly servers.
 
 From GitLab v11.8 to v12.2, it is possible to use Elasticsearch in conjunction with
 a Gitaly setup that isn't utilising NFS. In order to use Elasticsearch in this
@@ -71,7 +77,7 @@ The following list depicts what the network architecture of Gitaly is:
   topology.
 - A `(Gitaly address, Gitaly token)` corresponds to a Gitaly server.
 - A Gitaly server hosts one or more storages.
-- A GitLab server can use one or more Gitaly servers.
+- A Gitaly client can use one or more Gitaly servers.
 - Gitaly addresses must be specified in such a way that they resolve
   correctly for ALL Gitaly clients.
 - Gitaly clients are: Puma/Unicorn, Sidekiq, GitLab Workhorse,
@@ -109,20 +115,19 @@ Omnibus GitLab or install it from source:
 ### 2. Authentication
 
 Gitaly and GitLab use two shared secrets for authentication, one to authenticate gRPC requests
-to Gitaly, and a second for authentication callbacks from GitLab-Shell to the GitLab internal API.
+to Gitaly, and a second for authentication callbacks from GitLab Shell to the GitLab internal API.
 
 **For Omnibus GitLab**
 
 To configure the Gitaly token:
 
-1. On the client server, edit `/etc/gitlab/gitlab.rb`:
+1. On the Gitaly clients, edit `/etc/gitlab/gitlab.rb`:
 
    ```ruby
    gitlab_rails['gitaly_token'] = 'abc123secret'
    ```
 
 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
-
 1. On the Gitaly server, edit `/etc/gitlab/gitlab.rb`:
 
    ```ruby
@@ -131,22 +136,21 @@ To configure the Gitaly token:
 
 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 
-There are two ways to configure the GitLab-Shell token:
+There are two ways to configure the GitLab Shell token:
 
-1. Copy `/etc/gitlab/gitlab-secrets.json` from the client server to same path on the Gitaly server.
+1. Copy `/etc/gitlab/gitlab-secrets.json` from the Gitaly client to same path on the Gitaly servers (and any other Gitaly clients).
-1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) on Gitaly servers.
 
 **OR**
 
-1. On the client server, edit `/etc/gitlab/gitlab.rb`:
+1. On the Gitaly clients, edit `/etc/gitlab/gitlab.rb`:
 
    ```ruby
    gitlab_shell['secret_token'] = 'shellsecret'
    ```
 
 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
-
+1. On the Gitaly servers, edit `/etc/gitlab/gitlab.rb`:
-1. On the Gitaly server, edit `/etc/gitlab/gitlab.rb`:
 
    ```ruby
    gitlab_shell['secret_token'] = 'shellsecret'
@@ -156,9 +160,9 @@ There are two ways to configure the GitLab-Shell token:
 
 **For installations from source**
 
-1. Copy `/home/git/gitlab/.gitlab_shell_secret` from the client server to the same path on the Gitaly
+1. Copy `/home/git/gitlab/.gitlab_shell_secret` from the Gitaly client to the same path on the Gitaly
-server.
+servers (and any other Gitaly clients).
-1. On the client server, edit `/home/git/gitlab/config/gitlab.yml`:
+1. On the Gitaly clients, edit `/home/git/gitlab/config/gitlab.yml`:
 
    ```yaml
    gitlab:
@@ -166,12 +170,20 @@ server.
        token: 'abc123secret'
    ```
 
+1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
+1. On the Gitaly servers, edit `/home/git/gitaly/config.toml`:
+
+   ```toml
+   [auth]
+   token = 'abc123secret'
+   ```
+
 1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
 
 ### 3. Gitaly server configuration
 
-Next, on the Gitaly servers, you need to configure storage paths, enable
+Next, on the Gitaly servers, you need to configure storage paths and enable
-the network listener and configure the token.
+the network listener.
 
 NOTE: **Note:** If you want to reduce the risk of downtime when you enable
 authentication you can temporarily disable enforcement, see [the
@@ -221,7 +233,7 @@ authentication](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/configurati
    # Configure the gitlab-shell API callback URL. Without this, `git push` will
    # fail. This can be your 'front door' GitLab URL or an internal load
    # balancer.
-   # Don't forget to copy `/etc/gitlab/gitlab-secrets.json` from web server to Gitaly server.
+   # Don't forget to copy `/etc/gitlab/gitlab-secrets.json` from Gitaly client to Gitaly server.
    gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
 
    # Make Gitaly accept connections on all network interfaces. You must use
@@ -230,7 +242,7 @@ authentication](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/configurati
    gitaly['listen_addr'] = "0.0.0.0:8075"
    ```
 
-1. Append the following to `/etc/gitlab/gitlab.rb` for each respective server:
+1. Append the following to `/etc/gitlab/gitlab.rb` for each respective Gitaly server:
 
    <!--
    updates to following example must also be made at
@@ -262,27 +274,24 @@ authentication](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/configurati
 
 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 1. Run `sudo /opt/gitlab/embedded/service/gitlab-shell/bin/check -config /opt/gitlab/embedded/service/gitlab-shell/config.yml`
-to confirm that Gitaly can perform callbacks to the internal API.
+to confirm that Gitaly can perform callbacks to the GitLab internal API.
 
 **For installations from source**
 
-1. On the client node(s), edit `/home/git/gitaly/config.toml`:
+1. Edit `/home/git/gitaly/config.toml`:
 
    ```toml
    listen_addr = '0.0.0.0:8075'
 
    internal_socket_dir = '/var/opt/gitlab/gitaly'
 
-   [auth]
-   token = 'abc123secret'
-
    [logging]
    format = 'json'
    level = 'info'
    dir = '/var/log/gitaly'
    ```
 
-1. Append the following to `/home/git/gitaly/config.toml` for each respective server:
+1. Append the following to `/home/git/gitaly/config.toml` for each respective Gitaly server:
 
    On `gitaly1.internal`:
 
@@ -304,33 +313,33 @@ to confirm that Gitaly can perform callbacks to the internal API.
    path = '/srv/gitlab/git-data/repositories'
    ```
 
-1. On each Gitaly server, edit `/home/git/gitlab-shell/config.yml`:
+1. Edit `/home/git/gitlab-shell/config.yml`:
 
    ```yaml
    gitlab_url: https://gitlab.example.com
    ```
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
+1. Save the files and [restart GitLab](../restart_gitlab.md#installations-from-source).
 1. Run `sudo -u git /home/git/gitlab-shell/bin/check -config /home/git/gitlab-shell/config.yml`
-to confirm that Gitaly can perform callbacks to the internal API.
+to confirm that Gitaly can perform callbacks to the GitLab internal API.
 
-### 4. Converting clients to use the Gitaly server
+### 4. Converting Gitaly clients to use the Gitaly servers
 
-As the final step, you need to update the client machines to switch from using
+As the final step, you need to update Gitaly clients to switch from using
-their local Gitaly service to the new Gitaly server you just configured. This
+local Gitaly service to use the Gitaly servers you just configured. This
 is a risky step because if there is any sort of network, firewall, or name
-resolution problem preventing your GitLab server from reaching the Gitaly server,
+resolution problem preventing your Gitaly clients from reaching the Gitaly servers,
 then all Gitaly requests will fail.
 
 Additionally, you need to
 [disable Rugged if previously manually enabled](../high_availability/nfs.md#improving-nfs-performance-with-gitlab).
 
 We assume that your `gitaly1.internal` Gitaly server can be reached at
-`gitaly1.internal:8075` from your GitLab server, and that Gitaly server
+`gitaly1.internal:8075` from your Gitaly clients, and that Gitaly server
 can read and write to `/mnt/gitlab/default` and `/mnt/gitlab/storage1`.
 
 We assume also that your `gitaly2.internal` Gitaly server can be reached at
-`gitaly2.internal:8075` from your GitLab server, and that Gitaly server
+`gitaly2.internal:8075` from your Gitaly clients, and that Gitaly server
 can read and write to `/mnt/gitlab/storage2`.
 
 **For Omnibus GitLab**
@@ -346,7 +355,7 @@ can read and write to `/mnt/gitlab/storage2`.
    ```
 
 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
-1. Run `sudo gitlab-rake gitlab:gitaly:check` to confirm the client can connect to Gitaly.
+1. Run `sudo gitlab-rake gitlab:gitaly:check` to confirm the Gitaly client can connect to Gitaly servers.
 1. Tail the logs to see the requests:
 
    ```shell
@@ -379,7 +388,7 @@ can read and write to `/mnt/gitlab/storage2`.
 
 1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
 1. Run `sudo -u git -H bundle exec rake gitlab:gitaly:check RAILS_ENV=production` to
-confirm the client can connect to Gitaly.
+confirm the Gitaly client can connect to Gitaly servers.
 1. Tail the logs to see the requests:
 
    ```shell
@@ -388,12 +397,12 @@ confirm the client can connect to Gitaly.
 
 When you tail the Gitaly logs on your Gitaly server you should see requests
 coming in. One sure way to trigger a Gitaly request is to clone a repository
-from your GitLab server over HTTP.
+from GitLab over HTTP or HTTPS.
 
 DANGER: **Danger:**
 If you have [Server hooks](../server_hooks.md) configured,
-either per repository or globally, you must move these to the Gitaly node.
+either per repository or globally, you must move these to the Gitaly servers.
-If you have multiple Gitaly nodes, copy your server hook(s) to all nodes.
+If you have multiple Gitaly servers, copy your server hooks to all Gitaly servers.
 
 ### Disabling the Gitaly service in a cluster environment
 
@@ -405,7 +414,7 @@ cluster configuration, where different services run on different
 machines. Disabling Gitaly on all machines in the cluster is not a
 valid configuration.
 
-To disable Gitaly on a client node:
+To disable Gitaly on a GitLab server:
 
 **For Omnibus GitLab**
 
@@ -436,13 +445,16 @@ with a Gitaly instance that listens for secure connections you will need to use
 scheme in the `gitaly_address` of the corresponding storage entry in the GitLab configuration.
 
 You will need to bring your own certificates as this isn't provided automatically.
-The certificate, or its certificate authority, must be installed on all Gitaly
+The certificate corresponding to each Gitaly server will need to be installed
-nodes (including the Gitaly node using the certificate) and on all client nodes
+on that Gitaly server.
+
+Additionally the certificate, or its certificate authority, must be installed on all Gitaly servers
+(including the Gitaly server using the certificate) and on all Gitaly clients
 that communicate with it following the procedure described in
-[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates).
+[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates) (and repeated below).
 
 NOTE: **Note**
-The self-signed certificate must specify the address you use to access the
+The certificate must specify the address you use to access the
 Gitaly server. If you are addressing the Gitaly server by a hostname, you can
 either use the Common Name field for this, or add it as a Subject Alternative
 Name. If you are addressing the Gitaly server by its IP address, you must add it
@@ -459,7 +471,14 @@ To configure Gitaly with TLS:
 
 **For Omnibus GitLab**
 
-1. On the client node(s), edit `/etc/gitlab/gitlab.rb` as follows:
+1. Create certificates for Gitaly servers.
+1. On the Gitaly clients, copy the certificates, or their certificate authority, into the `/etc/gitlab/trusted-certs`:
+
+   ```shell
+   sudo cp cert.pem /etc/gitlab/trusted-certs/
+   ```
+
+1. On the Gitaly clients, edit `git_data_dirs` in `/etc/gitlab/gitlab.rb` as follows:
 
    ```ruby
    git_data_dirs({
@@ -467,19 +486,10 @@ To configure Gitaly with TLS:
      'storage1' => { 'gitaly_address' => 'tls://gitaly1.internal:9999' },
      'storage2' => { 'gitaly_address' => 'tls://gitaly2.internal:9999' },
    })
-
-   gitlab_rails['gitaly_token'] = 'abc123secret'
-   gitlab_shell['secret_token'] = 'shellsecret'
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) on client node(s).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
-1. On the client node(s), copy the cert into the `/etc/gitlab/trusted-certs`:
+1. On the Gitaly servers, create the `/etc/gitlab/ssl` directory and copy your key and certificate there:
-
-  ```shell
-  sudo cp cert.pem /etc/gitlab/trusted-certs/
-  ```
-
-1. On the Gitaly server, create the `/etc/gitlab/ssl` directory and copy your key and certificate there:
 
    ```shell
    sudo mkdir -p /etc/gitlab/ssl
@@ -488,14 +498,14 @@ To configure Gitaly with TLS:
    sudo chmod 644 key.pem cert.pem
    ```
 
-1. Copy the cert to `/etc/gitlab/trusted-certs` so Gitaly will trust the cert when
+1. Copy all Gitaly server certificates, or their certificate authority, to `/etc/gitlab/trusted-certs` so Gitaly server will trust the certificate when
-calling into itself:
+calling into itself or other Gitaly servers:
 
    ```shell
-  sudo cp /etc/gitlab/ssl/cert.pem /etc/gitlab/trusted-certs/
+   sudo cp cert1.pem cert2.pem /etc/gitlab/trusted-certs/
    ```
 
-1. On the Gitaly server node(s), edit `/etc/gitlab/gitlab.rb` and add:
+1. Edit `/etc/gitlab/gitlab.rb` and add:
 
    <!--
    updates to following example must also be made at
@@ -508,23 +518,23 @@ calling into itself:
    gitaly['key_path'] = "/etc/gitlab/ssl/key.pem"
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) on Gitaly server node(s).
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 1. (Optional) After [verifying that all Gitaly traffic is being served over TLS](#observe-type-of-gitaly-connections),
    you can improve security by disabling non-TLS connections by commenting out
    or deleting `gitaly['listen_addr']` in `/etc/gitlab/gitlab.rb`, saving the file,
-   and [reconfiguring GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure)
+   and [reconfiguring GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
-   on Gitaly server node(s).
 
 **For installations from source**
 
-1. On the client node(s), add the cert to the system trusted certs:
+1. Create certificates for Gitaly servers.
+1. On the Gitaly clients, copy the certificates into the system trusted certificates:
 
    ```shell
    sudo cp cert.pem /usr/local/share/ca-certificates/gitaly.crt
    sudo update-ca-certificates
    ```
 
-1. On the client node(s), edit `/home/git/gitlab/config/gitlab.yml` as follows:
+1. On the Gitaly clients, edit `storages` in `/home/git/gitlab/config/gitlab.yml` as follows:
 
    ```yaml
    gitlab:
@@ -539,9 +549,6 @@ calling into itself:
          storage2:
            gitaly_address: tls://gitaly2.internal:9999
            path: /some/dummy/path
-
-     gitaly:
-       token: 'abc123secret'
    ```
 
    NOTE: **Note:**
@@ -549,18 +556,14 @@ calling into itself:
    data will be stored in this folder. This will no longer be necessary after
    [this issue](https://gitlab.com/gitlab-org/gitaly/-/issues/1282) is resolved.
 
-1. Save the file and[restart GitLab](../restart_gitlab.md#installations-from-source)
+1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
-on client node(s).
+1. On the Gitaly servers, create or edit `/etc/default/gitlab` and add:
-1. Copy `/home/git/gitlab/.gitlab_shell_secret` from the client server to the same
-path on the Gitaly server.
-1. On the Gitaly server, create or edit `/etc/default/gitlab` and add:
 
    ```shell
    export SSL_CERT_DIR=/etc/gitlab/ssl
    ```
 
-1. Save the file.
+1. On the Gitaly servers, create the `/etc/gitlab/ssl` directory and copy your key and certificate there:
-1. Create the `/etc/gitlab/ssl` directory and copy your key and certificate there:
 
    ```shell
    sudo mkdir -p /etc/gitlab/ssl
@@ -569,15 +572,14 @@ path on the Gitaly server.
    sudo chmod 644 key.pem cert.pem
    ```
 
-1. On the Gitaly server, add the cert to the system trusted certs so Gitaly will trust it
+1. Copy all Gitaly server certificates, or their certificate authority, to the system trusted certificates so Gitaly server will trust the certificate when calling into itself or other Gitaly servers.
-when calling into itself:
 
    ```shell
    sudo cp cert.pem /usr/local/share/ca-certificates/gitaly.crt
    sudo update-ca-certificates
    ```
 
-1. On the Gitaly server node(s), edit `/home/git/gitaly/config.toml` and add:
+1. Edit `/home/git/gitaly/config.toml` and add:
 
    ```toml
    tls_listen_addr = '0.0.0.0:9999'
@@ -587,12 +589,11 @@ when calling into itself:
    key_path = '/etc/gitlab/ssl/key.pem'
    ```
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) on Gitaly server node(s).
+1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
 1. (Optional) After [verifying that all Gitaly traffic is being served over TLS](#observe-type-of-gitaly-connections),
    you can improve security by disabling non-TLS connections by commenting out
    or deleting `listen_addr` in `/home/git/gitaly/config.toml`, saving the file,
-   and [restarting GitLab](../restart_gitlab.md#installations-from-source)
+   and [restarting GitLab](../restart_gitlab.md#installations-from-source).
-   on Gitaly server node(s).
 
 ### Observe type of Gitaly connections
 
@@ -673,8 +674,8 @@ gitaly['concurrency'] = [
 
 This will limit the number of in-flight RPC calls for the given RPC's.
 The limit is applied per repository. In the example above, each on the
-Gitaly server can have at most 20 simultaneous PostUploadPack calls in
+Gitaly server can have at most 20 simultaneous `PostUploadPack` calls in
-flight, and the same for SSHUploadPack. If another request comes in for
+flight, and the same for `SSHUploadPack`. If another request comes in for
 a repository that has used up its 20 slots, that request will get
 queued.
 
@@ -686,7 +687,7 @@ reporting about the concurrency limiter. In Prometheus, look for the
 `gitaly_rate_limiting_seconds` metrics.
 
 The name of the Prometheus metric is not quite right because this is a
-concurrency limiter, not a rate limiter. If a client makes 1000 requests
+concurrency limiter, not a rate limiter. If a Gitaly client makes 1000 requests
 in a row in a very short timespan, the concurrency will not exceed 1,
 and this mechanism (the concurrency limiter) will do nothing.
 
@@ -697,7 +698,7 @@ downtime, or causes outages, or both. If you are careful, though, you
 *can* rotate Gitaly credentials without a service interruption.
 
 This procedure also works if you are running GitLab on a single server.
-In that case, "Gitaly servers" and "Gitaly clients" refers to the same
+In that case, "Gitaly server" and "Gitaly client" refers to the same
 machine.
 
 ### 1. Monitor current authentication behavior
@@ -723,7 +724,7 @@ The only non-zero number should have `enforced="true",status="ok"`. If
 you have other non-zero numbers, something is wrong in your
 configuration.
 
-The 'status="ok"' number reflects your current request rate. In the example
+The `status="ok"` number reflects your current request rate. In the example
 above, Gitaly is handling about 4000 requests per second.
 
 Now you have established that you can monitor the Gitaly authentication
@@ -894,9 +895,9 @@ which is still under development as of December 2019.
 
 ## Troubleshooting Gitaly
 
-### Checking versions when using standalone Gitaly nodes
+### Checking versions when using standalone Gitaly servers
 
-When using standalone Gitaly nodes, you must make sure they are the same version
+When using standalone Gitaly servers, you must make sure they are the same version
 as GitLab to ensure full compatibility. Check **Admin Area > Gitaly Servers** on
 your GitLab instance and confirm all Gitaly Servers are `Up to date`.
 
@@ -931,8 +932,8 @@ gitaly-debug -h
 remote: GitLab: 401 Unauthorized
 ```
 
-You will need to sync your `gitlab-secrets.json` file with your GitLab
+You will need to sync your `gitlab-secrets.json` file with your Gitaly clients (GitLab
-app nodes.
+app nodes).
 
 ### Client side gRPC logs
 
@@ -975,11 +976,11 @@ If you're running Gitaly on its own server and notice that users can
 successfully clone and fetch repositories (via both SSH and HTTPS), but can't
 push to them or make changes to the repository in the web UI without getting a
 `401 Unauthorized` message, then it's possible Gitaly is failing to authenticate
-with the other nodes due to having the [wrong secrets file](#3-gitaly-server-configuration).
+with the Gitaly client due to having the [wrong secrets file](#3-gitaly-server-configuration).
 
 Confirm the following are all true:
 
-- When any user performs a `git push` to any repository on this Gitaly node, it
+- When any user performs a `git push` to any repository on this Gitaly server, it
   fails with the following error (note the `401 Unauthorized`):
 
   ```shell
@@ -993,7 +994,8 @@ Confirm the following are all true:
   UI, it immediately fails with a red `401 Unauthorized` banner.
 - Creating a new project and [initializing it with a README](../../gitlab-basics/create-project.md#blank-projects)
   successfully creates the project but doesn't create the README.
-- When [tailing the logs](https://docs.gitlab.com/omnibus/settings/logs.html#tail-logs-in-a-console-on-the-server) on an app node and reproducing the error, you get `401` errors
+- When [tailing the logs](https://docs.gitlab.com/omnibus/settings/logs.html#tail-logs-in-a-console-on-the-server)
+  on a Gitaly client and reproducing the error, you get `401` errors
   when reaching the `/api/v4/internal/allowed` endpoint:
 
   ```shell
@@ -1056,13 +1058,15 @@ Confirm the following are all true:
   ```
 
 To fix this problem, confirm that your [`gitlab-secrets.json` file](#3-gitaly-server-configuration)
-on the Gitaly node matches the one on all other nodes. If it doesn't match,
+on the Gitaly server matches the one on Gitaly client. If it doesn't match,
-update the secrets file on the Gitaly node to match the others, then
+update the secrets file on the Gitaly server to match the Gitaly client, then
-[reconfigure the node](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+[reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 
 ### Command line tools cannot connect to Gitaly
 
-If you are having trouble connecting to a Gitaly node with command line (CLI) tools, and certain actions result in a `14: Connect Failed` error message, it means that gRPC cannot reach your Gitaly node.
+If you are having trouble connecting to a Gitaly server with command line (CLI) tools,
+and certain actions result in a `14: Connect Failed` error message,
+it means that gRPC cannot reach your Gitaly server.
 
 Verify that you can reach Gitaly via TCP:
 
@@ -1070,18 +1074,22 @@ Verify that you can reach Gitaly via TCP:
 sudo gitlab-rake gitlab:tcp_check[GITALY_SERVER_IP,GITALY_LISTEN_PORT]
 ```
 
-If the TCP connection fails, check your network settings and your firewall rules. If the TCP connection succeeds, your networking and firewall rules are correct.
+If the TCP connection fails, check your network settings and your firewall rules.
+If the TCP connection succeeds, your networking and firewall rules are correct.
 
-If you use proxy servers in your command line environment, such as Bash, these can interfere with your gRPC traffic.
+If you use proxy servers in your command line environment, such as Bash, these
+can interfere with your gRPC traffic.
 
-If you use Bash or a compatible command line environment, run the following commands to determine whether you have proxy servers configured:
+If you use Bash or a compatible command line environment, run the following commands
+to determine whether you have proxy servers configured:
 
 ```shell
 echo $http_proxy
 echo $https_proxy
 ```
 
-If either of these variables have a value, your Gitaly CLI connections may be getting routed through a proxy which cannot connect to Gitaly.
+If either of these variables have a value, your Gitaly CLI connections may be
+getting routed through a proxy which cannot connect to Gitaly.
 
 To remove the proxy setting, run the following commands (depending on which variables had values):
 
@@ -1092,17 +1100,18 @@ unset https_proxy
 
 ### Gitaly not listening on new address after reconfiguring
 
-When updating the `gitaly['listen_addr']` or `gitaly['prometheus_listen_addr']` values, Gitaly may continue to listen on the old address after a `sudo gitlab-ctl reconfigure`.
+When updating the `gitaly['listen_addr']` or `gitaly['prometheus_listen_addr']`
+values, Gitaly may continue to listen on the old address after a `sudo gitlab-ctl reconfigure`.
 
 When this occurs, performing a `sudo gitlab-ctl restart` will resolve the issue. This will no longer be necessary after [this issue](https://gitlab.com/gitlab-org/gitaly/-/issues/2521) is resolved.
 
-### Permission denied errors appearing in Gitaly logs when accessing repositories from a standalone Gitaly node
+### Permission denied errors appearing in Gitaly logs when accessing repositories from a standalone Gitaly server
 
 If this error occurs even though file permissions are correct, it's likely that
-the Gitaly node is experiencing
+the Gitaly server is experiencing
 [clock drift](https://en.wikipedia.org/wiki/Clock_drift).
 
-Please ensure that the GitLab and Gitaly nodes are synchronized and use an NTP time
+Please ensure that the Gitaly clients and servers are synchronized and use an NTP time
 server to keep them synchronized if possible.
 
 ### Praefect

doc/administration/logs.md

@@ -352,7 +352,7 @@ only. For example:
 ## `audit_json.log`
 
 NOTE: **Note:**
-Most log entries only exist in [GitLab Starter](https://about.gitlab.com/pricing), however a few exist in GitLab Core.
+Most log entries only exist in [GitLab Starter](https://about.gitlab.com/pricing/), however a few exist in GitLab Core.
 
 This file lives in `/var/log/gitlab/gitlab-rails/audit_json.log` for
 Omnibus GitLab packages or in `/home/git/gitlab/log/audit_json.log` for

doc/administration/monitoring/prometheus/pgbouncer_exporter.md

@@ -10,7 +10,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 Available since [Omnibus GitLab 11.0](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/2493).
 For installations from source you'll have to install and configure it yourself.
 
-The [PgBouncer exporter](https://github.com/stanhu/pgbouncer_exporter) allows you to measure various PgBouncer metrics.
+The [PgBouncer exporter](https://github.com/prometheus-community/pgbouncer_exporter) allows you to measure various PgBouncer metrics.
 
 To enable the PgBouncer exporter:
 

doc/ci/cloud_deployment/index.md

@@ -35,12 +35,21 @@ Some credentials are required to be able to run `aws` commands:
    NOTE: **Note:**
    A new **Access key ID** and **Secret access key** pair will be generated. Please take a note of them right away.
 
-1. In your GitLab project, go to **Settings > CI / CD**. Set the Access key ID and Secret access key as [environment variables](../variables/README.md#gitlab-cicd-environment-variables), using the following variable names:
+1. In your GitLab project, go to **Settings > CI / CD**. Set the following as
+   [environment variables](../variables/README.md#gitlab-cicd-environment-variables)
+   (see table below):
+
+   - Access key ID.
+   - Secret access key.
+   - Region code. You can check the [list of AWS regional endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html#regional-endpoints).
+     You might want to check if the AWS service you intend to use is
+     [available in the chosen region](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/).
 
    | Env. variable name      | Value                  |
-   |:------------------------|:-------------------------|
+   |:------------------------|:-----------------------|
-   | `AWS_ACCESS_KEY_ID`     | Your "Access key ID"     |
+   | `AWS_ACCESS_KEY_ID`     | Your Access key ID     |
-   | `AWS_SECRET_ACCESS_KEY` | Your "Secret access key" |
+   | `AWS_SECRET_ACCESS_KEY` | Your Secret access key |
+   | `AWS_DEFAULT_REGION`    | Your region code       |
 
 1. You can now use `aws` commands in the `.gitlab-ci.yml` file of this project:
 

doc/ci/variables/README.md

@@ -669,7 +669,7 @@ Below you can find supported syntax reference:
    which means that it is defined and non-empty, you can simply use
    variable name as an expression, like `$STAGING`. If `$STAGING` variable
    is defined, and is non empty, expression will evaluate to truth.
-   `$STAGING` value needs to a string, with length higher than zero.
+   `$STAGING` value needs to be a string, with length higher than zero.
    Variable that contains only whitespace characters is not an empty variable.
 
 1. Pattern matching (introduced in GitLab 11.0)

doc/development/documentation/index.md

@@ -59,7 +59,7 @@ However, anyone can contribute [documentation improvements](improvement-workflow
 ## Markdown and styles
 
 [GitLab docs](https://gitlab.com/gitlab-org/gitlab-docs) uses [GitLab Kramdown](https://gitlab.com/gitlab-org/gitlab_kramdown)
-as its Markdown rendering engine. See the [GitLab Markdown Guide](https://about.gitlab.com/handbook/engineering/ux/technical-writing/markdown-guide/) for a complete Kramdown reference.
+as its Markdown rendering engine. See the [GitLab Markdown Guide](https://about.gitlab.com/handbook/markdown-guide/) for a complete Kramdown reference.
 
 Adhere to the [Documentation Style Guide](styleguide.md). If a style standard is missing, you are welcome to suggest one via a merge request.
 
@@ -512,7 +512,7 @@ This list does not limit what other linters you can add to your local documentat
 [markdownlint](https://github.com/DavidAnson/markdownlint) checks that Markdown
 syntax follows [certain rules](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#rules),
 and is used by the [`docs-lint` test](#testing) with a [configuration file](#markdownlint-configuration).
-Our [Documentation Style Guide](styleguide.md#markdown) and [Markdown Guide](https://about.gitlab.com/handbook/engineering/ux/technical-writing/markdown-guide/)
+Our [Documentation Style Guide](styleguide.md#markdown) and [Markdown Guide](https://about.gitlab.com/handbook/markdown-guide/)
 elaborate on which choices must be made when selecting Markdown syntax for GitLab
 documentation. This tool helps catch deviations from those guidelines.
 

doc/development/documentation/styleguide.md

@@ -1614,7 +1614,7 @@ Rendered example:
 - Wherever needed use this personal access token: `<your_access_token>`.
 - Always put the request first. `GET` is the default so you don't have to
   include it.
-- Use double quotes to the URL when it includes additional parameters.
+- Wrap the URL in double quotes (`"`).
 - Prefer to use examples using the personal access token and don't pass data of
   username and password.
 

doc/user/project/integrations/prometheus_units.md

@@ -19,7 +19,7 @@ Currently, your [internationalization and localization options](https://en.wikip
 
 For generic or default data, numbers are formatted according to the current locale in [engineering notation](https://en.wikipedia.org/wiki/Engineering_notation).
 
-While an [engineering notation exists for the web](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat), GitLab uses a version based off the [scientific notation](https://en.wikipedia.org/wiki/Scientific_notation). GitLab formatting acts in accordance with SI prefixes. For example, using GitLab notation, `1500.00` becomes `1.5k` instead of `1.5E3`. Keep this distinction in mind when using the engineering notation for your metrics.
+While an [engineering notation exists for the web](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat), GitLab uses a version based off the [scientific notation](https://en.wikipedia.org/wiki/Scientific_notation). GitLab formatting acts in accordance with SI prefixes. For example, using GitLab notation, `1500.00` becomes `1.5k` instead of `1.5E3`. Keep this distinction in mind when using the engineering notation for your metrics.
 
 Formats: `engineering`
 

doc/user/project/pages/getting_started/fork_sample_project.md

@@ -5,68 +5,52 @@ group: Release Management
 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
 ---
 
-# New Pages website from a forked sample
+# Create a Pages website from a forked sample
 
-To get started with GitLab Pages from a sample website, the easiest
+GitLab provides [sample projects for the most popular Static Site Generators](https://gitlab.com/pages).
-way to do it is by using one of the [bundled templates](pages_bundled_template.md).
+You can fork one of the sample projects and run the CI/CD pipeline to generate a Pages website.
-If you don't find one that suits your needs, you can opt by
-forking (copying) a [sample project from the most popular Static Site Generators](https://gitlab.com/pages).
 
-<table class="borderless-table center fixed-table middle width-80">
+Fork a sample project when you want to test GitLab Pages or start a new project that's already
-  <tr>
+configured to generate a Pages site.
-    <td style="width: 30%"><img src="../img/icons/fork.png" alt="Fork" class="image-noshadow half-width"></td>
-    <td style="width: 10%">
-      <strong>
-        <i class="fa fa-angle-double-right" aria-hidden="true"></i>
-      </strong>
-    </td>
-    <td style="width: 30%"><img src="../img/icons/terminal.png" alt="Deploy" class="image-noshadow half-width"></td>
-    <td style="width: 10%">
-      <strong>
-        <i class="fa fa-angle-double-right" aria-hidden="true"></i>
-      </strong>
-    </td>
-    <td style="width: 30%"><img src="../img/icons/click.png" alt="Visit" class="image-noshadow half-width"></td>
-  </tr>
-  <tr>
-    <td><em>Fork an example project</em></td>
-    <td></td>
-    <td><em>Deploy your website</em></td>
-    <td></td>
-    <td><em>Visit your website's URL</em></td>
-  </tr>
-</table>
 
-**<i class="fa fa-youtube-play youtube" aria-hidden="true"></i> Watch a [video tutorial](https://www.youtube.com/watch?v=TWqh9MtT4Bg) with all the steps below.**
+<i class="fa fa-youtube-play youtube" aria-hidden="true"></i> Watch a [video tutorial](https://www.youtube.com/watch?v=TWqh9MtT4Bg) of how this works.
 
-1. [Fork](../../../../gitlab-basics/fork-project.md) a sample project from the [GitLab Pages examples](https://gitlab.com/pages) group.
+To fork a sample project and create a Pages website:
-1. From the left sidebar, navigate to your project's **CI/CD > Pipelines**
-   and click **Run pipeline** to trigger GitLab CI/CD to build and deploy your
-   site to the server.
-1. Once the pipeline has finished successfully, find the link to visit your
-   website from your project's **Settings > Pages**. It can take approximately
-   30 minutes to be deployed.
 
-You can also take some **optional** further steps:
+1. View the sample projects by going to the [GitLab Pages examples](https://gitlab.com/pages) group.
+1. Click the name of the project you want to [fork](../../../../gitlab-basics/fork-project.md).
+1. In the top right, click the **Fork** button, and then choose a namespace to fork to.
+1. Go to your project's **CI/CD > Pipelines** and click **Run pipeline**.
+   GitLab CI/CD builds and deploys your site.
 
-- _Remove the fork relationship._ The fork relationship is necessary to contribute back to the project you originally forked from. If you don't have any intentions to do so, you can remove it. To do so, navigate to your project's **Settings**, expand **Advanced settings**, and scroll down to **Remove fork relationship**:
+When the pipeline is finished, go to **Settings > Pages** to find the link to your website from your project.
+It can take approximately 30 minutes to deploy.
 
-  ![Remove fork relationship](../img/remove_fork_relationship.png)
+For every change pushed to your repository, GitLab CI/CD runs a new pipeline
+that immediately publishes your changes to the Pages site.
 
-- _Make it a user or group website._ To turn a **project website** forked
+You can take some **optional** further steps:
-  from the Pages group into a **user/group** website, you'll need to:
-  - Rename it to `namespace.gitlab.io`: go to your project's
-    **Settings > General** and expand **Advanced**. Scroll down to
-    **Change path** and change the path to `namespace.gitlab.io`.
 
-    For example, consider the group `https://gitlab.com/gitlab-tests`:
+- _Remove the fork relationship._ If you want to contribute to the project you forked from,
-   `gitlab-tests` is the group's namespace, the repository path should be set
+  you can keep this relationship. Otherwise, go to your project's **Settings > General**,
-    to `gitlab-tests.gitlab.io` (yes, weird like that), and the
+  expand **Advanced settings**, and scroll down to **Remove fork relationship**:
-    resulting URL for your Pages website will be `https://gitlab-tests.gitlab.io`.
+
+  ![Remove fork relationship](../img/remove_fork_relationship_v13_1.png)
+
+- _Change the URL to match your namespace._ If your Pages site is hosted on GitLab.com,
+  you can rename it to `<namespace>.gitlab.io`, where `<namespace>` is your GitLab namespace
+  (the one you chose when you forked the project).
+
+  - Go to your project's **Settings > General** and expand **Advanced**. Scroll down to
+    **Change path** and change the path to `<namespace>.gitlab.io`.
+
+    For example, if your project's URL is `gitlab.com/gitlab-tests/jekyll`, your namespace is
+    `gitlab-tests`.
+
+    If you set the repository path to `gitlab-tests.gitlab.io`,
+    the resulting URL for your Pages website is `https://gitlab-tests.gitlab.io`.
 
     ![Change repo's path](../img/change_path_v12_10.png)
 
-  - Adjust your SSG's [base URL](../getting_started_part_one.md#urls-and-baseurls) from `"project-name"` to
+  - Now go to your SSG's config file and change the [base URL](../getting_started_part_one.md#urls-and-baseurls)
-    `""`. This setting will be at a different place for each SSG, as each of them
+    from `"project-name"` to `""`. The project name setting varies by SSG and may not be in the config file.
-    have their own structure and file tree. Most likely, it will be in the SSG's
-    config file.

lib/banzai/filter/ascii_doc_sanitization_filter.rb

@@ -18,6 +18,7 @@ module Banzai
 
       # Classes used by Asciidoctor to style components
       ADMONITION_CLASSES = %w(fa icon-note icon-tip icon-warning icon-caution icon-important).freeze
+      ALIGNMENT_BUILTINS_CLASSES = %w(text-center text-left text-right text-justify).freeze
       CALLOUT_CLASSES = ['conum'].freeze
       CHECKLIST_CLASSES = %w(fa fa-check-square-o fa-square-o).freeze
       LIST_CLASSES = %w(checklist none no-bullet unnumbered unstyled).freeze
@@ -28,7 +29,7 @@ module Banzai
 
       ELEMENT_CLASSES_WHITELIST = {
         span: %w(big small underline overline line-through).freeze,
-        div: ['admonitionblock'].freeze,
+        div: ALIGNMENT_BUILTINS_CLASSES + ['admonitionblock'].freeze,
         td: ['icon'].freeze,
         i: ADMONITION_CLASSES + CALLOUT_CLASSES + CHECKLIST_CLASSES,
         ul: LIST_CLASSES,

lib/gitlab/lfs_token.rb

@@ -14,7 +14,7 @@ module Gitlab
 
     include LfsTokenHelper
 
-    DEFAULT_EXPIRE_TIME = 1800
+    DEFAULT_EXPIRE_TIME = 7200 # Default value 2 hours
 
     attr_accessor :actor
 

locale/gitlab.pot

@@ -11616,6 +11616,9 @@ msgstr ""
 msgid "Import an exported GitLab project"
 msgstr ""
 
+msgid "Import failed due to a GitHub error: %{original}"
+msgstr ""
+
 msgid "Import from"
 msgstr ""
 

spec/lib/gitlab/lfs_token_spec.rb

@@ -3,6 +3,13 @@
 require 'spec_helper'
 
 describe Gitlab::LfsToken, :clean_gitlab_redis_shared_state do
+  let_it_be(:user)       { create(:user) }
+  let_it_be(:project)    { create(:project) }
+  let_it_be(:deploy_key) { create(:deploy_key) }
+
+  let(:actor)     { user }
+  let(:lfs_token) { described_class.new(actor) }
+
   describe '#token' do
     shared_examples 'a valid LFS token' do
       it 'returns a computed token' do
@@ -10,14 +17,11 @@ describe Gitlab::LfsToken, :clean_gitlab_redis_shared_state do
 
         expect(token).not_to be_nil
         expect(token).to be_a String
-        expect(described_class.new(actor).token_valid?(token)).to be_truthy
+        expect(described_class.new(actor).token_valid?(token)).to be true
       end
     end
 
     context 'when the actor is a user' do
-      let(:actor) { create(:user, username: 'test_user_lfs_1') }
-      let(:lfs_token) { described_class.new(actor) }
-
       it_behaves_like 'a valid LFS token'
 
       it 'returns the correct username' do
@@ -30,9 +34,7 @@ describe Gitlab::LfsToken, :clean_gitlab_redis_shared_state do
     end
 
     context 'when the actor is a key' do
-      let(:user) { create(:user, username: 'test_user_lfs_2') }
+      let_it_be(:actor) { create(:key, user: user) }
-      let(:actor) { create(:key, user: user) }
-      let(:lfs_token) { described_class.new(actor) }
 
       it_behaves_like 'a valid LFS token'
 
@@ -46,10 +48,8 @@ describe Gitlab::LfsToken, :clean_gitlab_redis_shared_state do
     end
 
     context 'when the actor is a deploy key' do
+      let(:actor) { deploy_key }
       let(:actor_id) { 1 }
-      let(:actor) { create(:deploy_key) }
-      let(:project) { create(:project) }
-      let(:lfs_token) { described_class.new(actor) }
 
       before do
         allow(actor).to receive(:id).and_return(actor_id)
@@ -74,45 +74,45 @@ describe Gitlab::LfsToken, :clean_gitlab_redis_shared_state do
   end
 
   describe '#token_valid?' do
-    let(:actor) { create(:user, username: 'test_user_lfs_1') }
-    let(:lfs_token) { described_class.new(actor) }
-
     context 'where the token is invalid' do
       context "because it's junk" do
         it 'returns false' do
-          expect(lfs_token.token_valid?('junk')).to be_falsey
+          expect(lfs_token.token_valid?('junk')).to be false
         end
       end
 
       context "because it's been fiddled with" do
         it 'returns false' do
           fiddled_token = lfs_token.token.tap { |token| token[0] = 'E' }
-          expect(lfs_token.token_valid?(fiddled_token)).to be_falsey
+
+          expect(lfs_token.token_valid?(fiddled_token)).to be false
         end
       end
 
-      context "because it was generated with a different secret" do
+      context 'because it was generated with a different secret' do
         it 'returns false' do
           different_actor = create(:user, username: 'test_user_lfs_2')
           different_secret_token = described_class.new(different_actor).token
-          expect(lfs_token.token_valid?(different_secret_token)).to be_falsey
+
+          expect(lfs_token.token_valid?(different_secret_token)).to be false
         end
       end
 
       context "because it's expired" do
         it 'returns false' do
           expired_token = lfs_token.token
-          # Needs to be at least 1860 seconds, because the default expiry is
+
-          # 1800 seconds with an additional 60 second leeway.
+          # Needs to be at least LfsToken::DEFAULT_EXPIRE_TIME + 60 seconds
-          Timecop.freeze(Time.now + 1865) do
+          # in order to check whether it is valid 1 minute after it has expired
-            expect(lfs_token.token_valid?(expired_token)).to be_falsey
+          Timecop.freeze(Time.now + described_class::DEFAULT_EXPIRE_TIME + 60) do
+            expect(lfs_token.token_valid?(expired_token)).to be false
           end
         end
       end
 
       context 'where the token is valid' do
         it 'returns true' do
-          expect(lfs_token.token_valid?(lfs_token.token)).to be_truthy
+          expect(lfs_token.token_valid?(lfs_token.token)).to be true
         end
       end
 
@@ -121,7 +121,7 @@ describe Gitlab::LfsToken, :clean_gitlab_redis_shared_state do
           let(:actor) { create(:user, :blocked) }
 
           it 'returns false' do
-            expect(lfs_token.token_valid?(lfs_token.token)).to be_falsey
+            expect(lfs_token.token_valid?(lfs_token.token)).to be false
           end
         end
 
@@ -129,7 +129,7 @@ describe Gitlab::LfsToken, :clean_gitlab_redis_shared_state do
           let(:actor) { create(:user, password_expires_at: 1.minute.ago) }
 
           it 'returns false' do
-            expect(lfs_token.token_valid?(lfs_token.token)).to be_falsey
+            expect(lfs_token.token_valid?(lfs_token.token)).to be false
           end
         end
       end
@@ -143,7 +143,7 @@ describe Gitlab::LfsToken, :clean_gitlab_redis_shared_state do
           let(:actor) { create(:user, :blocked) }
 
           it 'returns false' do
-            expect(lfs_token.token_valid?(lfs_token.token)).to be_falsey
+            expect(lfs_token.token_valid?(lfs_token.token)).to be false
           end
         end
 
@@ -151,7 +151,7 @@ describe Gitlab::LfsToken, :clean_gitlab_redis_shared_state do
           let(:actor) { create(:user, password_expires_at: 1.minute.ago) }
 
           it 'returns true' do
-            expect(lfs_token.token_valid?(lfs_token.token)).to be_truthy
+            expect(lfs_token.token_valid?(lfs_token.token)).to be true
           end
         end
       end
@@ -159,27 +159,21 @@ describe Gitlab::LfsToken, :clean_gitlab_redis_shared_state do
   end
 
   describe '#deploy_key_pushable?' do
-    let(:lfs_token) { described_class.new(actor) }
-
     context 'when actor is not a DeployKey' do
-      let(:actor) { create(:user) }
-      let(:project) { create(:project) }
-
       it 'returns false' do
-        expect(lfs_token.deploy_key_pushable?(project)).to be_falsey
+        expect(lfs_token.deploy_key_pushable?(project)).to be false
       end
     end
 
     context 'when actor is a DeployKey' do
-      let(:deploy_keys_project) { create(:deploy_keys_project, can_push: can_push) }
+      let(:deploy_keys_project) { create(:deploy_keys_project, project: project, can_push: can_push) }
-      let(:project) { deploy_keys_project.project }
       let(:actor) { deploy_keys_project.deploy_key }
 
       context 'but the DeployKey cannot push to the project' do
         let(:can_push) { false }
 
         it 'returns false' do
-          expect(lfs_token.deploy_key_pushable?(project)).to be_falsey
+          expect(lfs_token.deploy_key_pushable?(project)).to be false
         end
       end
 
@@ -187,27 +181,23 @@ describe Gitlab::LfsToken, :clean_gitlab_redis_shared_state do
         let(:can_push) { true }
 
         it 'returns true' do
-          expect(lfs_token.deploy_key_pushable?(project)).to be_truthy
+          expect(lfs_token.deploy_key_pushable?(project)).to be true
         end
       end
     end
   end
 
   describe '#type' do
-    let(:lfs_token) { described_class.new(actor) }
-
     context 'when actor is not a User' do
-      let(:actor) { create(:deploy_key) }
+      let(:actor) { deploy_key }
 
-      it 'returns false' do
+      it 'returns :lfs_deploy_token type' do
         expect(lfs_token.type).to eq(:lfs_deploy_token)
       end
     end
 
     context 'when actor is a User' do
-      let(:actor) { create(:user) }
+      it 'returns :lfs_token type' do
-
-      it 'returns false' do
         expect(lfs_token.type).to eq(:lfs_token)
       end
     end
@@ -215,8 +205,6 @@ describe Gitlab::LfsToken, :clean_gitlab_redis_shared_state do
 
   describe '#authentication_payload' do
     it 'returns a Hash designed for gitlab-shell' do
-      actor = create(:user)
-      lfs_token = described_class.new(actor)
       repo_http_path = 'http://localhost/user/repo.git'
       authentication_payload = lfs_token.authentication_payload(repo_http_path)
 

spec/models/concerns/cache_markdown_field_spec.rb

@@ -209,8 +209,8 @@ describe CacheMarkdownField, :clean_gitlab_redis_cache do
           thing.cached_markdown_version += 1
         end
 
-        it 'calls #refresh_markdown_cache' do
+        it 'calls #refresh_markdown_cache!' do
-          expect(thing).to receive(:refresh_markdown_cache)
+          expect(thing).to receive(:refresh_markdown_cache!)
 
           expect(thing.updated_cached_html_for(:description)).to eq(html)
         end
@@ -227,8 +227,8 @@ describe CacheMarkdownField, :clean_gitlab_redis_cache do
           thing.try(:save)
         end
 
-        it 'does not call #refresh_markdown_cache' do
+        it 'does not call #refresh_markdown_cache!' do
-          expect(thing).not_to receive(:refresh_markdown_cache)
+          expect(thing).not_to receive(:refresh_markdown_cache!)
 
           expect(thing.updated_cached_html_for(:description)).to eq(html)
         end

spec/services/import/github_service_spec.rb

@@ -0,0 +1,55 @@
+# frozen_string_literal: true
+
+require 'spec_helper'
+
+describe Import::GithubService do
+  let_it_be(:user) { create(:user) }
+  let_it_be(:token) { 'complex-token' }
+  let_it_be(:access_params) { { github_access_token: 'github-complex-token' } }
+  let_it_be(:client) { Gitlab::LegacyGithubImport::Client.new(token) }
+  let_it_be(:params) { { repo_id: 123, new_name: 'new_repo', target_namespace: 'root' } }
+
+  let(:subject) { described_class.new(client, user, params) }
+
+  before do
+    allow(subject).to receive(:authorized?).and_return(true)
+  end
+
+  context 'do not raise an exception on input error' do
+    let(:exception) { Octokit::ClientError.new(status: 404, body: 'Not Found') }
+
+    before do
+      expect(client).to receive(:repo).and_raise(exception)
+    end
+
+    it 'logs the original error' do
+      expect(Gitlab::Import::Logger).to receive(:error).with({
+        message: 'Import failed due to a GitHub error',
+        status: 404,
+        error: 'Not Found'
+      }).and_call_original
+
+      subject.execute(access_params, :github)
+    end
+
+    it 'returns an error' do
+      result = subject.execute(access_params, :github)
+
+      expect(result).to include(
+        message: 'Import failed due to a GitHub error: Not Found',
+        status: :error,
+        http_status: :unprocessable_entity
+      )
+    end
+  end
+
+  it 'raises an exception for unknown error causes' do
+    exception = StandardError.new('Not Implemented')
+
+    expect(client).to receive(:repo).and_raise(exception)
+
+    expect(Gitlab::Import::Logger).not_to receive(:error)
+
+    expect { subject.execute(access_params, :github) }.to raise_error(exception)
+  end
+end

spec/support/shared_examples/models/mentionable_shared_examples.rb

@@ -80,13 +80,11 @@ RSpec.shared_examples 'a mentionable' do
 
   context 'when there are cached markdown fields' do
     before do
-      if subject.is_a?(CacheMarkdownField)
+      skip unless subject.is_a?(CacheMarkdownField)
-        subject.refresh_markdown_cache
-      end
     end
 
     it 'sends in cached markdown fields when appropriate' do
-      if subject.is_a?(CacheMarkdownField) && subject.extractors[author].blank?
+      subject.extractors[author] = nil
       expect_next_instance_of(Gitlab::ReferenceExtractor) do |ext|
         attrs = subject.class.mentionable_attrs.collect(&:first) & subject.cached_markdown_fields.markdown_fields
         attrs.each do |field|
@@ -94,13 +92,11 @@ RSpec.shared_examples 'a mentionable' do
         end
       end
 
-        expect(subject).not_to receive(:refresh_markdown_cache)
       expect(subject).to receive(:cached_markdown_fields).at_least(:once).and_call_original
 
       subject.all_references(author)
     end
   end
-  end
 
   it 'creates cross-reference notes' do
     mentioned_objects = [mentioned_issue, mentioned_mr, mentioned_commit,
@@ -126,28 +122,42 @@ RSpec.shared_examples 'an editable mentionable' do
 
   context 'when there are cached markdown fields' do
     before do
-      if subject.is_a?(CacheMarkdownField)
+      skip unless subject.is_a?(CacheMarkdownField)
-        subject.refresh_markdown_cache
+
-      end
+      subject.save!
     end
 
     it 'refreshes markdown cache if necessary' do
-      subject.save!
-
       set_mentionable_text.call('This is a text')
 
-      if subject.is_a?(CacheMarkdownField) && subject.extractors[author].blank?
+      subject.extractors[author] = nil
       expect_next_instance_of(Gitlab::ReferenceExtractor) do |ext|
         subject.cached_markdown_fields.markdown_fields.each do |field|
           expect(ext).to receive(:analyze).with(subject.send(field), hash_including(rendered: anything))
         end
       end
 
-        expect(subject).to receive(:refresh_markdown_cache)
+      expect(subject).to receive(:refresh_markdown_cache).and_call_original
       expect(subject).to receive(:cached_markdown_fields).at_least(:once).and_call_original
 
       subject.all_references(author)
     end
+
+    context 'when the markdown cache is stale' do
+      before do
+        expect(subject).to receive(:latest_cached_markdown_version).at_least(:once) do
+          (Gitlab::MarkdownCache::CACHE_COMMONMARK_VERSION + 1) << 16
+        end
+      end
+
+      it 'persists the refreshed cache so that it does not have to be refreshed every time' do
+        expect(subject).to receive(:refresh_markdown_cache).once.and_call_original
+
+        subject.all_references(author)
+
+        subject.reload
+        subject.all_references(author)
+      end
     end
   end