Commit 59131f57 authored by GitLab Bot's avatar GitLab Bot
Browse files

Add latest changes from gitlab-org/gitlab@master

parent cd9c44586025
......@@ -18,7 +18,6 @@ export function startPollingDetails({ commit }, endpoint) {
data: { endpoint },
successCallback: ({ data }) => {
if (!data) {
detailPoll.restart();
return;
}
......@@ -43,7 +42,6 @@ export function startPollingStacktrace({ commit }, endpoint) {
data: { endpoint },
successCallback: ({ data }) => {
if (!data) {
stackTracePoll.restart();
return;
}
commit(types.SET_STACKTRACE_DATA, data.error);
......
......@@ -6,7 +6,7 @@
Mattermost
.col-sm-10
.form-check.js-toggle-container
.js-toggle-button.form-check-input= f.check_box(:create_chat_team, { checked: true }, true, false)
.js-toggle-button.form-check-input= f.check_box(:create_chat_team, { checked: false }, true, false)
= f.label :create_chat_team, class: 'form-check-label' do
= _('Create a Mattermost team for this group')
%br
......
---
title: Default the `creation of a Mattermost team` checkbox to false
merge_request: 23329
author: briankabiro
type: changed
---
title: Make rake -T output more consistent
merge_request: 23550
author:
type: other
---
title: Ensure that error tracking frontend only polls when required
merge_request: 23305
author:
type: fixed
......@@ -105,7 +105,7 @@ bundle exec rake file_hooks:validate RAILS_ENV=production
Example of output:
```
```plaintext
Validating file hooks from /plugins directory
* /home/git/gitlab/plugins/save_to_file.clj succeed (zero exit code)
* /home/git/gitlab/plugins/save_to_file.rb failure (non-zero exit code)
......
......@@ -45,7 +45,7 @@ query.
## Can I `git push` to a **secondary** node?
Yes! Pushing directly to a **secondary** node (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/blog/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
Yes! Pushing directly to a **secondary** node (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/releases/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
## How long does it take to have a commit replicated to a **secondary** node?
......
......@@ -63,7 +63,7 @@ Keep in mind that:
- Get user data for logins (API).
- Replicate repositories, LFS Objects, and Attachments (HTTPS + JWT).
- Since GitLab Premium 10.0, the **primary** node no longer talks to **secondary** nodes to notify for changes (API).
- Pushing directly to a **secondary** node (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/blog/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
- Pushing directly to a **secondary** node (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/releases/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
- There are [limitations](#current-limitations) in the current implementation.
### Architecture
......
......@@ -2,8 +2,8 @@
The following security review of the Geo feature set focuses on security aspects of
the feature as they apply to customers running their own GitLab instances. The review
questions are based in part on the [OWASP Application Security Verification Standard Project](https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project)
from [owasp.org](https://www.owasp.org/index.php/Main_Page).
questions are based in part on the [OWASP Application Security Verification Standard Project](https://owasp.org/www-project-application-security-verification-standard/)
from [owasp.org](https://www.owasp.org/).
## Business Model
......
......@@ -4,7 +4,7 @@
After you set up the [database replication and configure the Geo nodes][req], use your closest GitLab node as you would a normal standalone GitLab instance.
Pushing directly to a **secondary** node (for both HTTP, SSH including Git LFS) was [introduced](https://about.gitlab.com/blog/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
Pushing directly to a **secondary** node (for both HTTP, SSH including Git LFS) was [introduced](https://about.gitlab.com/releases/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
Example of the output you will see when pushing to a **secondary** node:
......
......@@ -98,7 +98,7 @@ The Pages daemon doesn't listen to the outside world.
1. Install the Pages daemon:
```
```bash
cd /home/git
sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git
cd gitlab-pages
......@@ -160,7 +160,7 @@ outside world.
1. Install the Pages daemon:
```
```bash
cd /home/git
sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git
cd gitlab-pages
......@@ -225,7 +225,7 @@ world. Custom domains are supported, but no TLS.
1. Install the Pages daemon:
```
```bash
cd /home/git
sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git
cd gitlab-pages
......@@ -290,7 +290,7 @@ world. Custom domains and TLS are supported.
1. Install the Pages daemon:
```
```bash
cd /home/git
sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git
cd gitlab-pages
......@@ -353,20 +353,20 @@ not remove the backslashes.
If your GitLab Pages domain is `example.io`, replace:
```bash
```nginx
server_name ~^.*\.YOUR_GITLAB_PAGES\.DOMAIN$;
```
with:
```
```nginx
server_name ~^.*\.example\.io$;
```
If you are using a subdomain, make sure to escape all dots (`.`) except from
the first one with a backslash (\). For example `pages.example.io` would be:
```
```nginx
server_name ~^.*\.pages\.example\.io$;
```
......
......@@ -33,7 +33,7 @@ integrity check described previously.
**Omnibus Installation**
```
```bash
sudo gitlab-rake gitlab:git:fsck
```
......@@ -58,7 +58,7 @@ Currently, integrity checks are supported for the following types of file:
**Omnibus Installation**
```
```bash
sudo gitlab-rake gitlab:artifacts:check
sudo gitlab-rake gitlab:lfs:check
sudo gitlab-rake gitlab:uploads:check
......@@ -90,7 +90,7 @@ sudo gitlab-rake gitlab:uploads:check BATCH=100 ID_FROM=50 ID_TO=250
Example output:
```
```bash
$ sudo gitlab-rake gitlab:uploads:check
Checking integrity of Uploads
- 1..1350: Failures: 0
......@@ -107,7 +107,7 @@ Done!
Example verbose output:
```
```bash
$ sudo gitlab-rake gitlab:uploads:check VERBOSE=1
Checking integrity of Uploads
- 1..1350: Failures: 0
......
......@@ -11,7 +11,7 @@ This is equivalent of running `git repack -d` on a _bare_ repository.
**Omnibus Installation**
```
```bash
sudo gitlab-rake geo:git:housekeeping:incremental_repack
```
......@@ -29,7 +29,7 @@ when this is enabled in GitLab.
**Omnibus Installation**
```
```bash
sudo gitlab-rake geo:git:housekeeping:full_repack
```
......@@ -46,7 +46,7 @@ a reachability bitmap index when this is enabled in GitLab.
**Omnibus Installation**
```
```bash
sudo gitlab-rake geo:git:housekeeping:gc
```
......@@ -63,7 +63,7 @@ can remove them using the rake task `geo:run_orphaned_project_registry_cleaner`:
**Omnibus Installation**
```
```bash
sudo gitlab-rake geo:run_orphaned_project_registry_cleaner
```
......
......@@ -9,7 +9,7 @@ using the command below.
**Omnibus Installation**
```
```bash
sudo gitlab-rake gitlab:ldap:check
```
......@@ -41,7 +41,7 @@ instead.
**Omnibus Installation**
```
```bash
sudo gitlab-rake gitlab:ldap:group_sync
```
......@@ -101,7 +101,7 @@ sudo gitlab-rake gitlab:ldap:rename_provider[ldapmain,ldapmycompany]
Example output:
```
```plaintext
100 users with provider 'ldapmain' will be updated to 'ldapmycompany'.
If the new provider is incorrect, users will be unable to sign in.
Do you want to continue (yes/no)? yes
......@@ -128,7 +128,7 @@ bundle exec rake gitlab:ldap:rename_provider RAILS_ENV=production
**Example output:**
```
```plaintext
What is the old provider? Ex. 'ldapmain': ldapmain
What is the new provider? Ex. 'ldapcustom': ldapmycompany
```
......
......@@ -6,19 +6,19 @@ This command gathers information about your GitLab installation and the System i
**Omnibus Installation**
```
```bash
sudo gitlab-rake gitlab:env:info
```
**Source Installation**
```
```bash
bundle exec rake gitlab:env:info RAILS_ENV=production
```
Example output:
```
```plaintext
System information
System: Debian 7.8
Current User: git
......@@ -66,13 +66,13 @@ You may also have a look at our Troubleshooting Guides:
**Omnibus Installation**
```
```bash
sudo gitlab-rake gitlab:check
```
**Source Installation**
```
```bash
bundle exec rake gitlab:check RAILS_ENV=production
```
......@@ -80,7 +80,7 @@ NOTE: Use `SANITIZE=true` for `gitlab:check` if you want to omit project names f
Example output:
```
```plaintext
Checking Environment ...
Git configured for git user? ... yes
......@@ -129,18 +129,18 @@ In some case it is necessary to rebuild the `authorized_keys` file.
**Omnibus Installation**
```
```bash
sudo gitlab-rake gitlab:shell:setup
```
**Source Installation**
```
```bash
cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:shell:setup RAILS_ENV=production
```
```
```plaintext
This will rebuild an authorized_keys file.
You will lose any data stored in authorized_keys file.
Do you want to continue (yes/no)? yes
......@@ -153,13 +153,13 @@ clear Redis' cache.
**Omnibus Installation**
```
```bash
sudo gitlab-rake cache:clear
```
**Source Installation**
```
```bash
cd /home/git/gitlab
sudo -u git -H bundle exec rake cache:clear RAILS_ENV=production
```
......@@ -174,7 +174,7 @@ Omnibus packages.
**Source Installation**
```
```bash
cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:assets:compile RAILS_ENV=production
```
......@@ -194,13 +194,13 @@ in the GitLab Performance Monitoring database.
**Omnibus Installation**
```
```bash
sudo gitlab-rake gitlab:track_deployment
```
**Source Installation**
```
```bash
cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:track_deployment RAILS_ENV=production
```
......@@ -213,13 +213,13 @@ is included to help you with this:
**Omnibus Installation**
```
```bash
sudo gitlab-rake gitlab:tcp_check[example.com,80]
```
**Source Installation**
```
```bash
cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:tcp_check[example.com,80] RAILS_ENV=production
```
......@@ -279,6 +279,6 @@ This could be as a result of [updating existing metrics](../../development/prome
To re-import the metrics you can run:
```sh
```bash
sudo gitlab-rake metrics:setup_common_metrics
```
......@@ -659,8 +659,6 @@ procfile exec` to replicate the environment where your application will run.
#### Workers
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/30628) in GitLab 12.6, `.gitlab/auto-deploy-values.yaml` will be used by default for Helm upgrades.
Some web applications need to run extra deployments for "worker processes". For
example, it is common in a Rails application to have a separate worker process
to run background tasks like sending emails.
......@@ -683,17 +681,8 @@ need to:
ensure it's passed into your deployments.
Once you have configured your worker to respond to health checks, run a Sidekiq
worker for your Rails application. For:
- GitLab 12.6 and later, either:
- Add a file named `.gitlab/auto-deploy-values.yaml` to your repository. It will
be automatically used if found.
- Add a file with a different name or path to the repository, and override the value of the
`HELM_UPGRADE_VALUES_FILE` variable with the path and name.
- GitLab 12.5 and earlier, run the worker with the `--values` parameter that specifies
a file in the repository.
In any case, the file must contain the following:
worker for your Rails application. You can enable workers by setting the
following in the [`.gitlab/auto-deploy-values.yaml` file](#customize-values-for-helm-chart):
```yml
workers:
......@@ -927,8 +916,21 @@ repo or by specifying a project variable:
- **Project variable** - Create a [project variable](../../ci/variables/README.md#gitlab-cicd-environment-variables)
`AUTO_DEVOPS_CHART` with the URL of a custom chart to use or create two project variables `AUTO_DEVOPS_CHART_REPOSITORY` with the URL of a custom chart repository and `AUTO_DEVOPS_CHART` with the path to the chart.
You can also make use of the `HELM_UPGRADE_EXTRA_ARGS` environment variable to override the default values in the `values.yaml` file in the [default Helm chart](https://gitlab.com/gitlab-org/charts/auto-deploy-app).
To apply your own `values.yaml` file to all Helm upgrade commands in Auto Deploy set `HELM_UPGRADE_EXTRA_ARGS` to `--values my-values.yaml`.
### Customize values for Helm Chart
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/30628) in GitLab 12.6, `.gitlab/auto-deploy-values.yaml` will be used by default for Helm upgrades.
You can override the default values in the `values.yaml` file in the [default Helm chart](https://gitlab.com/gitlab-org/charts/auto-deploy-app).
This can be achieved by either:
- Adding a file named `.gitlab/auto-deploy-values.yaml` to your repository. It will
be automatically used if found.
- Adding a file with a different name or path to the repository, and set the
`HELM_UPGRADE_VALUES_FILE` [environment variable](#environment-variables) with the path and name.
NOTE: **Note:**
For GitLab 12.5 and earlier, the `HELM_UPGRADE_EXTRA_ARGS` environment variable can be used to override the default chart values.
To do so, set `HELM_UPGRADE_EXTRA_ARGS` to `--values my-values.yaml`.
### Custom Helm chart per environment
......
......@@ -78,7 +78,7 @@ service: gitlab-example
provider:
name: aws
runtime: nodejs10.x
functions:
hello:
handler: src/handler.hello
......@@ -222,7 +222,7 @@ From there, you can reference them in your functions as well.
Remember to add `A_VARIABLE` to your GitLab CI variables under **Settings > CI/CD > Variables**, and it will get picked up and deployed with your function.
NOTE: **Note:**
Anyone with access to the AWS environemnt may be able to see the values of those
Anyone with access to the AWS environment may be able to see the values of those
variables persisted in the lambda definition.
### Setting up CORS
......
......@@ -12,9 +12,9 @@ The [Prometheus service](../prometheus.md) must be enabled.
| Name | Query |
| ---- | ----- |
| Throughput (req/sec) | sum(aws_elb_request_count_sum{%{environment_filter}}) / 60 |
| Latency (ms) | avg(aws_elb_latency_average{%{environment_filter}}) * 1000 |
| HTTP Error Rate (%) | sum(aws_elb_httpcode_backend_5_xx_sum{%{environment_filter}}) / sum(aws_elb_request_count_sum{%{environment_filter}}) |
| Throughput (req/sec) | `sum(aws_elb_request_count_sum{%{environment_filter}}) / 60` |
| Latency (ms) | `avg(aws_elb_latency_average{%{environment_filter}}) * 1000` |
| HTTP Error Rate (%) | `sum(aws_elb_httpcode_backend_5_xx_sum{%{environment_filter}}) / sum(aws_elb_request_count_sum{%{environment_filter}})` |
## Configuring Prometheus to monitor for Cloudwatch metrics
......
......@@ -62,8 +62,8 @@ Data will be encoded with a comma as the column delimiter, with `"` used to quot
| Confidential | `Yes` or `No` |
| Locked | `Yes` or `No` |
| Due Date | Formated as `YYYY-MM-DD` |
| Created At (UTC) | Formated as `YYYY-MM-DD HH:MM:SS` |
| Updated At (UTC) | Formated as `YYYY-MM-DD HH:MM:SS` |
| Created At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` |
| Updated At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` |
| Milestone | Title of the issue milestone |
| Weight | Issue weight |
| Labels | Title of any labels joined with a `,` |
......
......@@ -17,7 +17,7 @@ or through the GitLab UI.
This document describes the several ways to create a merge request.
When you start a new merge request, regarless of the method,
When you start a new merge request, regardless of the method,
you'll be taken to the [**New Merge Request** page](#new-merge-request-page)
to fill it with information about the merge request.
......@@ -29,9 +29,9 @@ button and start a merge request from there.
On the **New Merge Request** page, start by filling in the title
and description for the merge request. If there are are already
commits on the branch, the title will be pre-filled with the first
commits on the branch, the title will be prefilled with the first
line of the first commit message, and the description will be
pre-filled with any additional lines in the commit message.
prefilled with any additional lines in the commit message.
The title is the only field that is mandatory in all cases.
From there, you can fill it with information (title, description,
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment