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 2019-10-01 03:05:57 +00:00
parent b38cf7ccdf
commit ec60358d52
23 changed files with 238 additions and 131 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.eslintrc.yml
View File

@ -45,7 +45,6 @@ rules:
no-jquery/no-serialize: error
promise/always-return: off
promise/no-callback-in-promise: off
promise/no-nesting: off
overrides:
files:
- '**/spec/**/*'

3
app/assets/javascripts/ide/.eslintrc.yml Normal file
View File

@ -0,0 +1,3 @@
rules:
# https://gitlab.com/gitlab-org/gitlab/issues/33024
promise/no-nesting: off

8
app/models/lfs_object.rb
View File

@ -24,7 +24,13 @@ class LfsObject < ApplicationRecord
end
def project_allowed_access?(project)
projects.exists?(project.lfs_storage_project.id)
if project.fork_network_member
lfs_objects_projects
.where("EXISTS(?)", project.fork_network.fork_network_members.select(1).where("fork_network_members.project_id = lfs_objects_projects.project_id"))
.exists?
else
lfs_objects_projects.where(project_id: project.id).exists?
end
end
def local_store?

4
app/views/admin/labels/destroy.js.haml
View File

@ -1,2 +1,2 @@
- if @labels.size == 0
$('.labels').load(document.URL + ' .card.bg-light').hide().fadeIn(1000)
- if @labels.size.zero?
$('.labels').load(document.URL + ' .nothing-here-block').hide().fadeIn(1000)

4
app/views/admin/labels/index.html.haml
View File

@ -14,6 +14,4 @@
= paginate @labels, theme: 'gitlab'
- else
.card.bg-light
.nothing-here-block= _('There are no labels yet')
.nothing-here-block= _('There are no labels yet')

4
doc/administration/index.md
View File

@ -193,7 +193,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
- [Debugging tips](troubleshooting/debug.md): Tips to debug problems when things go wrong
- [Log system](logs.md): Where to look for logs.
- [Sidekiq Troubleshooting](troubleshooting/sidekiq.md): Debug when Sidekiq appears hung and is not processing jobs.
- [Troubleshooting ElasticSearch](troubleshooting/elasticsearch.md)
- [Troubleshooting Elasticsearch](troubleshooting/elasticsearch.md)
### Support Team Docs
@ -213,7 +213,7 @@ who are aware of the risks.
- [Useful Linux commands](troubleshooting/linux_cheat_sheet.md)
- [Troubleshooting Kubernetes](troubleshooting/kubernetes_cheat_sheet.md)
- [Guide to test environments](troubleshooting/test_environments.md) (for Support Engineers)
- [GitLab rails console commands](troubleshooting/gitlab_rails_cheat_sheet.md) (for Support Engineers)
- [GitLab Rails console commands](troubleshooting/gitlab_rails_cheat_sheet.md) (for Support Engineers)
- Useful links:
- [GitLab Developer Docs](../development/README.md)
- [Repairing and recovering broken Git repositories](https://git.seveas.net/repairing-and-recovering-broken-git-repositories.html)

2
doc/administration/job_artifacts.md
View File

@ -118,7 +118,7 @@ The connection settings match those provided by [Fog](https://github.com/fog), a
| `enable_signature_v4_streaming` | Set to true to enable HTTP chunked transfers with [AWS v4 signatures](https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-streaming.html). Oracle Cloud S3 needs this to be false | true |
| `region` | AWS region | us-east-1 |
| `host` | S3 compatible host for when not using AWS, e.g. `localhost` or `storage.example.com` | s3.amazonaws.com |
| `endpoint` | Can be used when configuring an S3 compatible service such as [Minio](https://www.minio.io), by entering a URL such as `http://127.0.0.1:9000` | (optional) |
| `endpoint` | Can be used when configuring an S3 compatible service such as [MinIO](https://www.minio.io), by entering a URL such as `http://127.0.0.1:9000` | (optional) |
| `path_style` | Set to true to use `host/bucket_name/object` style paths instead of `bucket_name.host/object`. Leave as false for AWS S3 | false |
| `use_iam_profile` | Set to true to use IAM profile instead of access keys | false

12
doc/administration/pages/index.md
View File

@ -115,7 +115,7 @@ since that is needed in all configurations.
URL scheme: `http://page.example.io`
This is the minimum setup that you can use Pages with. It is the base for all
other setups as described below. Nginx will proxy all requests to the daemon.
other setups as described below. NGINX will proxy all requests to the daemon.
The Pages daemon doesn't listen to the outside world.
1. Set the external URL for GitLab Pages in `/etc/gitlab/gitlab.rb`:
@ -139,7 +139,7 @@ Watch the [video tutorial][video-admin] for this configuration.
URL scheme: `https://page.example.io`
Nginx will proxy all requests to the daemon. Pages daemon doesn't listen to the
NGINX will proxy all requests to the daemon. Pages daemon doesn't listen to the
outside world.
1. Place the certificate and key inside `/etc/gitlab/ssl`
@ -196,7 +196,7 @@ you have IPv6 as well as IPv4 addresses, you can use them both.
URL scheme: `http://page.example.io` and `http://domain.com`
In that case, the Pages daemon is running, Nginx still proxies requests to
In that case, the Pages daemon is running, NGINX still proxies requests to
the daemon but the daemon is also able to receive requests from the outside
world. Custom domains are supported, but no TLS.
@ -227,7 +227,7 @@ world. Custom domains are supported, but no TLS.
URL scheme: `https://page.example.io` and `https://domain.com`
In that case, the Pages daemon is running, Nginx still proxies requests to
In that case, the Pages daemon is running, NGINX still proxies requests to
the daemon but the daemon is also able to receive requests from the outside
world. Custom domains and TLS are supported.
@ -319,7 +319,7 @@ pages:
gitlab_pages['http_proxy'] = 'http://example:8080'
```
1. [Reconfigure Gitlab][reconfigure] for the changes to take effect.
1. [Reconfigure GitLab][reconfigure] for the changes to take effect.
## Activate verbose logging for daemon
@ -426,7 +426,7 @@ Pages are part of the [regular backup][backup] so there is nothing to configure.
## Security
You should strongly consider running GitLab pages under a different hostname
You should strongly consider running GitLab Pages under a different hostname
than GitLab to prevent XSS attacks.
[backup]: ../../raketasks/backup_restore.md

22
doc/administration/pages/source.md
View File

@ -93,7 +93,7 @@ since that is needed in all configurations.
URL scheme: `http://page.example.io`
This is the minimum setup that you can use Pages with. It is the base for all
other setups as described below. Nginx will proxy all requests to the daemon.
other setups as described below. NGINX will proxy all requests to the daemon.
The Pages daemon doesn't listen to the outside world.
1. Install the Pages daemon:
@ -136,7 +136,7 @@ The Pages daemon doesn't listen to the outside world.
gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090"
```
1. Copy the `gitlab-pages` Nginx configuration file:
1. Copy the `gitlab-pages` NGINX configuration file:
```bash
sudo cp lib/support/nginx/gitlab-pages /etc/nginx/sites-available/gitlab-pages.conf
@ -155,7 +155,7 @@ The Pages daemon doesn't listen to the outside world.
URL scheme: `https://page.example.io`
Nginx will proxy all requests to the daemon. Pages daemon doesn't listen to the
NGINX will proxy all requests to the daemon. Pages daemon doesn't listen to the
outside world.
1. Install the Pages daemon:
@ -193,7 +193,7 @@ outside world.
gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -root-cert /path/to/example.io.crt -root-key /path/to/example.io.key
```
1. Copy the `gitlab-pages-ssl` Nginx configuration file:
1. Copy the `gitlab-pages-ssl` NGINX configuration file:
```bash
sudo cp lib/support/nginx/gitlab-pages-ssl /etc/nginx/sites-available/gitlab-pages-ssl.conf
@ -219,7 +219,7 @@ that without TLS certificates.
URL scheme: `http://page.example.io` and `http://domain.com`
In that case, the pages daemon is running, Nginx still proxies requests to
In that case, the pages daemon is running, NGINX still proxies requests to
the daemon but the daemon is also able to receive requests from the outside
world. Custom domains are supported, but no TLS.
@ -261,7 +261,7 @@ world. Custom domains are supported, but no TLS.
gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -listen-http 192.0.2.2:80"
```
1. Copy the `gitlab-pages-ssl` Nginx configuration file:
1. Copy the `gitlab-pages-ssl` NGINX configuration file:
```bash
sudo cp lib/support/nginx/gitlab-pages /etc/nginx/sites-available/gitlab-pages.conf
@ -284,7 +284,7 @@ world. Custom domains are supported, but no TLS.
URL scheme: `https://page.example.io` and `https://domain.com`
In that case, the pages daemon is running, Nginx still proxies requests to
In that case, the pages daemon is running, NGINX still proxies requests to
the daemon but the daemon is also able to receive requests from the outside
world. Custom domains and TLS are supported.
@ -330,7 +330,7 @@ world. Custom domains and TLS are supported.
gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -listen-http 192.0.2.2:80 -listen-https 192.0.2.2:443 -root-cert /path/to/example.io.crt -root-key /path/to/example.io.key
```
1. Copy the `gitlab-pages-ssl` Nginx configuration file:
1. Copy the `gitlab-pages-ssl` NGINX configuration file:
```bash
sudo cp lib/support/nginx/gitlab-pages-ssl /etc/nginx/sites-available/gitlab-pages-ssl.conf
@ -351,7 +351,7 @@ The following information applies only for installations from source.
Be extra careful when setting up the domain name in the NGINX config. You must
not remove the backslashes.
If your GitLab pages domain is `example.io`, replace:
If your GitLab Pages domain is `example.io`, replace:
```bash
server_name ~^.*\.YOUR_GITLAB_PAGES\.DOMAIN$;
@ -401,7 +401,7 @@ Pages access control is disabled by default. To enable it:
1. Create a new [system OAuth application](../../integration/oauth_provider.md#adding-an-application-through-the-profile).
This should be called `GitLab Pages` and have a `Redirect URL` of
`https://projects.example.io/auth`. It does not need to be a "trusted"
application, but it does need the "api" scope.
application, but it does need the `api` scope.
1. Start the Pages daemon with the following additional arguments:
```shell
@ -443,7 +443,7 @@ Pages are part of the [regular backup][backup] so there is nothing to configure.
## Security
You should strongly consider running GitLab pages under a different hostname
You should strongly consider running GitLab Pages under a different hostname
than GitLab to prevent XSS attacks.
[backup]: ../../raketasks/backup_restore.md

2
doc/administration/repository_storage_types.md
View File

@ -10,7 +10,7 @@ that can be:
- Mounted to the local disk
- Exposed as an NFS shared volume
- Accessed via [gitaly] on its own machine.
- Accessed via [Gitaly] on its own machine.
In GitLab, this is configured in `/etc/gitlab/gitlab.rb` by the `git_data_dirs({})`
configuration hash. The storage layouts discussed here will apply to any shard

2
doc/administration/smime_signing_email.md
View File

@ -1,6 +1,6 @@
# Signing outgoing email with S/MIME
Notification emails sent by Gitlab can be signed with S/MIME for improved
Notification emails sent by GitLab can be signed with S/MIME for improved
security.
> **Note:**

14
doc/administration/troubleshooting/debug.md
View File

@ -89,10 +89,10 @@ in Omnibus, run as root:
Many of the tips to diagnose issues below apply to many different situations. We'll use one
concrete example to illustrate what you can do to learn what is going wrong.
### 502 Gateway Timeout after unicorn spins at 100% CPU
### 502 Gateway Timeout after Unicorn spins at 100% CPU
This error occurs when the Web server times out (default: 60 s) after not
hearing back from the unicorn worker. If the CPU spins to 100% while this in
hearing back from the Unicorn worker. If the CPU spins to 100% while this in
progress, there may be something taking longer than it should.
To fix this issue, we first need to figure out what is happening. The
@ -100,7 +100,7 @@ following tips are only recommended if you do NOT mind users being affected by
downtime. Otherwise skip to the next section.
1. Load the problematic URL
1. Run `sudo gdb -p <PID>` to attach to the unicorn process.
1. Run `sudo gdb -p <PID>` to attach to the Unicorn process.
1. In the gdb window, type:
```
@ -135,7 +135,7 @@ downtime. Otherwise skip to the next section.
exit
```
Note that if the unicorn process terminates before you are able to run these
Note that if the Unicorn process terminates before you are able to run these
commands, gdb will report an error. To buy more time, you can always raise the
Unicorn timeout. For omnibus users, you can edit `/etc/gitlab/gitlab.rb` and
increase it from 60 seconds to 300:
@ -152,7 +152,7 @@ For source installations, edit `config/unicorn.rb`.
#### Troubleshooting without affecting other users
The previous section attached to a running unicorn process, and this may have
The previous section attached to a running Unicorn process, and this may have
undesirable effects for users trying to access GitLab during this time. If you
are concerned about affecting others during a production system, you can run a
separate Rails process to debug the issue:
@ -183,7 +183,7 @@ separate Rails process to debug the issue:
### GitLab: API is not accessible
This often occurs when gitlab-shell attempts to request authorization via the
This often occurs when GitLab Shell attempts to request authorization via the
internal API (e.g., `http://localhost:8080/api/v4/internal/allowed`), and
something in the check fails. There are many reasons why this may happen:
@ -192,7 +192,7 @@ something in the check fails. There are many reasons why this may happen:
1. Error accessing the repository (e.g., stale NFS handles)
To diagnose this problem, try to reproduce the problem and then see if there
is a unicorn worker that is spinning via `top`. Try to use the `gdb`
is a Unicorn worker that is spinning via `top`. Try to use the `gdb`
techniques above. In addition, using `strace` may help isolate issues:
```shell

126
doc/administration/troubleshooting/elasticsearch.md
View File

@ -1,6 +1,6 @@
# Troubleshooting ElasticSearch
# Troubleshooting Elasticsearch
Troubleshooting ElasticSearch requires:
Troubleshooting Elasticsearch requires:
- Knowledge of common terms.
- Establishing within which category the problem fits.
@ -30,7 +30,7 @@ The type of problem will determine what steps to take. The possible troubleshoot
### Search Results workflow
The following workflow is for ElasticSearch search results issues:
The following workflow is for Elasticsearch search results issues:
```mermaid
graph TD;
@ -42,11 +42,11 @@ graph TD;
B5 --> |Yes| B6
B5 --> |No| B7
B7 --> B8
B{Is GitLab using<br>ElasticSearch for<br>searching?}
B{Is GitLab using<br>Elasticsearch for<br>searching?}
B1[Check Admin Area > Integrations<br>to ensure the settings are correct]
B2[Perform a search via<br>the rails console]
B3[If all settings are correct<br>and it still doesn't show ElasticSearch<br>doing the searches, escalate<br>to GitLab support.]
B4[Perform<br>the same search via the<br>ElasticSearch API]
B3[If all settings are correct<br>and it still doesn't show Elasticsearch<br>doing the searches, escalate<br>to GitLab support.]
B4[Perform<br>the same search via the<br>Elasticsearch API]
B5{Are the results<br>the same?}
B6[This means it is working as intended.<br>Speak with GitLab support<br>to confirm if the issue lies with<br>the filters.]
B7[Check the index status of the project<br>containing the missing search<br>results.]
@ -55,7 +55,7 @@ graph TD;
### Indexing workflow
The following workflow is for ElasticSearch indexing issues:
The following workflow is for Elasticsearch indexing issues:
```mermaid
graph TD;
@ -67,7 +67,7 @@ graph TD;
C --> |No| C6
C6 --> |No| C10
C7 --> |GitLab| C8
C7 --> |ElasticSearch| C9
C7 --> |Elasticsearch| C9
C6 --> |Yes| C7
C10 --> |No| C12
C10 --> |Yes| C11
@ -76,27 +76,27 @@ graph TD;
C14 --> |Yes| C15
C14 --> |No| C16
C{Is the problem with<br>creating an empty<br>index?}
C1{Does the gitlab-production<br>index exist on the<br>ElasticSearch instance?}
C2(Try to manually<br>delete the index on the<br>ElasticSearch instance and<br>retry creating an empty index.)
C3{Can indices be made<br>manually on the ElasticSearch<br>instance?}
C1{Does the gitlab-production<br>index exist on the<br>Elasticsearch instance?}
C2(Try to manually<br>delete the index on the<br>Elasticsearch instance and<br>retry creating an empty index.)
C3{Can indices be made<br>manually on the Elasticsearch<br>instance?}
C4(Retry the creation of an empty index)
C5(It is best to speak with an<br>ElasticSearch admin concerning the<br>instance's inability to create indices.)
C5(It is best to speak with an<br>Elasticsearch admin concerning the<br>instance's inability to create indices.)
C6{Is the indexer presenting<br>errors during indexing?}
C7{Is the error a GitLab<br>error or an ElasticSearch<br>error?}
C7{Is the error a GitLab<br>error or an Elasticsearch<br>error?}
C8[Escalate to<br>GitLab support]
C9[You will want<br>to speak with an<br>ElasticSearch admin.]
C9[You will want<br>to speak with an<br>Elasticsearch admin.]
C10{Does the index status<br>show 100%?}
C11[Escalate to<br>GitLab support]
C12{Does re-indexing the project<br> present any GitLab errors?}
C13[Rectify the GitLab errors and<br>restart troubleshooting, or<br>escalate to GitLab support.]
C14{Does re-indexing the project<br>present errors on the <br>ElasticSearch instance?}
C15[It would be best<br>to speak with an<br>ElasticSearch admin.]
C14{Does re-indexing the project<br>present errors on the <br>Elasticsearch instance?}
C15[It would be best<br>to speak with an<br>Elasticsearch admin.]
C16[This is likely a bug/issue<br>in GitLab and will require<br>deeper investigation. Escalate<br>to GitLab support.]
```
### Integration workflow
The following workflow is for ElasticSearch integration issues:
The following workflow is for Elasticsearch integration issues:
```mermaid
graph TD;
@ -107,7 +107,7 @@ graph TD;
D4 --> |No| D5
D4 --> |Yes| D6
D{Is the error concerning<br>the beta indexer?}
D1[It would be best<br>to speak with an<br>ElasticSearch admin.]
D1[It would be best<br>to speak with an<br>Elasticsearch admin.]
D2{Is the ICU development<br>package installed?}
D3>This package is required.<br>Install the package<br>and retry.]
D4{Is the error stemming<br>from the indexer?}
@ -117,7 +117,7 @@ graph TD;
### Performance workflow
The following workflow is for ElasticSearch performance issues:
The following workflow is for Elasticsearch performance issues:
```mermaid
graph TD;
@ -128,19 +128,19 @@ graph TD;
F4 --> F5
F5 --> |No| F6
F5 --> |Yes| F7
F{Is the ElasticSearch instance<br>running on the same server<br>as the GitLab instance?}
F1(This is not advised and will cause issues.<br>We recommend moving the ElasticSearch<br>instance to a different server.)
F2{Does the ElasticSearch<br>server have at least 8<br>GB of RAM and 2 CPU<br>cores?}
F3(According to ElasticSearch, a non-prod<br>server needs these as a base requirement.<br>Production often requires more. We recommend<br>you increase the server specifications.)
F{Is the Elasticsearch instance<br>running on the same server<br>as the GitLab instance?}
F1(This is not advised and will cause issues.<br>We recommend moving the Elasticsearch<br>instance to a different server.)
F2{Does the Elasticsearch<br>server have at least 8<br>GB of RAM and 2 CPU<br>cores?}
F3(According to Elasticsearch, a non-prod<br>server needs these as a base requirement.<br>Production often requires more. We recommend<br>you increase the server specifications.)
F4(Obtain the <br>cluster health information)
F5(Does it show the<br>status as green?)
F6(We recommend you speak with<br>an ElasticSearch admin<br>about implementing sharding.)
F6(We recommend you speak with<br>an Elasticsearch admin<br>about implementing sharding.)
F7(Escalate to<br>GitLab support.)
```
## Troubleshooting walkthrough
Most ElasticSearch troubleshooting can be broken down into 4 categories:
Most Elasticsearch troubleshooting can be broken down into 4 categories:
- [Troubleshooting search results](#troubleshooting-search-results)
- [Troubleshooting indexing](#troubleshooting-indexing)
@ -150,19 +150,19 @@ Most ElasticSearch troubleshooting can be broken down into 4 categories:
Generally speaking, if it does not fall into those four categories, it is either:
- Something GitLab support needs to look into.
- Not a true ElasticSearch issue.
- Not a true Elasticsearch issue.
Exercise caution. Issues that appear to be ElasticSearch problems can be OS-level issues.
Exercise caution. Issues that appear to be Elasticsearch problems can be OS-level issues.
### Troubleshooting search results
Troubleshooting search result issues is rather straight forward on ElasticSearch.
Troubleshooting search result issues is rather straight forward on Elasticsearch.
The first step is to confirm GitLab is using ElasticSearch for the search function.
The first step is to confirm GitLab is using Elasticsearch for the search function.
To do this:
1. Confirm the integration is enabled in **Admin Area > Settings > Integrations**.
1. Confirm searches utilize ElasticSearch by accessing the rails console
1. Confirm searches utilize Elasticsearch by accessing the rails console
(`sudo gitlab-rails console`) and running the following commands:
```rails
@ -173,21 +173,21 @@ To do this:
The ouput from the last command is the key here. If it shows:
- `ActiveRecord::Relation`, **it is not** using ElasticSearch.
- `Kaminari::PaginatableArray`, **it is** using ElasticSearch.
- `ActiveRecord::Relation`, **it is not** using Elasticsearch.
- `Kaminari::PaginatableArray`, **it is** using Elasticsearch.
| Not using ElasticSearch | Using ElasticSearch |
| Not using Elasticsearch | Using Elasticsearch |
|--------------------------|------------------------------|
| `ActiveRecord::Relation` | `Kaminari::PaginatableArray` |
If all the settings look correct and it is still not using ElasticSearch for the search function, it is best to escalate to GitLab support. This could be a bug/issue.
If all the settings look correct and it is still not using Elasticsearch for the search function, it is best to escalate to GitLab support. This could be a bug/issue.
Moving past that, it is best to attempt the same search using the [ElasticSearch Search API](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-search.html) and compare the results from what you see in GitLab.
Moving past that, it is best to attempt the same search using the [Elasticsearch Search API](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-search.html) and compare the results from what you see in GitLab.
If the results:
- Sync up, then there is not a technical "issue" per se. Instead, it might be a problem
with the ElasticSearch filters we are using. This can be complicated, so it is best to
with the Elasticsearch filters we are using. This can be complicated, so it is best to
escalate to GitLab support to check these and guide you on the potential on whether or
not a feature request is needed.
- Do not match up, this indicates a problem with the documents generated from the
@ -197,20 +197,20 @@ If the results:
### Troubleshooting indexing
Troubleshooting indexing issues can be tricky. It can pretty quickly go to either GitLab
support or your ElasticSearch admin.
support or your Elasticsearch admin.
The best place to start is to determine if the issue is with creating an empty index.
If it is, check on the ElasticSearch side to determine if the `gitlab-production` (the
name for the GitLab index) exists. If it exists, manually delete it on the ElasticSearch
If it is, check on the Elasticsearch side to determine if the `gitlab-production` (the
name for the GitLab index) exists. If it exists, manually delete it on the Elasticsearch
side and attempt to recreate it from the
[`create_empty_index`](../../integration/elasticsearch.md#gitlab-elasticsearch-rake-tasks)
rake task.
If you still encounter issues, try creating an index manually on the ElasticSearch
If you still encounter issues, try creating an index manually on the Elasticsearch
instance. The details of the index aren't important here, as we want to test if indices
can be made. If the indices:
- Cannot be made, speak with your ElasticSearch admin.
- Cannot be made, speak with your Elasticsearch admin.
- Can be made, Escalate this to GitLab support.
If the issue is not with creating an empty index, the next step is to check for errors
@ -218,7 +218,7 @@ during the indexing of projects. If errors do occur, they will either stem from
- On the GitLab side. You need to rectify those. If they are not
something you are familiar with, contact GitLab support for guidance.
- Within the ElasticSearch instance itself. See if the error is [documented and has a fix](../../integration/elasticsearch.md#troubleshooting). If not, speak with your ElasticSearch admin.
- Within the Elasticsearch instance itself. See if the error is [documented and has a fix](../../integration/elasticsearch.md#troubleshooting). If not, speak with your Elasticsearch admin.
If the indexing process does not present errors, you will want to check the status of the indexed projects. You can do this via the following rake tasks:
@ -235,8 +235,8 @@ If:
If reindexing the project shows:
- Errors on the GitLab side, escalate those to GitLab support.
- ElasticSearch errors or doesn't present any errors at all, reach out to your
ElasticSearch admin to check the instance.
- Elasticsearch errors or doesn't present any errors at all, reach out to your
Elasticsearch admin to check the instance.
### Troubleshooting integration
@ -246,7 +246,7 @@ much to "integrate" here.
If the issue is:
- Not concerning the beta indexer, it is almost always an
ElasticSearch-side issue. This means you should reach out to your ElasticSearch admin
Elasticsearch-side issue. This means you should reach out to your Elasticsearch admin
regarding the error(s) you are seeing. If you are unsure here, it never hurts to reach
out to GitLab support.
- With the beta indexer, check if the ICU development package is installed.
@ -260,48 +260,48 @@ Beyond that, you will want to review the error. If it is:
### Troubleshooting performance
Troubleshooting performance can be difficult on ElasticSearch. There is a ton of tuning
Troubleshooting performance can be difficult on Elasticsearch. There is a ton of tuning
that *can* be done, but the majority of this falls on shoulders of a skilled
ElasticSearch administrator.
Elasticsearch administrator.
Generally speaking, ensure:
- The ElasticSearch server **is not** running on the same node as GitLab.
- The ElasticSearch server have enough RAM and CPU cores.
- The Elasticsearch server **is not** running on the same node as GitLab.
- The Elasticsearch server have enough RAM and CPU cores.
- That sharding **is** being used.
Going into some more detail here, if ElasticSearch is running on the same server as GitLab, resource contention is **very** likely to occur. Ideally, ElasticSearch, which requires ample resources, should be running on its own server (maybe coupled with logstash and kibana).
Going into some more detail here, if Elasticsearch is running on the same server as GitLab, resource contention is **very** likely to occur. Ideally, Elasticsearch, which requires ample resources, should be running on its own server (maybe coupled with logstash and kibana).
When it comes to ElasticSearch, RAM is the key resource. ElasticSearch themselves recommend:
When it comes to Elasticsearch, RAM is the key resource. Elasticsearch themselves recommend:
- **At least** 8 GB of RAM for a non-production instance.
- **At least** 16 GB of RAM for a production instance.
- Ideally, 64 GB of RAM.
For CPU, ElasticSearch recommends at least 2 CPU cores, but ElasticSearch states common
For CPU, Elasticsearch recommends at least 2 CPU cores, but Elasticsearch states common
setups use up to 8 cores. For more details on server specs, check out
[ElasticSearch's hardware guide](https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html).
[Elasticsearch's hardware guide](https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html).
Beyond the obvious, sharding comes into play. Sharding is a core part of ElasticSearch.
Beyond the obvious, sharding comes into play. Sharding is a core part of Elasticsearch.
It allows for horizontal scaling of indices, which is helpful when you are dealing with
a large amount of data.
With the way GitLab does indexing, there is a **huge** amount of documents being
indexed. By utilizing sharding, you can speed up ElasticSearch's ability to locate
indexed. By utilizing sharding, you can speed up Elasticsearch's ability to locate
data, since each shard is a Lucene index.
If you are not using sharding, you are likely to hit issues when you start using
ElasticSearch in a production environment.
Elasticsearch in a production environment.
Keep in mind that an index with only one shard has **no scale factor** and will
likely encounter issues when called upon with some frequency.
If you need to know how many shards, read
[ElasticSearch's documentation on capacity planning](https://www.elastic.co/guide/en/elasticsearch/guide/2.x/capacity-planning.html),
[Elasticsearch's documentation on capacity planning](https://www.elastic.co/guide/en/elasticsearch/guide/2.x/capacity-planning.html),
as the answer is not straight forward.
The easiest way to determine if sharding is in use is to check the output of the
[ElasticSearch Health API](https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-health.html):
[Elasticsearch Health API](https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-health.html):
- Red means the cluster is down.
- Yellow means it is up with no sharding/replication.
@ -311,11 +311,11 @@ For production use, it should always be green.
Beyond these steps, you get into some of the more complicated things to check,
such as merges and caching. These can get complicated and it takes some time to
learn them, so it is best to escalate/pair with an ElasticSearch expert if you need to
learn them, so it is best to escalate/pair with an Elasticsearch expert if you need to
dig further into these.
Feel free to reach out to GitLab support, but this is likely to be something a skilled
ElasticSearch admin has more experience with.
Elasticsearch admin has more experience with.
## Common issues
@ -324,12 +324,12 @@ feel free to update that page with issues you encounter and solutions.
## Replication
Setting up ElasticSearch isn't too bad, but it can be a bit finnicky and time consuming.
Setting up Elasticsearch isn't too bad, but it can be a bit finnicky and time consuming.
The eastiest method is to spin up a docker container with the required version and
bind ports 9200/9300 so it can be used.
The following is an example of running a docker container of ElasticSearch v7.2.0:
The following is an example of running a docker container of Elasticsearch v7.2.0:
```bash
docker pull docker.elastic.co/elasticsearch/elasticsearch:7.2.0
@ -341,5 +341,5 @@ From here, you can:
- Grab the IP of the docker container (use `docker inspect <container_id>`)
- Use `<IP.add.re.ss:9200>` to communicate with it.
This is a quick method to test out ElasticSearch, but by no means is this a
This is a quick method to test out Elasticsearch, but by no means is this a
production solution.

8
doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
View File

@ -4,7 +4,7 @@ type: reference
# GitLab Rails Console Cheat Sheet
This is the GitLab Support Team's collection of information regarding the GitLab rails
This is the GitLab Support Team's collection of information regarding the GitLab Rails
console, for use while troubleshooting. It is listed here for transparency,
and it may be useful for users with experience with these tools. If you are currently
having an issue with GitLab, it is highly recommended that you check your
@ -822,7 +822,7 @@ License.current # check to make sure it applied
From [Zendesk ticket #91083](https://gitlab.zendesk.com/agent/tickets/91083) (internal)
### Poll unicorn requests by seconds
### Poll Unicorn requests by seconds
```ruby
require 'rubygems'
@ -898,13 +898,13 @@ See <https://github.com/mperham/sidekiq/wiki/Signals#ttin>.
## Redis
### Connect to redis (omnibus)
### Connect to Redis (omnibus)
```sh
/opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket
```
### Connect to redis (HA)
### Connect to Redis (HA)
```sh
/opt/gitlab/embedded/bin/redis-cli -h <host ip> -a <password>

16
doc/administration/troubleshooting/kubernetes_cheat_sheet.md
View File

@ -15,7 +15,7 @@ If you are on a [paid tier](https://about.gitlab.com/pricing/) and are not sure
to use these commands, it is best to [contact Support](https://about.gitlab.com/support/)
and they will assist you with any issues you are having.
## Generic kubernetes commands
## Generic Kubernetes commands
- How to authorize to your GCP project (can be especially useful if you have projects
under different GCP accounts):
@ -33,7 +33,7 @@ and they will assist you with any issues you are having.
kubectl proxy
```
- How to ssh to a Kubernetes node and enter the container as root
- How to SSH to a Kubernetes node and enter the container as root
<https://github.com/kubernetes/kubernetes/issues/30656>:
- For GCP, you may find the node name and run `gcloud compute ssh node-name`.
@ -72,12 +72,12 @@ and they will assist you with any issues you are having.
This is the principle of Kubernetes, read [Twelve-factor app](https://12factor.net/)
for details.
## GitLab-specific kubernetes information
## GitLab-specific Kubernetes information
- Minimal config that can be used to test a Kubernetes helm chart can be found
- Minimal config that can be used to test a Kubernetes Helm chart can be found
[here](https://gitlab.com/gitlab-org/charts/gitlab/issues/620).
- Tailing logs of a separate pod. An example for a unicorn pod:
- Tailing logs of a separate pod. An example for a Unicorn pod:
```bash
kubectl logs gitlab-unicorn-7656fdd6bf-jqzfs -c unicorn
@ -101,7 +101,7 @@ and they will assist you with any issues you are having.
```
- Check all events in the `gitlab` namespace (the namespace name can be different if you
specified a different one when deploying the helm chart):
specified a different one when deploying the Helm chart):
```bash
kubectl get events -w --namespace=gitlab
@ -140,8 +140,8 @@ and they will assist you with any issues you are having.
- Check the output of `kubectl get events -w --all-namespaces`.
- Check the logs of pods within `gitlab-managed-apps` namespace.
- On the side of GitLab check sidekiq log and kubernetes log. When GitLab is installed
via Helm Chart, `kubernetes.log` can be found inside the sidekiq pod.
- On the side of GitLab check Sidekiq log and Kubernetes log. When GitLab is installed
via Helm Chart, `kubernetes.log` can be found inside the Sidekiq pod.
- How to get your initial admin password <https://docs.gitlab.com/charts/installation/deployment.html#initial-login>:

2
doc/administration/troubleshooting/sidekiq.md
View File

@ -238,7 +238,7 @@ workers.each do |process_id, thread_id, work|
end
```
### Remove sidekiq jobs for given parameters (destructive)
### Remove Sidekiq jobs for given parameters (destructive)
```ruby
# for jobs like this:

6
doc/administration/troubleshooting/test_environments.md
View File

@ -49,7 +49,7 @@ gitlab/gitlab-ee:11.5.3-ee.0
#### SAML for Authentication
We can use the [test-saml-idp Docker image](https://hub.docker.com/r/jamedjo/test-saml-idp)
We can use the [`test-saml-idp` Docker image](https://hub.docker.com/r/jamedjo/test-saml-idp)
to do the work for us:
```sh
@ -91,7 +91,7 @@ gitlab_rails['omniauth_providers'] = [
See [the GDK SAML documentation](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/saml.md).
### ElasticSearch
### Elasticsearch
```sh
docker run -d --name elasticsearch \
@ -101,7 +101,7 @@ docker.elastic.co/elasticsearch/elasticsearch:5.5.1
```
Then confirm it works in the browser at `curl http://<IP_ADDRESS>:9200/_cat/health`.
ElasticSearch's default username is `elastic` and password is `changeme`.
Elasticsearch's default username is `elastic` and password is `changeme`.
### PlantUML

4
doc/user/admin_area/settings/visibility_and_access_controls.md
View File

@ -105,7 +105,7 @@ With GitLab's access restrictions, you can select with which protocols users can
GitLab.
Disabling an access protocol does not block access to the server itself via those ports. The ports
used for the protocol, SSH or HTTP, will still be accessible. The GitLab restrictions apply at the
used for the protocol, SSH or HTTP(S), will still be accessible. The GitLab restrictions apply at the
application level.
To specify the enabled Git access protocols:
@ -150,7 +150,7 @@ For more details, see [SSH key restrictions](../../../security/ssh_keys_restrict
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3586) in GitLab 10.3.
This option is enabled by default. By disabling it, both pull and push mirroring will no longer
This option is enabled by default. By disabling it, both [pull and push mirroring](../../../workflow/repository_mirroring.md) will no longer
work in every repository and can only be re-enabled by an admin on a per-project basis.
![Mirror settings](img/mirror_settings.png)

14
doc/user/gitlab_com/index.md
View File

@ -355,38 +355,38 @@ publicly available at [chef cookbooks](https://gitlab.com/gitlab-cookbooks).
We use Elasticsearch, logstash, and Kibana for part of our monitoring solution:
- [gitlab-cookbooks / gitlab-elk · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-elk)
- [gitlab-cookbooks / gitlab_elasticsearch · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab_elasticsearch)
- [`gitlab-cookbooks` / `gitlab-elk` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-elk)
- [`gitlab-cookbooks` / `gitlab_elasticsearch` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab_elasticsearch)
### Prometheus
Prometheus complete our monitoring stack:
- [gitlab-cookbooks / gitlab-prometheus · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-prometheus)
- [`gitlab-cookbooks` / `gitlab-prometheus` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-prometheus)
### Grafana
For the visualization of monitoring data:
- [gitlab-cookbooks / gitlab-grafana · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-grafana)
- [`gitlab-cookbooks` / `gitlab-grafana` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-grafana)
### Sentry
Open source error tracking:
- [gitlab-cookbooks / gitlab-sentry · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-sentry)
- [`gitlab-cookbooks` / `gitlab-sentry` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-sentry)
### Consul
Service discovery:
- [gitlab-cookbooks / gitlab_consul · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab_consul)
- [`gitlab-cookbooks` / `gitlab_consul` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab_consul)
### Haproxy
High Performance TCP/HTTP Load Balancer:
- [gitlab-cookbooks / gitlab-haproxy · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-haproxy)
- [`gitlab-cookbooks` / `gitlab-haproxy` · GitLab](https://gitlab.com/gitlab-cookbooks/gitlab-haproxy)
[autoscale mode]: https://docs.gitlab.com/runner/configuration/autoscale.html "How Autoscale works"
[runners-post]: https://about.gitlab.com/2016/04/05/shared-runners/ "Shared Runners on GitLab.com"

3
doc/user/group/index.md
View File

@ -186,8 +186,7 @@ By default, [Developers and Maintainers](../permissions.md#group-members-permiss
To change this setting for a specific group:
1. Go to the group's page.
1. Go to **Settings > General**.
1. Go to the group's **Settings > General** page.
1. Expand the **Permissions, LFS, 2FA** section.
1. Select the desired option in the **Allowed to create projects** dropdown list.
1. Click **Save changes**.

3
spec/javascripts/create_cluster/.eslintrc.yml Normal file
View File

@ -0,0 +1,3 @@
rules:
# https://gitlab.com/gitlab-org/gitlab/issues/33025
promise/no-nesting: off

40
spec/models/lfs_object_spec.rb
View File

@ -31,6 +31,46 @@ describe LfsObject do
end
end
describe '#project_allowed_access?' do
set(:lfs_object) { create(:lfs_objects_project).lfs_object }
set(:project) { create(:project) }
it 'returns true when project is linked' do
create(:lfs_objects_project, lfs_object: lfs_object, project: project)
expect(lfs_object.project_allowed_access?(project)).to eq(true)
end
it 'returns false when project is not linked' do
expect(lfs_object.project_allowed_access?(project)).to eq(false)
end
context 'when project is a member of a fork network' do
set(:fork_network) { create(:fork_network) }
set(:fork_network_root_project) { fork_network.root_project }
set(:fork_network_membership) { create(:fork_network_member, project: project, fork_network: fork_network) }
it 'returns true for all members when forked project is linked' do
create(:lfs_objects_project, lfs_object: lfs_object, project: project)
expect(lfs_object.project_allowed_access?(project)).to eq(true)
expect(lfs_object.project_allowed_access?(fork_network_root_project)).to eq(true)
end
it 'returns true for all members when root of network is linked' do
create(:lfs_objects_project, lfs_object: lfs_object, project: fork_network_root_project)
expect(lfs_object.project_allowed_access?(project)).to eq(true)
expect(lfs_object.project_allowed_access?(fork_network_root_project)).to eq(true)
end
it 'returns false when no member of fork network is linked' do
expect(lfs_object.project_allowed_access?(project)).to eq(false)
expect(lfs_object.project_allowed_access?(fork_network_root_project)).to eq(false)
end
end
end
describe '#schedule_background_upload' do
before do
stub_lfs_setting(enabled: true)

69
spec/support/shared_examples/controllers/repository_lfs_file_load_examples.rb
View File

@ -25,13 +25,17 @@ shared_examples 'a controller that can serve LFS files' do |options = {}|
context 'when lfs is enabled' do
before do
allow_any_instance_of(Project).to receive(:lfs_enabled?).and_return(true)
allow_any_instance_of(LfsObjectUploader).to receive(:exists?).and_return(true)
allow(controller).to receive(:send_file) { controller.head :ok }
end
context 'when project has access' do
def link_project(project)
project.lfs_objects << lfs_object
end
context 'when the project is linked to the LfsObject' do
before do
project.lfs_objects << lfs_object
allow_any_instance_of(LfsObjectUploader).to receive(:exists?).and_return(true)
allow(controller).to receive(:send_file) { controller.head :ok }
link_project(project)
end
it 'serves the file' do
@ -76,13 +80,68 @@ shared_examples 'a controller that can serve LFS files' do |options = {}|
end
end
context 'when project does not have access' do
context 'when project is not linked to the LfsObject' do
it 'does not serve the file' do
subject
expect(response).to have_gitlab_http_status(404)
end
end
context 'when the project is part of a fork network' do
shared_examples 'a controller that correctly serves lfs files within a fork network' do
it do
expect(fork_network_member).not_to eq(fork_network.root_project)
end
it 'does not serve the file if no members are linked to the LfsObject' do
subject
expect(response).to have_gitlab_http_status(404)
end
it 'serves the file when the fork network root is linked to the LfsObject' do
link_project(fork_network.root_project)
subject
expect(response).to have_gitlab_http_status(200)
end
it 'serves the file when the fork network member is linked to the LfsObject' do
link_project(fork_network_member)
subject
expect(response).to have_gitlab_http_status(200)
end
end
context 'when the project is the root of the fork network' do
let!(:fork_network) { create(:fork_network, root_project: project) }
let!(:fork_network_member) { create(:fork_network_member, fork_network: fork_network).project }
before do
project.reload
end
it_behaves_like 'a controller that correctly serves lfs files within a fork network'
end
context 'when the project is a downstream member of the fork network' do
let!(:fork_network) { create(:fork_network) }
let!(:fork_network_member) do
create(:fork_network_member, project: project, fork_network: fork_network)
project
end
before do
project.reload
end
it_behaves_like 'a controller that correctly serves lfs files within a fork network'
end
end
end
context 'when lfs is not enabled' do