Commit f2eb66fe authored by 🤖 GitLab Bot 🤖's avatar 🤖 GitLab Bot 🤖
Browse files

Add latest changes from gitlab-org/gitlab@master

parent c7a46b04
0fe0cfaccc979592610cbf65807f19b307957750
a7f84c7c8ea135881fd2cc6c7f48fdc487b125fb
......@@ -350,7 +350,7 @@ group :development do
end
group :development, :test do
gem 'bullet', '~> 6.0.2'
gem 'bullet', '~> 6.1.0'
gem 'pry-byebug', '~> 3.5.1', platform: :mri
gem 'pry-rails', '~> 0.3.9'
......
......@@ -145,7 +145,7 @@ GEM
brakeman (4.2.1)
browser (4.2.0)
builder (3.2.4)
bullet (6.0.2)
bullet (6.1.0)
activesupport (>= 3.0.0)
uniform_notifier (~> 1.11)
bundler-audit (0.6.1)
......@@ -1245,7 +1245,7 @@ DEPENDENCIES
bootstrap_form (~> 4.2.0)
brakeman (~> 4.2)
browser (~> 4.2)
bullet (~> 6.0.2)
bullet (~> 6.1.0)
bundler-audit (~> 0.6.1)
capybara (~> 3.33.0)
capybara-screenshot (~> 1.0.22)
......
......@@ -14,8 +14,6 @@ module SnippetsActions
skip_before_action :verify_authenticity_token,
if: -> { action_name == 'show' && js_request? }
before_action :redirect_if_binary, only: [:edit, :update]
respond_to :html
end
......@@ -134,10 +132,4 @@ def handle_repository_error(action)
recaptcha_check_with_fallback(errors.empty?) { render action }
end
def redirect_if_binary
return if Feature.enabled?(:snippets_binary_blob)
redirect_to gitlab_snippet_path(snippet) if blob&.binary?
end
end
......@@ -103,7 +103,7 @@ def update
else
render 'shared/wikis/edit'
end
rescue WikiPage::PageChangedError, WikiPage::PageRenameError, Gitlab::Git::Wiki::OperationError => e
rescue WikiPage::PageChangedError, WikiPage::PageRenameError => e
@error = e
render 'shared/wikis/edit'
end
......@@ -120,13 +120,8 @@ def create
notice: _('Wiki was successfully updated.')
)
else
flash[:alert] = response.message
render 'shared/wikis/edit'
end
rescue Gitlab::Git::Wiki::OperationError => e
@page = build_page(wiki_params)
@error = e
render 'shared/wikis/edit'
end
# rubocop:enable Gitlab/ModuleWithInstanceVariables
......@@ -162,14 +157,18 @@ def diff
# rubocop:disable Gitlab/ModuleWithInstanceVariables
def destroy
WikiPages::DestroyService.new(container: container, current_user: current_user).execute(page)
return render_404 unless page
redirect_to wiki_path(wiki),
status: :found,
notice: _("Page was successfully deleted")
rescue Gitlab::Git::Wiki::OperationError => e
@error = e
render 'shared/wikis/edit'
response = WikiPages::DestroyService.new(container: container, current_user: current_user).execute(page)
if response.success?
redirect_to wiki_path(wiki),
status: :found,
notice: _("Page was successfully deleted")
else
@error = response
render 'shared/wikis/edit'
end
end
# rubocop:enable Gitlab/ModuleWithInstanceVariables
......
......@@ -5,16 +5,15 @@ class GlobalService
include Gitlab::Utils::StrongMemoize
attr_accessor :current_user, :params
attr_reader :default_project_filter
def initialize(user, params)
@current_user, @params = user, params.dup
@default_project_filter = true
end
def execute
Gitlab::SearchResults.new(current_user, projects, params[:search],
default_project_filter: default_project_filter)
Gitlab::SearchResults.new(current_user,
params[:search],
projects)
end
def projects
......
......@@ -7,13 +7,15 @@ class GroupService < Search::GlobalService
def initialize(user, group, params)
super(user, params)
@default_project_filter = false
@group = group
end
def execute
Gitlab::GroupSearchResults.new(
current_user, projects, group, params[:search], default_project_filter: default_project_filter
current_user,
params[:search],
projects,
group: group
)
end
......
......@@ -10,9 +10,9 @@ def initialize(project, user, params)
def execute
Gitlab::ProjectSearchResults.new(current_user,
project,
params[:search],
params[:repository_ref])
project: project,
repository_ref: params[:repository_ref])
end
def scope
......
......@@ -3,11 +3,14 @@
module WikiPages
class DestroyService < WikiPages::BaseService
def execute(page)
if page&.delete
if page.delete
execute_hooks(page)
ServiceResponse.success(payload: { page: page })
else
ServiceResponse.error(
message: _('Could not delete wiki page'), payload: { page: page }
)
end
page
end
def usage_counter_action
......
---
title: Remove redirection when snippet has a binary blob
merge_request: 39858
author:
type: changed
---
title: Migration of old icon button to component button in Approval Rules (private groups)
merge_request: 39769
author:
type: changed
......@@ -4,21 +4,6 @@
require 'yaml'
SEE_DOC = "See the [changelog documentation](https://docs.gitlab.com/ee/development/changelog.html)."
CREATE_CHANGELOG_MESSAGE = <<~MSG
If you want to create a changelog entry for GitLab FOSS, run the following:
```
bin/changelog -m %<mr_iid>s "%<mr_title>s"
```
If you want to create a changelog entry for GitLab EE, run the following instead:
```
bin/changelog --ee -m %<mr_iid>s "%<mr_title>s"
```
If this merge request [doesn't need a CHANGELOG entry](https://docs.gitlab.com/ee/development/changelog.html#what-warrants-a-changelog-entry), feel free to ignore this message.
MSG
SUGGEST_MR_COMMENT = <<~SUGGEST_COMMENT
```suggestion
......@@ -70,13 +55,8 @@ def check_changelog_path(path)
end
end
def sanitized_mr_title
helper.sanitize_mr_title(gitlab.mr_json["title"])
end
if git.modified_files.include?("CHANGELOG.md")
fail "**CHANGELOG.md was edited.** Please remove the additions and create a CHANGELOG entry.\n\n" +
format(CREATE_CHANGELOG_MESSAGE, mr_iid: gitlab.mr_json["iid"], mr_title: sanitized_mr_title)
fail changelog.modified_text
end
changelog_found = changelog.found
......@@ -84,7 +64,8 @@ changelog_found = changelog.found
if changelog_found
check_changelog_yaml(changelog_found)
check_changelog_path(changelog_found)
elsif changelog.needed?
message "**[CHANGELOG missing](https://docs.gitlab.com/ee/development/changelog.html)**:\n\n" +
format(CREATE_CHANGELOG_MESSAGE, mr_iid: gitlab.mr_json["iid"], mr_title: sanitized_mr_title)
elsif changelog.required?
fail changelog.required_text
elsif changelog.optional?
message changelog.optional_text
end
......@@ -20,8 +20,8 @@ exceptions:
- AWS
- CLI
- CNAME
- CPU
- CORE
- CPU
- CSS
- CSV
- DNS
......@@ -38,6 +38,7 @@ exceptions:
- IAM
- IBM
- IDE
- IID
- IRC
- ISO
- JSON
......@@ -56,8 +57,8 @@ exceptions:
- PHP
- POST
- PUT
- RPC
- RAM
- RPC
- RSA
- RSS
- SAML
......@@ -76,9 +77,9 @@ exceptions:
- TODO
- TOML
- UNIX
- USB
- URI
- URL
- USB
- UUID
- VPC
- WIP
......
......@@ -129,7 +129,7 @@ the Omnibus GitLab distribution is not yet supported. Follow this
Prepare all your new nodes by [installing
GitLab](https://about.gitlab.com/install/).
- 1 Praefect node (minimal storage required)
- At least 1 Praefect node (minimal storage required)
- 3 Gitaly nodes (high CPU, high memory, fast storage)
- 1 GitLab server
......@@ -232,7 +232,7 @@ The database used by Praefect is now configured.
#### PgBouncer
To reduce PostgreSQL resource consumption, you should set up and configure
To reduce PostgreSQL resource consumption, we recommend setting up and configuring
[PgBouncer](https://www.pgbouncer.org/) in front of the PostgreSQL instance. To do
this, replace value of the `POSTGRESQL_SERVER_ADDRESS` with corresponding IP or host
address of the PgBouncer instance.
......@@ -275,6 +275,9 @@ PostgreSQL instances. Otherwise you should change the configuration parameter
### Praefect
NOTE: **Note:**
If there are multiple Praefect nodes, complete these steps for **each** node.
To complete this section you will need:
- [Configured PostgreSQL server](#postgresql), including:
......@@ -426,7 +429,7 @@ application server, or a Gitaly node.
1. To ensure that Praefect [has updated its Prometheus listen
address](https://gitlab.com/gitlab-org/gitaly/-/issues/2734), [restart
Gitaly](../restart_gitlab.md#omnibus-gitlab-restart):
Praefect](../restart_gitlab.md#omnibus-gitlab-restart):
```shell
gitlab-ctl restart praefect
......@@ -444,7 +447,7 @@ application server, or a Gitaly node.
**The steps above must be completed for each Praefect node!**
## Enabling TLS support
#### Enabling TLS support
> [Introduced](https://gitlab.com/gitlab-org/gitaly/-/issues/1698) in GitLab 13.2.
......@@ -730,7 +733,7 @@ After all Gitaly nodes are configured, you can run the Praefect connection
checker to verify Praefect can connect to all Gitaly servers in the Praefect
config.
1. SSH into the **Praefect** node and run the Praefect connection checker:
1. SSH into each **Praefect** node and run the Praefect connection checker:
```shell
sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml dial-nodes
......@@ -774,9 +777,9 @@ application. This is done by updating the `git_data_dirs`.
Particular attention should be shown to:
- the storage name added to `git_data_dirs` in this section must match the
storage name under `praefect['virtual_storages']` on the Praefect node. This
storage name under `praefect['virtual_storages']` on the Praefect node(s). This
was set in the [Praefect](#praefect) section of this guide. This document uses
`storage-1` as the Praefect storage name.
`default` as the Praefect storage name.
1. SSH into the **GitLab** node and login as root:
......@@ -833,7 +836,8 @@ Particular attention should be shown to:
gitlab_shell['secret_token'] = 'GITLAB_SHELL_SECRET_TOKEN'
```
1. Add Prometheus monitoring settings by editing `/etc/gitlab/gitlab.rb`.
1. Add Prometheus monitoring settings by editing `/etc/gitlab/gitlab.rb`. If Prometheus
is enabled on a different node, make edits on that node instead.
You will need to replace:
......@@ -871,7 +875,7 @@ Particular attention should be shown to:
gitlab-ctl reconfigure
```
1. Verify each `gitlab-shell` on each Gitaly instance can reach GitLab. On each Gitaly instance run:
1. Verify each `gitlab-shell` on each Gitaly node can reach GitLab. On each Gitaly node run:
```shell
/opt/gitlab/embedded/service/gitlab-shell/bin/check -config /opt/gitlab/embedded/service/gitlab-shell/config.yml
......@@ -901,7 +905,7 @@ for detailed documentation.
To get started quickly:
1. SSH into the **GitLab** node and login as root:
1. SSH into the **GitLab** node (or whichever node has Grafana enabled) and login as root:
```shell
sudo -i
......
This diff is collapsed.
......@@ -80,7 +80,7 @@ Once you're familiar with how GitLab CI/CD works, see the
for all the attributes you can set and use.
NOTE: **Note:**
GitLab CI/CD and [shared runners](runners/README.md#shared-runners) are enabled in GitLab.com and available for all users, limited only to the [user's pipelines quota](../user/gitlab_com/index.md#shared-runners).
GitLab CI/CD and [shared runners](runners/README.md#shared-runners) are enabled on GitLab.com and available for all users, limited only by the [pipeline quota](../user/gitlab_com/index.md#shared-runners).
## Concepts
......@@ -93,7 +93,7 @@ GitLab CI/CD uses a number of concepts to describe and run your build and deploy
| [Environments](environments/index.md) | Deploy your application to different environments (e.g., staging, production). |
| [Job artifacts](pipelines/job_artifacts.md) | Output, use, and reuse job artifacts. |
| [Cache dependencies](caching/index.md) | Cache your dependencies for a faster execution. |
| [GitLab Runner](https://docs.gitlab.com/runner/) | Configure your own GitLab Runners to execute your scripts. |
| [GitLab Runner](https://docs.gitlab.com/runner/) | Configure your own runners to execute your scripts. |
## Configuration
......@@ -108,7 +108,7 @@ GitLab CI/CD supports numerous configuration options:
| [Pipeline triggers](triggers/README.md) | Trigger pipelines through the API. |
| [Pipelines for Merge Requests](merge_request_pipelines/index.md) | Design a pipeline structure for running a pipeline in merge requests. |
| [Integrate with Kubernetes clusters](../user/project/clusters/index.md) | Connect your project to Google Kubernetes Engine (GKE) or an existing Kubernetes cluster. |
| [Optimize GitLab and Runner for large repositories](large_repositories/index.md) | Recommended strategies for handling large repositories. |
| [Optimize GitLab and GitLab Runner for large repositories](large_repositories/index.md) | Recommended strategies for handling large repositories. |
| [`.gitlab-ci.yml` full reference](yaml/README.md) | All the attributes you can use with GitLab CI/CD. |
Note that certain operations can only be performed according to the
......
......@@ -35,12 +35,12 @@ There are three methods to enable the use of `docker build` and `docker run`
during jobs, each with their own tradeoffs.
An alternative to using `docker build` is to [use kaniko](using_kaniko.md).
This avoids having to execute Runner in privileged mode.
This avoids having to execute a runner in privileged mode.
TIP: **Tip:**
To see how Docker and Runner are configured for shared Runners on
GitLab.com, see [GitLab.com Shared
Runners](../../user/gitlab_com/index.md#shared-runners).
To see how Docker and GitLab Runner are configured for shared runners on
GitLab.com, see [GitLab.com shared
runners](../../user/gitlab_com/index.md#shared-runners).
### Use shell executor
......@@ -123,7 +123,7 @@ not without its own challenges:
- By default, Docker 17.09 and higher uses `--storage-driver overlay2` which is
the recommended storage driver. See [Using the overlayfs driver](#use-the-overlayfs-driver)
for details.
- Since the `docker:19.03.12-dind` container and the Runner container don't share their
- Since the `docker:19.03.12-dind` container and the runner container don't share their
root file system, the job's working directory can be used as a mount point for
child containers. For example, if you have files you want to share with a
child container, you may create a subdirectory under `/builds/$CI_PROJECT_PATH`
......@@ -160,7 +160,7 @@ details.
The Docker daemon supports connection over TLS and it's done by default
for Docker 19.03.12 or higher. This is the **suggested** way to use the
Docker-in-Docker service and
[GitLab.com Shared Runners](../../user/gitlab_com/index.md#shared-runners)
[GitLab.com shared runners](../../user/gitlab_com/index.md#shared-runners)
support this.
1. Install [GitLab Runner](https://docs.gitlab.com/runner/install/).
......@@ -179,7 +179,7 @@ support this.
--docker-volumes "/certs/client"
```
The above command registers a new Runner to use the special
The above command registers a new runner to use the special
`docker:19.03.12` image, which is provided by Docker. **Notice that it's
using the `privileged` mode to start the build and service
containers.** If you want to use [Docker-in-Docker](https://www.docker.com/blog/docker-can-now-run-within-docker/) mode, you always
......@@ -255,7 +255,7 @@ Sometimes there are legitimate reasons why you might want to disable TLS.
For example, you have no control over the GitLab Runner configuration
that you are using.
Assuming that the Runner `config.toml` is similar to:
Assuming that the runner's `config.toml` is similar to:
```toml
[[runners]]
......@@ -337,10 +337,10 @@ In order to do that, follow the steps:
--docker-volumes /var/run/docker.sock:/var/run/docker.sock
```
The above command registers a new Runner to use the special
The above command registers a new runner to use the special
`docker:19.03.12` image which is provided by Docker. **Notice that it's using
the Docker daemon of the Runner itself, and any containers spawned by Docker
commands are siblings of the Runner rather than children of the Runner.**
the Docker daemon of the runner itself, and any containers spawned by Docker
commands are siblings of the runner rather than children of the runner.**
This may have complications and limitations that are unsuitable for your workflow.
The above command creates a `config.toml` entry similar to this:
......@@ -454,7 +454,7 @@ The steps in the `script` section for the `build` stage can be summed up to:
## Use the OverlayFS driver
NOTE: **Note:**
The shared Runners on GitLab.com use the `overlay2` driver by default.
The shared runners on GitLab.com use the `overlay2` driver by default.
By default, when using `docker:dind`, Docker uses the `vfs` storage driver which
copies the filesystem on every run. This is a disk-intensive operation
......@@ -504,10 +504,10 @@ environment variable in the
environment = ["DOCKER_DRIVER=overlay2"]
```
If you're running multiple Runners, you have to modify all configuration files.
If you're running multiple runners, you have to modify all configuration files.
NOTE: **Note:**
Read more about the [Runner configuration](https://docs.gitlab.com/runner/configuration/)
Read more about the [runner configuration](https://docs.gitlab.com/runner/configuration/)
and [using the OverlayFS storage driver](https://docs.docker.com/engine/userguide/storagedriver/overlayfs-driver/).
## Using the GitLab Container Registry
......
......@@ -26,7 +26,7 @@ test them on a dedicated CI server.
## Register Docker Runner
To use GitLab Runner with Docker you need to [register a new Runner](https://docs.gitlab.com/runner/register/)
To use GitLab Runner with Docker you need to [register a new runner](https://docs.gitlab.com/runner/register/)
to use the `docker` executor.
An example can be seen below. First we set up a temporary template to supply the services:
......@@ -112,7 +112,7 @@ It may be a database like MySQL, or Redis, and even `docker:stable-dind` which
allows you to use Docker in Docker. It can be practically anything that's
required for the CI/CD job to proceed and is accessed by network.
To make sure this works, the Runner:
To make sure this works, the runner:
1. Checks which ports are exposed from the container by default.
1. Starts a special container that waits for these ports to be accessible.
......@@ -382,7 +382,7 @@ services:
- mysql:latest
```
The Runner would start two containers using the `mysql:latest` image, but both
The runner would start two containers using the `mysql:latest` image, but both
of them would be added to the job's container with the `mysql` alias based on
the [default hostname naming](#accessing-the-services). This would end with one
of the services not being accessible.
......@@ -398,7 +398,7 @@ services:
alias: mysql-2
```
The Runner still starts two containers using the `mysql:latest` image,
The runner still starts two containers using the `mysql:latest` image,
however now each of them are also accessible with the alias configured
in `.gitlab-ci.yml` file.
......@@ -448,23 +448,23 @@ As you can see, the syntax of `command` is similar to [Dockerfile's `CMD`](https
> Introduced in GitLab and GitLab Runner 9.4. Read more about the [extended configuration options](#extended-docker-configuration-options).
Before showing the available entrypoint override methods, let's describe shortly
how the Runner starts and uses a Docker image for the containers used in the
how the runner starts and uses a Docker image for the containers used in the
CI jobs:
1. The Runner starts a Docker container using the defined entrypoint (default
1. The runner starts a Docker container using the defined entrypoint (default
from `Dockerfile` that may be overridden in `.gitlab-ci.yml`)
1. The Runner attaches itself to a running container.
1. The Runner prepares a script (the combination of
1. The runner attaches itself to a running container.
1. The runner prepares a script (the combination of
[`before_script`](../yaml/README.md#before_script-and-after_script),
[`script`](../yaml/README.md#script),
and [`after_script`](../yaml/README.md#before_script-and-after_script)).
1. The Runner sends the script to the container's shell STDIN and receives the
1. The runner sends the script to the container's shell STDIN and receives the
output.
To override the entrypoint of a Docker image, the recommended solution is to
define an empty `entrypoint` in `.gitlab-ci.yml`, so the Runner does not start
define an empty `entrypoint` in `.gitlab-ci.yml`, so the runner does not start
a useless shell layer. However, that does not work for all Docker versions, and
you should check which one your Runner is using. Specifically:
you should check which one your runner is using. Specifically:
- If Docker 17.06 or later is used, the `entrypoint` can be set to an empty value.
- If Docker 17.03 or previous versions are used, the `entrypoint` can be set to
......@@ -477,7 +477,7 @@ inside it and you would like to use it as a base image for your job because you
want to execute some tests with this database binary. Let's also assume that
this image is configured with `/usr/bin/super-sql run` as an entrypoint. That
means that when starting the container without additional options, it runs
the database's process, while Runner expects that the image has no
the database's process, while runner expects that the image has no
entrypoint or that the entrypoint is prepared to start a shell command.
With the extended Docker configuration options, instead of creating your
......@@ -527,7 +527,7 @@ To define which should be used, the GitLab Runner process reads the configuratio
- `DOCKER_AUTH_CONFIG` variable provided as either:
- A [variable](../variables/README.md#gitlab-cicd-environment-variables) in `.gitlab-ci.yml`.
- A project's variables stored on the projects **Settings > CI/CD** page.
- `DOCKER_AUTH_CONFIG` variable provided as environment variable in `config.toml` of the Runner.
- `DOCKER_AUTH_CONFIG` variable provided as environment variable in `config.toml` of the runner.
- `config.json` file placed in `$HOME/.docker` directory of the user running GitLab Runner process.
If the `--user` flag is provided to run the GitLab Runner child processes as unprivileged user,
the home directory of the main GitLab Runner process user is used.
......@@ -543,7 +543,7 @@ runtime.
- This feature requires GitLab Runner **1.8** or higher.
- For GitLab Runner versions **>= 0.6, <1.8** there was a partial
support for using private registries, which required manual configuration
of credentials on runner's host. We recommend to upgrade your Runner to
of credentials on runner's host. We recommend to upgrade your runner to
at least version **1.8** if you want to use private registries.
- Available for [Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes.html)
in GitLab Runner 13.1 and later.
......@@ -556,9 +556,9 @@ private registry. Both require setting the environment variable
1. Per-job: To configure one job to access a private registry, add
`DOCKER_AUTH_CONFIG` as a job variable.
1. Per-runner: To configure a Runner so all its jobs can access a
1. Per-runner: To configure a runner so all its jobs can access a
private registry, add `DOCKER_AUTH_CONFIG` to the environment in the
Runner's configuration.
runner's configuration.
See below for examples of each.
......@@ -652,12 +652,12 @@ registries to the `"auths"` hash as described above.
NOTE: **Note:**
The full `hostname:port` combination is required everywhere
for the Runner to match the `DOCKER_AUTH_CONFIG`. For example, if
for the runner to match the `DOCKER_AUTH_CONFIG`. For example, if
`registry.example.com:5000/namespace/image:tag` is specified in `.gitlab-ci.yml`,
then the `DOCKER_AUTH_CONFIG` must also specify `registry.example.com:5000`.
Specifying only `registry.example.com` does not work.
### Configuring a Runner
### Configuring a runner
If you have many pipelines that access the same registry, it is
probably better to set up registry access at the runner level. This
......@@ -670,16 +670,16 @@ registry with the same privilege, even across projects. If you need to
control access to the registry, you need to be sure to control
access to the runner.
To add `DOCKER_AUTH_CONFIG` to a Runner:
To add `DOCKER_AUTH_CONFIG` to a runner: