Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2022-06-01 00:08:20 +00:00
parent 6eaa834284
commit a6808e1619
30 changed files with 316 additions and 181 deletions

View File

@ -0,0 +1,3 @@
import mountBranchRules from '~/projects/settings/branch_rules/mount_branch_rules';
mountBranchRules(document.getElementById('js-branch-rules'));

View File

@ -0,0 +1,11 @@
<script>
export default {
name: 'RuleEdit',
};
</script>
<template>
<div>
<!-- TODO - Add branch protections (https://gitlab.com/gitlab-org/gitlab/-/issues/362212) -->
</div>
</template>

View File

@ -0,0 +1,15 @@
import Vue from 'vue';
import RuleEdit from './components/rule_edit.vue';
export default function mountBranchRules(el) {
if (!el) {
return null;
}
return new Vue({
el,
render(h) {
return h(RuleEdit);
},
});
}

View File

@ -0,0 +1,15 @@
# frozen_string_literal: true
module Projects
module Settings
class BranchRulesController < Projects::ApplicationController
before_action :authorize_admin_project!
feature_category :source_code_management
def index
render_404 unless Feature.enabled?(:branch_rules, project)
end
end
end
end

View File

@ -0,0 +1,6 @@
- add_to_breadcrumbs _('Repository Settings'), project_settings_repository_path(@project)
- page_title _('Branch rules')
%h3= _('Branch rules')
#js-branch-rules

View File

@ -147,6 +147,8 @@ constraints(::Constraints::ProjectUrlConstrainer.new) do
# See MR comment for more detail: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/27059#note_311585356
post :create_deploy_token, path: 'deploy_token/create'
post :cleanup
resources :branch_rules, only: [:index]
end
resources :access_tokens, only: [:index, :create] do

View File

@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
> - [Feature flag `ff_external_audit_events_namespace`](https://gitlab.com/gitlab-org/gitlab/-/issues/349588) removed in GitLab 14.8.
Users can set an HTTP endpoint for a top-level group to receive all audit events about the group, its subgroups, and
projects as structured JSON. Event streaming is only available for top-level groups.
projects as structured JSON.
Top-level group owners can manage their audit logs in third-party systems. Any service that can receive
structured JSON data can be used as the endpoint.

View File

@ -346,6 +346,14 @@ that do not exist in a repository.
"error":"not found: .gitlab-ci.yml"
```
### Git pushes are slow when Dynatrace is enabled
Dynatrace can cause the `/opt/gitlab/embedded/bin/gitaly-hooks` reference transaction hook,
to take several seconds to start up and shut down. `gitaly-hooks` is executed twice when users
push, which causes a significant delay.
If Git pushes are too slow when Dynatrace is enabled, disable Dynatrace.
## Troubleshoot Praefect (Gitaly Cluster)
The following sections provide possible solutions to Gitaly Cluster errors.

View File

@ -0,0 +1,57 @@
---
stage: Data Stores
group: Memory
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/#assignments
---
# IP whitelist **(FREE SELF)**
NOTE:
We intend to [rename IP whitelist as `IP allowlist`](https://gitlab.com/groups/gitlab-org/-/epics/3478).
GitLab provides some [monitoring endpoints](../../user/admin_area/monitoring/health_check.md)
that provide health check information when probed.
To control access to those endpoints via IP whitelisting, you can add single
hosts or use IP ranges:
**For Omnibus installations**
1. Open `/etc/gitlab/gitlab.rb` and add or uncomment the following:
```ruby
gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '192.168.0.1']
```
1. Save the file and [reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab for the changes to take effect.
---
**For installations using cloud native Helm charts**
You can set the required IPs under the `gitlab.webservice.monitoring.ipWhitelist` key. For example:
```yaml
gitlab:
webservice:
monitoring:
# Monitoring IP whitelist
ipWhitelist:
- 0.0.0.0/0 # Default
```
---
**For installations from source**
1. Edit `config/gitlab.yml`:
```yaml
monitoring:
# by default only local IPs are allowed to access monitoring resources
ip_whitelist:
- 127.0.0.0/8
- 192.168.0.1
```
1. Save the file and [restart](../restart_gitlab.md#installations-from-source) GitLab for the changes to take effect.

View File

@ -1,57 +1,11 @@
---
stage: Data Stores
group: Memory
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/#assignments
redirect_to: 'ip_allowlist.md'
remove_date: '2022-08-31'
---
# IP whitelist **(FREE SELF)**
This document was moved to [another location](ip_allowlist.md).
NOTE:
We intend to [rename IP whitelist as `IP allowlist`](https://gitlab.com/groups/gitlab-org/-/epics/3478).
GitLab provides some [monitoring endpoints](../../user/admin_area/monitoring/health_check.md)
that provide health check information when probed.
To control access to those endpoints via IP whitelisting, you can add single
hosts or use IP ranges:
**For Omnibus installations**
1. Open `/etc/gitlab/gitlab.rb` and add or uncomment the following:
```ruby
gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '192.168.0.1']
```
1. Save the file and [reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab for the changes to take effect.
---
**For installations using cloud native Helm charts**
You can set the required IPs under the `gitlab.webservice.monitoring.ipWhitelist` key. For example:
```yaml
gitlab:
webservice:
monitoring:
# Monitoring IP whitelist
ipWhitelist:
- 0.0.0.0/0 # Default
```
---
**For installations from source**
1. Edit `config/gitlab.yml`:
```yaml
monitoring:
# by default only local IPs are allowed to access monitoring resources
ip_whitelist:
- 127.0.0.0/8
- 192.168.0.1
```
1. Save the file and [restart](../restart_gitlab.md#installations-from-source) GitLab for the changes to take effect.
<!-- This redirect file can be deleted after <2022-08-31>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

View File

@ -19,8 +19,6 @@ To use GitLab CI/CD with a Bitbucket Cloud repository:
1. Select **Run CI/CD for external repository**.
1. Select **Repository by URL**.
![Create project](img/external_repository.png)
GitLab imports the repository and enables [Pull Mirroring](../../user/project/repository/mirror/pull.md).
1. In GitLab, create a

Binary file not shown.

Before

Width:  |  Height:  |  Size: 31 KiB

After

Width:  |  Height:  |  Size: 21 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 26 KiB

After

Width:  |  Height:  |  Size: 24 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 22 KiB

View File

@ -7,7 +7,7 @@ type: reference
# Where variables can be used **(FREE)**
As it's described in the [CI/CD variables](index.md) docs, you can
As it's described in the [CI/CD variables](index.md) documentation, you can
define many different variables. Some of them can be used for all GitLab CI/CD
features, but some of them are more or less limited.
@ -17,30 +17,30 @@ This document describes where and how the different types of variables can be us
There are two places defined variables can be used. On the:
1. GitLab side, in `.gitlab-ci.yml`.
1. GitLab side, in the [`.gitlab-ci.yml` file](../yaml/index.md).
1. The GitLab Runner side, in `config.toml`.
### `.gitlab-ci.yml` file
| Definition | Can be expanded? | Expansion place | Description |
|:----------------------|:-----------------|:-----------------------|:------------|
| `after_script` | yes | Script execution shell | The variable expansion is made by the [execution shell environment](#execution-shell-environment). |
| `artifacts:name` | yes | Runner | The variable expansion is made by GitLab Runner's shell environment. |
| `before_script` | yes | Script execution shell | The variable expansion is made by the [execution shell environment](#execution-shell-environment) |
| `cache:key` | yes | Runner | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism). |
| `environment:name` | yes | GitLab | Similar to `environment:url`, but the variables expansion doesn't support the following:<br/><br/>- Variables that are based on the environment's name (`CI_ENVIRONMENT_NAME`, `CI_ENVIRONMENT_SLUG`).<br/>- Any other variables related to environment (currently only `CI_ENVIRONMENT_URL`).<br/>- [Persisted variables](#persisted-variables). |
| `environment:url` | yes | GitLab | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab.<br/><br/>Supported are all variables defined for a job (project/group variables, variables from `.gitlab-ci.yml`, variables from triggers, variables from pipeline schedules).<br/><br/>Not supported are variables defined in the GitLab Runner `config.toml` and variables created in the job's `script`. |
| `except:variables:[]` | no | Not applicable | The variable must be in the form of `$variable`. Not supported are the following:<br/><br/>- Variables that are based on the environment's name (`CI_ENVIRONMENT_NAME`, `CI_ENVIRONMENT_SLUG`).<br/>- Any other variables related to environment (currently only `CI_ENVIRONMENT_URL`).<br/>- [Persisted variables](#persisted-variables). |
| `image` | yes | Runner | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism). |
| `include` | yes | GitLab | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab. <br/><br/>Predefined project variables are supported: `GITLAB_FEATURES`, `CI_DEFAULT_BRANCH`, and all variables that start with `CI_PROJECT_` (for example `CI_PROJECT_NAME`). |
| `only:variables:[]` | no | Not applicable | The variable must be in the form of `$variable`. Not supported are the following:<br/><br/>- Variables that are based on the environment's name (`CI_ENVIRONMENT_NAME`, `CI_ENVIRONMENT_SLUG`).<br/>- Any other variables related to environment (currently only `CI_ENVIRONMENT_URL`).<br/>- [Persisted variables](#persisted-variables). |
| `resource_group` | yes | GitLab | Similar to `environment:url`, but the variables expansion doesn't support the following:<br/>- `CI_ENVIRONMENT_URL`<br/>- [Persisted variables](#persisted-variables). |
| `rules:if` | no | Not applicable | The variable must be in the form of `$variable`. Not supported are the following:<br/><br/>- Variables that are based on the environment's name (`CI_ENVIRONMENT_NAME`, `CI_ENVIRONMENT_SLUG`).<br/>- Any other variables related to environment (currently only `CI_ENVIRONMENT_URL`).<br/>- [Persisted variables](#persisted-variables). |
| `script` | yes | Script execution shell | The variable expansion is made by the [execution shell environment](#execution-shell-environment). |
| `services:[]:name` | yes | Runner | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism). |
| `services:[]` | yes | Runner | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism). |
| `tags` | yes | GitLab | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35742) in GitLab 14.1. |
| `variables` | yes | GitLab/Runner | The variable expansion is first made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab, and then any unrecognized or unavailable variables are expanded by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism). |
| Definition | Can be expanded? | Expansion place | Description |
|:----------------------------------------------------------------------|:-----------------|:-----------------------|:------------|
| [`after_script`](../yaml/index.md#after_script) | yes | Script execution shell | The variable expansion is made by the [execution shell environment](#execution-shell-environment). |
| [`artifacts:name`](../yaml/index.md#artifactsname) | yes | Runner | The variable expansion is made by GitLab Runner's shell environment. |
| [`before_script`](../yaml/index.md#before_script) | yes | Script execution shell | The variable expansion is made by the [execution shell environment](#execution-shell-environment) |
| [`cache:key`](../yaml/index.md#cachekey) | yes | Runner | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism). |
| [`environment:name`](../yaml/index.md#environmentname) | yes | GitLab | Similar to `environment:url`, but the variables expansion doesn't support the following:<br/><br/>- Variables that are based on the environment's name (`CI_ENVIRONMENT_NAME`, `CI_ENVIRONMENT_SLUG`).<br/>- Any other variables related to environment (currently only `CI_ENVIRONMENT_URL`).<br/>- [Persisted variables](#persisted-variables). |
| [`environment:url`](../yaml/index.md#environmenturl) | yes | GitLab | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab.<br/><br/>Supported are all variables defined for a job (project/group variables, variables from `.gitlab-ci.yml`, variables from triggers, variables from pipeline schedules).<br/><br/>Not supported are variables defined in the GitLab Runner `config.toml` and variables created in the job's `script`. |
| [`except:variables`](../yaml/index.md#onlyvariables--exceptvariables) | no | Not applicable | The variable must be in the form of `$variable`. Not supported are the following:<br/><br/>- Variables that are based on the environment's name (`CI_ENVIRONMENT_NAME`, `CI_ENVIRONMENT_SLUG`).<br/>- Any other variables related to environment (currently only `CI_ENVIRONMENT_URL`).<br/>- [Persisted variables](#persisted-variables). |
| [`image`](../yaml/index.md#image) | yes | Runner | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism). |
| [`include`](../yaml/index.md#include) | yes | GitLab | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab. <br/><br/>Predefined project variables are supported: `GITLAB_FEATURES`, `CI_DEFAULT_BRANCH`, and all variables that start with `CI_PROJECT_` (for example `CI_PROJECT_NAME`). |
| [`only:variables`](../yaml/index.md#onlyvariables--exceptvariables) | no | Not applicable | The variable must be in the form of `$variable`. Not supported are the following:<br/><br/>- Variables that are based on the environment's name (`CI_ENVIRONMENT_NAME`, `CI_ENVIRONMENT_SLUG`).<br/>- Any other variables related to environment (currently only `CI_ENVIRONMENT_URL`).<br/>- [Persisted variables](#persisted-variables). |
| [`resource_group`](../yaml/index.md#resource_group) | yes | GitLab | Similar to `environment:url`, but the variables expansion doesn't support the following:<br/>- `CI_ENVIRONMENT_URL`<br/>- [Persisted variables](#persisted-variables). |
| [`rules:if`](../yaml/index.md#rulesif) | no | Not applicable | The variable must be in the form of `$variable`. Not supported are the following:<br/><br/>- Variables that are based on the environment's name (`CI_ENVIRONMENT_NAME`, `CI_ENVIRONMENT_SLUG`).<br/>- Any other variables related to environment (currently only `CI_ENVIRONMENT_URL`).<br/>- [Persisted variables](#persisted-variables). |
| [`script`](../yaml/index.md#script) | yes | Script execution shell | The variable expansion is made by the [execution shell environment](#execution-shell-environment). |
| [`services:name`](../yaml/index.md#services) | yes | Runner | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism). |
| [`services`](../yaml/index.md#services) | yes | Runner | The variable expansion is made by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism). |
| [`tags`](../yaml/index.md#tags) | yes | GitLab | The variable expansion is made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35742) in GitLab 14.1. |
| [`variables`](../yaml/index.md#variables) | yes | GitLab/Runner | The variable expansion is first made by the [internal variable expansion mechanism](#gitlab-internal-variable-expansion-mechanism) in GitLab, and then any unrecognized or unavailable variables are expanded by GitLab Runner's [internal variable expansion mechanism](#gitlab-runner-internal-variable-expansion-mechanism). |
### `config.toml` file

View File

@ -175,6 +175,8 @@ Use `include:local` instead of symbolic links.
- The YAML file must have the extension `.yml` or `.yaml`.
- You can [use `*` and `**` wildcards in the file path](includes.md#use-includelocal-with-wildcard-file-paths).
CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
**Example of `include:local`**:
```yaml
@ -209,6 +211,8 @@ use `include:file`. You can use `include:file` in combination with `include:proj
- A full path, relative to the root directory (`/`). The YAML file must have the
extension `.yml` or `.yaml`.
CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
**Example of `include:file`**:
```yaml
@ -267,6 +271,8 @@ Use `include:remote` with a full URL to include a file from a different location
- A public URL accessible by an HTTP/HTTPS `GET` request. Authentication with the
remote URL is not supported. The YAML file must have the extension `.yml` or `.yaml`.
CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
**Example of `include:remote`**:
```yaml
@ -292,6 +298,8 @@ Use `include:template` to include [`.gitlab-ci.yml` templates](https://gitlab.co
- [`.gitlab-ci.yml` templates](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates).
CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
**Example of `include:template`**:
```yaml
@ -504,6 +512,8 @@ Use `after_script` to define an array of commands that run after each job, inclu
- Long commands [split over multiple lines](script.md#split-long-commands).
- [YAML anchors](yaml_optimization.md#yaml-anchors-for-scripts).
CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
**Example of `after_script`**:
```yaml
@ -809,8 +819,8 @@ If not defined, the default name is `artifacts`, which becomes `artifacts.zip` w
**Possible inputs**:
- The name of the artifacts archive. Can use [CI/CD variables](../variables/index.md). Must be combined with
[`artifacts:paths`](#artifactspaths).
- The name of the artifacts archive. CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
Must be combined with [`artifacts:paths`](#artifactspaths).
**Example of `artifacts:name`**:
@ -1002,6 +1012,8 @@ Use `before_script` to define an array of commands that should run before each j
- Long commands [split over multiple lines](script.md#split-long-commands).
- [YAML anchors](yaml_optimization.md#yaml-anchors-for-scripts).
CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
**Example of `before_script`**:
```yaml
@ -1088,7 +1100,7 @@ no `cache:key` share the `default` cache.
**Possible inputs**:
- A string.
- A [predefined variables](../variables/index.md).
- A predefined [CI/CD variable](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
- A combination of both.
**Example of `cache:key`**:
@ -1505,7 +1517,8 @@ Common environment names are `qa`, `staging`, and `production`, but you can use
formats:
- Plain text, including letters, digits, spaces, and these characters: `-`, `_`, `/`, `$`, `{`, `}`.
- CI/CD variables, including predefined, project, group, instance, or variables defined in the
- [CI/CD variables](../variables/where_variables_can_be_used.md#gitlab-ciyml-file),
including predefined, project, group, instance, or variables defined in the
`.gitlab-ci.yml` file. You can't use variables defined in a `script` section.
**Example of `environment:name`**:
@ -1527,7 +1540,8 @@ Set a URL for an [environment](../environments/index.md).
**Possible inputs**: A single URL, in one of these formats:
- Plain text, like `https://prod.example.com`.
- CI/CD variables, including predefined, project, group, instance, or variables defined in the
- [CI/CD variables](../variables/where_variables_can_be_used.md#gitlab-ciyml-file),
including predefined, project, group, instance, or variables defined in the
`.gitlab-ci.yml` file. You can't use variables defined in a `script` section.
**Example of `environment:url`**:
@ -1789,6 +1803,8 @@ Use `image` to specify a Docker image that the job runs in.
- `<image-name>:<tag>`
- `<image-name>@<digest>`
CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
**Example of `image`**:
```yaml
@ -2170,8 +2186,8 @@ build_job:
In this example, `build_job` downloads the artifacts from the latest successful `build-1` job
on the `main` branch in the `group/project-name` project.
In GitLab 13.3 and later, you can use [CI/CD variables](../variables/index.md) in `needs:project`,
for example:
In GitLab 13.3 and later, you can use [CI/CD variables](../variables/where_variables_can_be_used.md#gitlab-ciyml-file)
in `needs:project`, for example:
```yaml
build_job:
@ -2751,7 +2767,9 @@ New tags use the SHA associated with the pipeline.
**Possible inputs**:
- A tag name. Can use [CI/CD variables](../variables/index.md).
- A tag name.
CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
**Example of `release:tag_name`**:
@ -2900,7 +2918,7 @@ can be deployed to, but only one deployment can occur per device at any given ti
**Possible inputs**:
- Only letters, digits, `-`, `_`, `/`, `$`, `{`, `}`, `.`, and spaces.
It can't start or end with `/`.
It can't start or end with `/`. CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
**Example of `resource_group`**:
@ -3263,6 +3281,8 @@ All jobs except [trigger jobs](#trigger) require a `script` keyword.
- Long commands [split over multiple lines](script.md#split-long-commands).
- [YAML anchors](yaml_optimization.md#yaml-anchors-for-scripts).
CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
**Example of `script`**:
```yaml
@ -3397,6 +3417,8 @@ to the image specified in the [`image`](#image) keyword.
- `<image-name>:<tag>`
- `<image-name>@<digest>`
CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
**Example of `services`**:
```yaml
@ -3567,7 +3589,8 @@ be assigned every tag listed in the job.
**Possible inputs**:
- An array of tag names.
- [CI/CD variables](../runners/configure_runners.md#use-cicd-variables-in-tags) in GitLab 14.1 and later.
- CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file)
in GitLab 14.1 and later.
**Example of `tags`**:
@ -3777,6 +3800,8 @@ variable defined, the [job-level variable takes precedence](../variables/index.m
the first character must be a letter.
- The value must be a string.
CI/CD variables [are supported](../variables/where_variables_can_be_used.md#gitlab-ciyml-file).
**Examples of `variables`**:
```yaml

View File

@ -210,25 +210,13 @@ This function should be imported and called in the [page-specific JavaScript](fe
= s_('Settings|Merge method')
.gl-form-radio.custom-control.custom-radio
= f.radio_button :merge_method, :merge, class: "custom-control-input", disabled: merge_method_locked
= f.label :merge_method_merge, class: 'custom-control-label' do
= s_('Settings|Merge commit')
%p.help-text
= s_('Settings|Every merge creates a merge commit.')
= f.gitlab_ui_radio_component :merge_method, :merge, s_('Settings|Merge commit'), help_text: s_('Settings|Every merge creates a merge commit.'), radio_options: { disabled: merge_method_locked }
.gl-form-radio.custom-control.custom-radio
= f.radio_button :merge_method, :rebase_merge, class: "custom-control-input", disabled: merge_method_locked
= f.label :merge_method_rebase_merge, class: 'custom-control-label' do
= s_('Settings|Merge commit with semi-linear history')
%p.help-text
= s_('Settings|Every merge creates a merge commit.')
= f.gitlab_ui_radio_component :merge_method, :rebase_merge, s_('Settings|Merge commit with semi-linear history'), help_text: s_('Settings|Every merge creates a merge commit.'), radio_options: { disabled: merge_method_locked }
.gl-form-radio.custom-control.custom-radio
= f.radio_button :merge_method, :ff, class: "custom-control-input", disabled: merge_method_locked
= f.label :merge_method_ff, class: 'custom-control-label' do
= s_('Settings|Fast-forward merge')
%p.help-text
= s_('Settings|No merge commits are created.')
= f.gitlab_ui_radio_component :merge_method, :ff, s_('Settings|Fast-forward merge'), help_text: s_('Settings|No merge commits are created.'), radio_options: { disabled: merge_method_locked }
= render 'shared/namespaces/cascading_settings/enforcement_checkbox',
attribute: :merge_method,

View File

@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Review Apps
Review Apps are deployed using the `start-review-app-pipeline` job. This job triggers a child pipeline containing a series of jobs to perform the various tasks needed to deploy a Review App.
Review Apps are deployed using the `start-review-app-pipeline` job which triggers a child pipeline containing a series of jobs to perform the various tasks needed to deploy a Review App.
![start-review-app-pipeline job](img/review-app-parent-pipeline.png)
@ -27,6 +27,8 @@ On every [pipeline](https://gitlab.com/gitlab-org/gitlab/pipelines/125315730) in
`review` stage), the `review-qa-smoke` and `review-qa-reliable` jobs are automatically started. The `review-qa-smoke` runs
the QA smoke suite and the `review-qa-reliable` executes E2E tests identified as [reliable](https://about.gitlab.com/handbook/engineering/quality/quality-engineering/reliable-tests).
`review-qa-*` jobs ensure that end-to-end tests for the changes in the merge request pass in a live environment. This shifts the identification of e2e failures from an environment on the path to production to the merge request, to prevent breaking features on GitLab.com or costly GitLab.com deployment blockers. `review-qa-*` failures should be investigated with counterpart SET involvement if needed to help determine the root cause of the error.
You can also manually start the `review-qa-all`: it runs the full QA suite.
After the end-to-end test runs have finished, [Allure reports](https://github.com/allure-framework/allure2) are generated and published by
@ -34,6 +36,10 @@ the `allure-report-qa-smoke`, `allure-report-qa-reliable`, and `allure-report-qa
Errors can be found in the `gitlab-review-apps` Sentry project and [filterable by Review App URL](https://sentry.gitlab.net/gitlab/gitlab-review-apps/?query=url%3A%22https%3A%2F%2Fgitlab-review-require-ve-u92nn2.gitlab-review.app%2F%22) or [commit SHA](https://sentry.gitlab.net/gitlab/gitlab-review-apps/releases/6095b501da7/all-events/).
### Bypass failed review app deployment to merge a broken `master` fix
Maintainers can elect to use the [process for merging during broken `master`](https://about.gitlab.com/handbook/engineering/workflow/#instructions-for-the-maintainer) if a customer-critical merge request is blocked by pipelines failing due to review app deployment failures.
## Performance Metrics
On every [pipeline](https://gitlab.com/gitlab-org/gitlab/pipelines/125315730) in the `qa` stage, the

Binary file not shown.

Before

Width:  |  Height:  |  Size: 49 KiB

View File

@ -9,14 +9,14 @@ info: To determine the technical writer assigned to the Stage/Group associated w
You can import your existing repositories by providing the Git URL:
1. From your GitLab dashboard select **New project**.
1. Switch to the **Import project** tab.
1. On the top bar, select **Menu > Create new project**.
1. Select the **Import project** tab.
1. Select **Repository by URL**.
1. Fill in the "Git repository URL" and the remaining project fields.
1. Select **Create project** to begin the import process.
1. Once complete, you are redirected to your newly created project.
1. Enter a **Git repository URL**.
1. Complete the remaining fields.
1. Select **Create project**.
![Import project by repository URL](img/import_projects_from_repo_url.png)
Your newly created project is displayed.
## Automate group and project import **(PREMIUM)**

View File

@ -9,27 +9,23 @@ type: reference
> Moved to GitLab Premium in 13.9.
NOTE:
This is the user documentation. To configure the Advanced Search,
visit the [administrator documentation](../../integration/elasticsearch.md).
Advanced Search is enabled in GitLab.com.
Advanced Search uses Elasticsearch for faster, more advanced search across the entire
GitLab instance.
GitLab Advanced Search expands on the Basic Search with an additional set of
features for faster, more advanced searches across the entire GitLab instance
when searching in:
Use Advanced Search when searching in:
- Projects
- Issues
- Merge requests
- Milestones
- Epics
- Comments
- Code
- Commits
- Users
- Epics (when searching in a group only)
- Code
- Comments
- Commits
- Wiki (except [group wikis](../project/wiki/group.md))
The Advanced Search can be useful in various scenarios:
Advanced Search can be useful in various scenarios:
- **Faster searches:**
Advanced Search is based on Elasticsearch, which is a purpose-built full
@ -46,6 +42,13 @@ The Advanced Search can be useful in various scenarios:
may be connected to each other, so your developers need to instantly search
throughout the GitLab instance and find the code they search for.
## Configuring Advanced Search
For self-managed GitLab instances, an administrator must
[configure Advanced Search](../../integration/elasticsearch.md).
On GitLab.com, Advanced Search is enabled.
## Advanced Search syntax
See the documentation on [Advanced Search syntax](global_search/advanced_search_syntax.md).

Binary file not shown.

Before

Width:  |  Height:  |  Size: 19 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 51 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 8.1 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 11 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

View File

@ -1,11 +1,66 @@
---
stage: Create
group: Editor
stage: Data Stores
group: Global Search
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/#assignments
---
# Searching in GitLab **(FREE)**
GitLab has two types of searches available: _basic_ and _advanced_.
Both types of search are the same, except when you are searching through code.
- When you use basic search to search code, your search includes one project at a time.
- When you use [advanced search](advanced_search.md) to search code, your search includes all projects at once.
## Basic search
Use basic search to find:
- Projects
- Issues
- Merge requests
- Milestones
- Users
- Epics (when searching in a group only)
- Code
- Comments
- Commits
- Wiki
## Perform a search
To start a search, type your search query in the search bar on the top-right of the screen.
![basic search](img/basic_search_v15_1.png)
After the results are displayed, you can modify the search, select a different type of data to
search, or choose a specific group or project.
![basic_search_results](img/basic_search_results_v15_1.png)
## Code search
To search through code or other documents in a single project, you can use
the search field on the top-right of your screen while the project page is open.
Code search shows only the first result in the file.
### Git blame from code search
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/327052) in GitLab 14.7.
You can access Git blame from any line that returned a result from the code search:
![code search results](img/code_search_git_blame_v15_1.png)
## SHA search
You can quickly access a commit from the project dashboard by entering the SHA
into the search field on the top right of the screen. If a single result is found, you are
redirected to the commit result and given the option to return to the search results page.
![project SHA search redirect](img/project_search_sha_redirect.png)
## Search issues and merge requests
To search through issues and merge requests in multiple projects, on the top bar, select the **Issues** or **Merge requests** links.
@ -258,63 +313,6 @@ In the search bar, you can view autocomplete suggestions for:
- Recently viewed epics (try and type some word from the title of a recently viewed epic)
- [GitLab Flavored Markdown](../markdown.md#gitlab-specific-references) (GLFM) for issues in a project (try and type a GLFM reference for an issue)
## Basic search
The Basic search in GitLab enables you to search
across the entire GitLab instance, in a group, or in a single project. Basic search is
backed by the database and allows searching in:
- Projects
- Issues
- Merge requests
- Milestones
- Users
- Epics (Group only)
- Code (Project only)
- Comments (Project only)
- Commits (Project only)
- Wiki (Project only)
To start a search, type into the search bar on the top-right of the screen. You can always search
in all GitLab and may also see the options to search in a group or project if you are in the
group or project dashboard.
![basic search](img/basic_search_v14_4.png)
After the results are returned, you can modify the search, select a different type of data to
search, or choose a specific group or project.
![basic_search_results](img/basic_search_results.png)
### Code search
To search through code or other documents in a single project, you can use
the search field on the top-right of your screen while the project page is open.
Code search shows only the first result in the file.
#### Git blame from code search **(FREE)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/327052) in GitLab 14.7.
You can access Git blame from any line that returned a result from the code search:
![code search results](img/code_search_git_blame_v14_9.png)
### SHA search
You can quickly access a commit from the project dashboard by entering the SHA
into the search field on the top right of the screen. If a single result is found, you are
redirected to the commit result and given the option to return to the search results page.
![project SHA search redirect](img/project_search_sha_redirect.png)
## Advanced Search **(PREMIUM)**
Leverage Elasticsearch for faster, more advanced code search across your entire
GitLab instance.
[Learn how to use the Advanced Search.](advanced_search.md)
## Search settings
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/292941) in GitLab 13.8 [with a flag](../../administration/feature_flags.md) named `search_settings_in_page`. Disabled by default.

View File

@ -11,7 +11,6 @@ User=git
WorkingDirectory=/home/git/gitlab
Environment=RAILS_ENV=production
ExecStart=/usr/local/bin/bundle exec sidekiq --config /home/git/gitlab/config/sidekiq_queues.yml --environment production
ExecStop=/usr/local/bin/bundle exec sidekiqctl stop /run/gitlab/sidekiq.pid
PIDFile=/home/git/gitlab/tmp/pids/sidekiq.pid
Restart=on-failure
RestartSec=1

View File

@ -0,0 +1,47 @@
# frozen_string_literal: true
require 'spec_helper'
RSpec.describe 'Projects > Settings > Repository > Branch rules settings' do
let(:project) { create(:project_empty_repo) }
let(:user) { create(:user) }
let(:role) { :developer }
subject(:request) { visit project_settings_repository_branch_rules_path(project) }
before do
project.add_role(user, role)
sign_in(user)
end
context 'for developer' do
let(:role) { :developer }
it 'is not allowed to view' do
request
expect(page).to have_gitlab_http_status(:not_found)
end
end
context 'for maintainer' do
let(:role) { :maintainer }
context 'Branch rules', :js do
it 'renders branch rules page' do
request
expect(page).to have_content('Branch rules')
end
end
context 'branch_rules feature flag disabled' do
it 'does not render branch rules content' do
stub_feature_flags(branch_rules: false)
request
expect(page).to have_gitlab_http_status(:not_found)
end
end
end
end