root
/
gitlab-ce
mirror of https://gitlab.com/free-releases/gitlab-ce.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2020-05-29 03:08:11 +00:00
parent d123b8e0d6
commit c70ed55242
26 changed files with 384 additions and 256 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
app/assets/stylesheets/framework/typography.scss
View File

@ -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;
}
}
/**

2
app/models/concerns/cache_markdown_field.rb
View File

@ -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

29
app/services/import/github_service.rb
View File

@ -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
.new(repo, project_name, target_namespace, current_user, access_params, type: provider)
.execute(extra_project_attrs)
project = create_project(access_params, provider)
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

5
changelogs/unreleased/218745-single-issue-api-performance-regression-degraded-by-8000ms-after-u.yml Normal file
View File

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

5
changelogs/unreleased/asciidoc-alignment-roles.yml Normal file
View File

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

5
changelogs/unreleased/fj-bump-lfs-token-default-expiration-time.yml Normal file
View File

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

13
doc/.vale/gitlab/CurlStringsQuoted.yml Normal file
View File

@ -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?://.*'

229
doc/administration/gitaly/index.md
View File

@ -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
and *Gitaly client* is a GitLab Rails app node that runs all other processes
except Gitaly.
On this page:
- **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. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
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) 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 server, edit `/etc/gitlab/gitlab.rb`:
1. On the Gitaly servers, 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
server.
1. On the client server, edit `/home/git/gitlab/config/gitlab.yml`:
1. Copy `/home/git/gitlab/.gitlab_shell_secret` from the Gitaly client to the same path on the Gitaly
servers (and any other Gitaly clients).
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
the network listener and configure the token.
Next, on the Gitaly servers, you need to configure storage paths and enable
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
their local Gitaly service to the new Gitaly server you just configured. This
As the final step, you need to update Gitaly clients to switch from using
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.
If you have multiple Gitaly nodes, copy your server hook(s) to all nodes.
either per repository or globally, you must move these to the Gitaly servers.
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
nodes (including the Gitaly node using the certificate) and on all client nodes
The certificate corresponding to each Gitaly server will need to be installed
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. On the client node(s), copy the cert into the `/etc/gitlab/trusted-certs`:
```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:
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. On the Gitaly servers, 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
calling into itself:
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 or other Gitaly servers:
```shell
sudo cp /etc/gitlab/ssl/cert.pem /etc/gitlab/trusted-certs/
```
```shell
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)
on Gitaly server node(s).
and [reconfiguring GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
**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)
on client node(s).
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:
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
1. On the Gitaly servers, create or edit `/etc/default/gitlab` and add:
```shell
export SSL_CERT_DIR=/etc/gitlab/ssl
```
1. Save the file.
1. Create the `/etc/gitlab/ssl` directory and copy your key and certificate there:
1. On the Gitaly servers, 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
when calling into itself:
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.
```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)
on Gitaly server node(s).
and [restarting GitLab](../restart_gitlab.md#installations-from-source).
### 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
flight, and the same for SSHUploadPack. If another request comes in for
Gitaly server can have at most 20 simultaneous `PostUploadPack` calls in
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
app nodes.
You will need to sync your `gitlab-secrets.json` file with your Gitaly clients (GitLab
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,
update the secrets file on the Gitaly node to match the others, then
[reconfigure the node](../restart_gitlab.md#omnibus-gitlab-reconfigure).
on the Gitaly server matches the one on Gitaly client. If it doesn't match,
update the secrets file on the Gitaly server to match the Gitaly client, then
[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

2
doc/administration/logs.md
View File

@ -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

2
doc/administration/monitoring/prometheus/pgbouncer_exporter.md
View File

@ -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:

19
doc/ci/cloud_deployment/index.md
View File

@ -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):
| Env. variable name | Value |
|:------------------------|:-------------------------|
| `AWS_ACCESS_KEY_ID` | Your "Access key ID" |
| `AWS_SECRET_ACCESS_KEY` | Your "Secret access key" |
- 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_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:

2
doc/ci/variables/README.md
View File

@ -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)

4
doc/development/documentation/index.md
View File

@ -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.

2
doc/development/documentation/styleguide.md
View File

@ -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.

2
doc/user/project/integrations/prometheus_units.md
View File

@ -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`

90
doc/user/project/pages/getting_started/fork_sample_project.md
View File

@ -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
way to do it is by using one of the [bundled templates](pages_bundled_template.md).
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).
GitLab provides [sample projects for the most popular Static Site Generators](https://gitlab.com/pages).
You can fork one of the sample projects and run the CI/CD pipeline to generate a Pages website.
<table class="borderless-table center fixed-table middle width-80">
<tr>
<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>
Fork a sample project when you want to test GitLab Pages or start a new project that's already
configured to generate a Pages site.
**<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.
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.
To fork a sample project and create a Pages website:
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
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`.
You can take some **optional** further steps:
For example, consider the group `https://gitlab.com/gitlab-tests`:
`gitlab-tests` is the group's namespace, the repository path should be set
to `gitlab-tests.gitlab.io` (yes, weird like that), and the
resulting URL for your Pages website will be `https://gitlab-tests.gitlab.io`.
- _Remove the fork relationship._ If you want to contribute to the project you forked from,
you can keep this relationship. Otherwise, go to your project's **Settings > General**,
expand **Advanced settings**, and scroll down to **Remove fork relationship**:
![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
`""`. This setting will be at a different place for each SSG, as each of them
have their own structure and file tree. Most likely, it will be in the SSG's
config file.
- Now go to your SSG's config file and change the [base URL](../getting_started_part_one.md#urls-and-baseurls)
from `"project-name"` to `""`. The project name setting varies by SSG and may not be in the config file.

BIN
doc/user/project/pages/img/change_path_v12_10.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 29 KiB

After

Width:  |  Height:  |  Size: 60 KiB

BIN
doc/user/project/pages/img/remove_fork_relationship.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 13 KiB

BIN
doc/user/project/pages/img/remove_fork_relationship_v13_1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 33 KiB

3
lib/banzai/filter/ascii_doc_sanitization_filter.rb
View File

@ -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,

2
lib/gitlab/lfs_token.rb
View File

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

3
locale/gitlab.pot
View File

@ -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 ""

78
spec/lib/gitlab/lfs_token_spec.rb
View File

@ -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(:actor) { create(:key, user: user) }
let(:lfs_token) { described_class.new(actor) }
let_it_be(:actor) { create(:key, user: user) }
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.
Timecop.freeze(Time.now + 1865) do
expect(lfs_token.token_valid?(expired_token)).to be_falsey
# Needs to be at least LfsToken::DEFAULT_EXPIRE_TIME + 60 seconds
# in order to check whether it is valid 1 minute after it has expired
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(:project) { deploy_keys_project.project }
let(:deploy_keys_project) { create(:deploy_keys_project, project: project, can_push: can_push) }
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 false' do
it 'returns :lfs_token type' 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)

8
spec/models/concerns/cache_markdown_field_spec.rb
View File

@ -209,8 +209,8 @@ describe CacheMarkdownField, :clean_gitlab_redis_cache do
thing.cached_markdown_version += 1
end
it 'calls #refresh_markdown_cache' do
expect(thing).to receive(:refresh_markdown_cache)
it 'calls #refresh_markdown_cache!' do
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
expect(thing).not_to receive(:refresh_markdown_cache)
it 'does not call #refresh_markdown_cache!' do
expect(thing).not_to receive(:refresh_markdown_cache!)
expect(thing.updated_cached_html_for(:description)).to eq(html)
end

55
spec/services/import/github_service_spec.rb Normal file
View File

@ -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

62
spec/support/shared_examples/models/mentionable_shared_examples.rb
View File

@ -80,25 +80,21 @@ RSpec.shared_examples 'a mentionable' do
context 'when there are cached markdown fields' do
before do
if subject.is_a?(CacheMarkdownField)
subject.refresh_markdown_cache
end
skip unless subject.is_a?(CacheMarkdownField)
end
it 'sends in cached markdown fields when appropriate' do
if subject.is_a?(CacheMarkdownField) && subject.extractors[author].blank?
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|
expect(ext).to receive(:analyze).with(subject.send(field), hash_including(rendered: anything))
end
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|
expect(ext).to receive(:analyze).with(subject.send(field), hash_including(rendered: anything))
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
expect(subject).to receive(:cached_markdown_fields).at_least(:once).and_call_original
subject.all_references(author)
end
end
@ -126,26 +122,40 @@ RSpec.shared_examples 'an editable mentionable' do
context 'when there are cached markdown fields' do
before do
if subject.is_a?(CacheMarkdownField)
subject.refresh_markdown_cache
end
skip unless subject.is_a?(CacheMarkdownField)
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?
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
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(:cached_markdown_fields).at_least(:once).and_call_original
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