kotovalexarian-likes-gitlab
/
gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2022-05-26 18:08:09 +00:00
parent cac0926ddb
commit f52b15b639
40 changed files with 279 additions and 179 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
app/assets/javascripts/packages_and_registries/shared/components/cli_commands.vue
View File

@ -49,7 +49,7 @@ export default {
<template>
<gl-dropdown
:text="$options.i18n.QUICK_START"
variant="info"
variant="confirm"
right
@shown="track('click_dropdown')"
>

2
app/graphql/types/group_member_type.rb
View File

@ -15,7 +15,7 @@ module Types
field :notification_email,
resolver: Resolvers::GroupMembers::NotificationEmailResolver,
description: "Group notification email for User. Only availble for admins."
description: "Group notification email for User. Only available for admins."
def group
Gitlab::Graphql::Loaders::BatchModelLoader.new(Group, object.source_id).find

8
config/feature_flags/development/container_security_policy_selection.yml
View File

@ -1,8 +0,0 @@
---
name: container_security_policy_selection
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80272
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/353071
milestone: '14.10'
type: development
group: group::container security
default_enabled: true

8
config/feature_flags/development/omniauth_initializer_fullhost_proc.yml
View File

@ -1,8 +0,0 @@
---
name: omniauth_initializer_fullhost_proc
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/82703
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/355579
milestone: '14.10'
type: development
group: group::geo
default_enabled: true

9
config/initializers/omniauth.rb
View File

@ -11,14 +11,7 @@ if Gitlab::Auth::Ldap::Config.enabled?
end
end
OmniAuth.config.full_host =
if Feature.feature_flags_available? && ::Feature.enabled?(:omniauth_initializer_fullhost_proc)
Gitlab::AppLogger.debug("Using OmniAuth proc initializer")
Gitlab::OmniauthInitializer.full_host
else
Gitlab::AppLogger.debug("Fallback to OmniAuth static full_host")
Settings.gitlab['base_url']
end
OmniAuth.config.full_host = Gitlab::OmniauthInitializer.full_host
OmniAuth.config.allowed_request_methods = [:post]
# In case of auto sign-in, the GET method is used (users don't get to click on a button)

14
data/deprecations/14-5-runner-s3-authenticationtype-nonexplicit-config-deprecation.yml
View File

@ -1,14 +0,0 @@
- name: "Must explicitly assign `AuthenticationType` for `[runners.cache.s3]`"
announcement_milestone: "14.5" # The milestone when this feature was first announced as deprecated.
announcement_date: "2021-11-22"
removal_milestone: "15.0" # the milestone when this feature is planned to be removed
removal_date: "2022-05-22" # the date of the milestone release when this feature is planned to be removed
breaking_change: true
body: | # Do not modify this line, instead modify the lines below.
In GitLab 15.0 and later, to access the AWS S3 cache, you must specify the `AuthenticationType` for [`[runners.cache.s3]`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerscaches3-section). The `AuthenticationType` must be `IAM` or `credentials`.
Prior to 14.5, if you did not define the `AuthenticationType`, GitLab Runner chose a type for you.
stage: Verify
tiers: [Core, Premium, Ultimate]
issue_url: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28171
documentation_url: https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerscaches3-section

2
doc/administration/auth/authentiq.md
View File

@ -69,7 +69,7 @@ Authentiq generates a Client ID and the accompanying Client Secret for you to us
1. [Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect if you installed GitLab via Omnibus or from source respectively.
On the sign in page there should now be an Authentiq icon below the regular sign in form. Click the
On the sign in page there should now be an Authentiq icon below the regular sign in form. Select the
icon to begin the authentication process. If the user:
- Has the Authentiq ID app installed in their iOS or Android device, they can:

4
doc/administration/configure.md
View File

@ -46,5 +46,5 @@ The following table outlines failure modes and mitigation paths for the product
| Single Gitaly Node + Geo Secondary | Downtime - Must restore from backup, can perform a manual failover to secondary | Downtime - Must restore from Backup, errors could have propagated to secondary | Manual intervention - failover to Geo secondary | |
| Sharded Gitaly Install | Partial Downtime - Only repositories on impacted node affected, must restore from backup | Partial Downtime - Only repositories on impacted node affected, must restore from backup | Downtime - Must wait for outage to end | |
| Sharded Gitaly Install + Geo Secondary | Partial Downtime - Only repositories on impacted node affected, must restore from backup, could perform manual failover to secondary for impacted repositories | Partial Downtime - Only repositories on impacted node affected, must restore from backup, errors could have propagated to secondary | Manual intervention - failover to Geo secondary | |
| Gitaly Cluster Install* | No Downtime - will swap repository primary to another node after 10 seconds | N/A - All writes are voted on by multiple Gitaly Cluster nodes | Downtime - Must wait for outage to end | Snapshot backups for Gitaly Cluster nodes not supported at this time |
| Gitaly Cluster Install* + Geo Secondary | No Downtime - will swap repository primary to another node after 10 seconds | N/A - All writes are voted on by multiple Gitaly Cluster nodes | Manual intervention - failover to Geo secondary | Snapshot backups for Gitaly Cluster nodes not supported at this time |
| Gitaly Cluster Install* | No Downtime - will swap repository primary to another node after 10 seconds | Not applicable; All writes are voted on by multiple Gitaly Cluster nodes | Downtime - Must wait for outage to end | Snapshot backups for Gitaly Cluster nodes not supported at this time |
| Gitaly Cluster Install* + Geo Secondary | No Downtime - will swap repository primary to another node after 10 seconds | Not applicable; All writes are voted on by multiple Gitaly Cluster nodes | Manual intervention - failover to Geo secondary | Snapshot backups for Gitaly Cluster nodes not supported at this time |

2
doc/administration/geo/replication/datatypes.md
View File

@ -26,7 +26,7 @@ verification methods:
| Type | Feature / component | Replication method | Verification method |
|:---------|:------------------------------------------------|:--------------------------------------|:-----------------------|
| Database | Application data in PostgreSQL | Native | Native |
| Database | Redis | _N/A_ (*1*) | _N/A_ |
| Database | Redis | Not applicable (*1*) | Not applicable |
| Database | Elasticsearch | Native | Native |
| Database | SSH public keys | PostgreSQL Replication | PostgreSQL Replication |
| Git | Project repository | Geo with Gitaly | Gitaly Checksum |

2
doc/administration/monitoring/gitlab_self_monitoring_project/index.md
View File

@ -54,7 +54,7 @@ you create the project again, it's created in its default state.
1. On the top bar, select **Menu > Admin**.
1. On the left sidebar, go to **Settings > Metrics and profiling** and expand **Self monitoring**.
1. Toggle **Self monitoring** off.
1. In the confirmation dialog that opens, click **Delete self monitoring project**.
1. In the confirmation dialog that opens, select **Delete self monitoring project**.
It can take a few seconds for it to be deleted.
1. After the project is deleted, GitLab displays a message confirming your action.

14
doc/administration/operations/puma.md
View File

@ -252,19 +252,19 @@ To switch from Unicorn to Puma:
| `unicorn['enable']` | `puma['enable']` |
| `unicorn['worker_timeout']` | `puma['worker_timeout']` |
| `unicorn['worker_processes']` | `puma['worker_processes']` |
| n/a | `puma['ha']` |
| n/a | `puma['min_threads']` |
| n/a | `puma['max_threads']` |
| Not applicable | `puma['ha']` |
| Not applicable | `puma['min_threads']` |
| Not applicable | `puma['max_threads']` |
| `unicorn['listen']` | `puma['listen']` |
| `unicorn['port']` | `puma['port']` |
| `unicorn['socket']` | `puma['socket']` |
| `unicorn['pidfile']` | `puma['pidfile']` |
| `unicorn['tcp_nopush']` | n/a |
| `unicorn['backlog_socket']` | n/a |
| `unicorn['tcp_nopush']` | Not applicable |
| `unicorn['backlog_socket']` | Not applicable |
| `unicorn['somaxconn']` | `puma['somaxconn']` |
| n/a | `puma['state_path']` |
| Not applicable | `puma['state_path']` |
| `unicorn['log_directory']` | `puma['log_directory']` |
| `unicorn['worker_memory_limit_min']` | n/a |
| `unicorn['worker_memory_limit_min']` | Not applicable |
| `unicorn['worker_memory_limit_max']` | `puma['per_worker_max_memory_mb']` |
| `unicorn['exporter_enabled']` | `puma['exporter_enabled']` |
| `unicorn['exporter_address']` | `puma['exporter_address']` |

2
doc/administration/system_hooks.md
View File

@ -61,7 +61,7 @@ To create a system hook:
1. Provide the **URL** and **Secret Token**.
1. Select the checkbox next to each optional **Trigger** you want to enable.
1. Select **Enable SSL verification**, if desired.
1. Click **Add system hook**.
1. Select **Add system hook**.
## Hooks request example

2
doc/api/graphql/reference/index.md
View File

@ -12081,7 +12081,7 @@ Represents a Group Membership.
| <a id="groupmemberexpiresat"></a>`expiresAt` | [`Time`](#time) | Date and time the membership expires. |
| <a id="groupmembergroup"></a>`group` | [`Group`](#group) | Group that a User is a member of. |
| <a id="groupmemberid"></a>`id` | [`ID!`](#id) | ID of the member. |
| <a id="groupmembernotificationemail"></a>`notificationEmail` | [`String`](#string) | Group notification email for User. Only availble for admins. |
| <a id="groupmembernotificationemail"></a>`notificationEmail` | [`String`](#string) | Group notification email for User. Only available for admins. |
| <a id="groupmemberupdatedat"></a>`updatedAt` | [`Time`](#time) | Date and time the membership was last updated. |
| <a id="groupmemberuser"></a>`user` | [`UserCore`](#usercore) | User that is associated with the member object. |
| <a id="groupmemberuserpermissions"></a>`userPermissions` | [`GroupPermissions!`](#grouppermissions) | Permissions for the current user on the resource. |

2
doc/ci/directed_acyclic_graph/index.md
View File

@ -87,7 +87,7 @@ are certain use cases that you may need to work around. For more information, ch
The needs visualization makes it easier to visualize the relationships between dependent jobs in a DAG. This graph displays all the jobs in a pipeline that need or are needed by other jobs. Jobs with no relationships are not displayed in this view.
To see the needs visualization, click on the **Needs** tab when viewing a pipeline that uses the `needs` keyword.
To see the needs visualization, select **Needs** when viewing a pipeline that uses the `needs` keyword.
![Needs visualization example](img/dag_graph_example_v13_1.png)

6
doc/ci/variables/where_variables_can_be_used.md
View File

@ -30,12 +30,12 @@ There are two places defined variables can be used. On the:
| `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 | n/a | 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). |
| `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 | n/a | 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). |
| `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 | n/a | 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). |
| `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). |

2
doc/development/code_review.md
View File

@ -272,7 +272,7 @@ This saves reviewers time and helps authors catch mistakes earlier.
[Review the merge request](#reviewing-a-merge-request) thoroughly. When you are confident
that it meets all requirements, you should:
- Click the Approve button.
- Select **Approve**.
- `@` mention the author to generate a to-do notification, and advise them that their merge request has been reviewed and approved.
- Request a review from a maintainer. Default to requests for a maintainer with [domain expertise](#domain-experts),
however, if one isn't available or you think the merge request doesn't need a review by a [domain expert](#domain-experts), feel free to follow the [Reviewer roulette](#reviewer-roulette) suggestion.

4
doc/development/database_debugging.md
View File

@ -57,7 +57,7 @@ bundle exec rake db:reset RAILS_ENV=test
Access the database via one of these commands (they all get you to the same place)
```ruby
```shell
gdk psql -d gitlabhq_development
bundle exec rails dbconsole -e development
bundle exec rails db -e development
@ -72,7 +72,7 @@ bundle exec rails db -e development
## Access the database with a GUI
Most GUIs (DataGrid, RubyMine, DBeaver) require a TCP connection to the database, but by default
Most GUIs (DataGrip, RubyMine, DBeaver) require a TCP connection to the database, but by default
the database runs on a UNIX socket. To be able to access the database from these tools, some steps
are needed:

12
doc/development/documentation/testing.md
View File

@ -321,12 +321,12 @@ To match the versions of `markdownlint-cli` and `vale` used in the GitLab projec
[versions used (see `variables:` section)](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/.gitlab-ci.yml)
when building the `image:docs-lint-markdown` Docker image containing these tools for CI/CD.
| Tool | Version | Command | Additional information |
|--------------------|-----------|-------------------------------------------|------------------------|
| `markdownlint-cli` | Latest | `yarn global add markdownlint-cli` | n/a |
| `markdownlint-cli` | Specific | `yarn global add markdownlint-cli@0.23.2` | The `@` indicates a specific version, and this example updates the tool to version `0.23.2`. |
| Vale | Latest | `brew update && brew upgrade vale` | This command is for macOS only. |
| Vale | Specific | n/a | Not possible using `brew`, but can be [directly downloaded](https://github.com/errata-ai/vale/releases). |
| Tool | Version | Command | Additional information |
|--------------------|-----------|--------------------------------------------------------|------------------------|
| `markdownlint-cli` | Latest | `yarn global add markdownlint-cli` | None. |
| `markdownlint-cli` | Specific | `yarn global add markdownlint-cli@0.23.2` | The `@` indicates a specific version, and this example updates the tool to version `0.23.2`. |
| Vale | Latest | `brew update && brew upgrade vale` | This command is for macOS only. |
| Vale | Specific | Not applicable. | Binaries can be [directly downloaded](https://github.com/errata-ai/vale/releases). |
### Configure editors

4
doc/development/gemfile.md
View File

@ -138,8 +138,8 @@ To avoid upgrading indirect dependencies, we can use [`bundle update
When submitting a merge request including a dependency update,
include a link to the Gem diff between the 2 versions in the merge request
description. You can find this link on `rubygems.org` under
**Review Changes**. When you click it, RubyGems generates a comparison
description. You can find this link on `rubygems.org`, select
**Review Changes** to generate a comparison
between the versions on `diffend.io`. For example, this is the gem
diff for [`thor` 1.0.0 vs
1.0.1](https://my.diffend.io/gems/thor/1.0.0/1.0.1). Use the

4
doc/development/uploads/working_with_uploads.md
View File

@ -101,8 +101,8 @@ Therefore, document new uploads here by slotting them into the following tables:
| Pipeline artifacts | `carrierwave` | `sidekiq` | `/artifacts/<proj_id_hash>/pipelines/<pipeline_id>/artifacts/<artifact_id>` |
| Live job traces | `fog` | `sidekiq` | `/artifacts/tmp/builds/<job_id>/chunks/<chunk_index>.log` |
| Job traces archive | `carrierwave` | `sidekiq` | `/artifacts/<proj_id_hash>/<date>/<job_id>/<artifact_id>/job.log` |
| Autoscale runner caching | N/A | `gitlab-runner` | `/gitlab-com-[platform-]runners-cache/???` |
| Backups | N/A | `s3cmd`, `awscli`, or `gcs` | `/gitlab-backups/???` |
| Autoscale runner caching | Not applicable | `gitlab-runner` | `/gitlab-com-[platform-]runners-cache/???` |
| Backups | Not applicable | `s3cmd`, `awscli`, or `gcs` | `/gitlab-backups/???` |
| Git LFS | `direct upload` | `workhorse` | `/lfs-objects/<lfs_obj_oid[0:2]>/<lfs_obj_oid[2:2]>` |
| Design management files | `disk buffering` | `rails controller` | `/lsf-objects/<lfs_obj_oid[0:2]>/<lfs_obj_oid[2:2]>` |
| Design management thumbnails | `carrierwave` | `sidekiq` | `/uploads/design_management/action/image_v432x230/<model_id>/<original_lfs_obj_oid[2:2]` |

2
doc/install/aws/manual_install_aws.md
View File

@ -705,7 +705,7 @@ From the EC2 dashboard:
### Create an auto scaling group
1. As soon as the launch configuration is created, you'll see an option to **Create an Auto Scaling group using this launch configuration**. Click that to start creating the auto scaling group.
1. After the launch configuration is created, select **Create an Auto Scaling group using this launch configuration** to start creating the auto scaling group.
1. Enter a **Group name** (we'll use `gitlab-auto-scaling-group`).
1. For **Group size**, enter the number of instances you want to start with (we'll enter `2`).
1. Select the `gitlab-vpc` from the **Network** dropdown.

2
doc/install/google_cloud_platform/index.md
View File

@ -13,7 +13,7 @@ NOTE:
To deploy production-ready GitLab on
Google Kubernetes Engine,
you can follow Google Cloud Platform's
[Click to Deploy steps](https://github.com/GoogleCloudPlatform/click-to-deploy/blob/master/k8s/gitlab/README.md)
[`Click to Deploy` steps](https://github.com/GoogleCloudPlatform/click-to-deploy/blob/master/k8s/gitlab/README.md)
It's an alternative to using a GCP VM, and uses
the [Cloud native GitLab Helm chart](https://docs.gitlab.com/charts/).

2
doc/operations/metrics/alerts.md
View File

@ -36,7 +36,7 @@ Alerts can be used to trigger actions, like opening an issue automatically
1. Enable the option to create issues.
1. Choose the [issue template](../../user/project/description_templates.md) to create the issue from.
1. Optionally, select whether to send an email notification to the developers of the project.
1. Click **Save changes**.
1. Select **Save changes**.
After enabling, GitLab automatically opens an issue when an alert is triggered containing
values extracted from the [`alerts` field in webhook payload](https://prometheus.io/docs/alerting/latest/configuration/#webhook_config):

8
doc/operations/metrics/dashboards/develop.md
View File

@ -23,14 +23,14 @@ Navigate to the browser-based editor of your choice:
- In the **Repository view**:
1. Navigate to **{doc-text}** **Repository > Files**.
1. Click **{plus}** **Add to tree** and select **New file**,
then click **Select a template type** to see a list of available templates:
1. Select **{plus}** **Add to tree** and select **New file**,
then select **Select a template type** to see a list of available templates:
![Metrics dashboard template selection](img/metrics_dashboard_template_selection_v13_3.png)
- In the **[Web IDE](../../../user/project/web_ide/index.md)**:
1. Click **Web IDE** when viewing your repository.
1. Click **{doc-new}** **New file**, then click **Choose a template** to see a list of available templates:
1. Select **Web IDE** when viewing your repository.
1. Select **{doc-new}** **New file**, then select **Choose a template** to see a list of available templates:
![Metrics dashboard template selection WebIDE](img/metrics_dashboard_template_selection_web_ide_v13_3.png)
## Custom dashboard templates **(PREMIUM SELF)**

8
doc/operations/metrics/dashboards/settings.md
View File

@ -28,12 +28,12 @@ time zone:
1. Sign in as a user with Manage Project Operations [permissions](../../../user/permissions.md).
1. Navigate to **Settings > Monitor**.
1. Scroll to **Metrics Dashboard** and click **Expand**.
1. Scroll to **Metrics Dashboard** and select **Expand**.
1. In the **Dashboard timezone** select box, select *User's local timezone*
or *UTC*:
![Dashboard timezone setting](img/dashboard_local_timezone_v13_1.png)
1. Click **Save changes**.
1. Select **Save changes**.
## Link to an external dashboard
@ -44,12 +44,12 @@ existing external dashboards:
1. Sign in as a user with Manage Project Operations [permissions](../../../user/permissions.md).
1. Navigate to **Settings > Monitor**.
1. Scroll to **Metrics Dashboard** and click **Expand**.
1. Scroll to **Metrics Dashboard** and select **Expand**.
1. In **External dashboard URL**, provide the URL to your external dashboard:
![External Dashboard Setting](img/dashboard_external_link_v13_1.png)
1. Click **Save changes**.
1. Select **Save changes**.
GitLab displays a **View full dashboard** button in the top right corner of your
[monitoring dashboard](../../../ci/environments/index.md#monitor-environments)

4
doc/operations/metrics/embed.md
View File

@ -48,8 +48,8 @@ GitLab unfurls the link as an embedded metrics panel:
![Embedded Metrics Rendered](img/embedded_metrics_rendered_v13_4.png)
You can also embed a single chart. To get a link to a chart, click the
**{ellipsis_v}** **More actions** menu in the upper right corner of the chart,
You can also embed a single chart. To get a link to a chart, select
**{ellipsis_v}** **More actions** in the upper right corner of the chart,
and select **Copy link to chart**, as shown in this example:
![Copy Link To Chart](img/copy_link_to_chart_v12_10.png)

2
doc/operations/metrics/index.md
View File

@ -87,7 +87,7 @@ navigation bar contains:
[custom dashboards](dashboards/index.md).
([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/34779) in GitLab 12.5.)
- **Duplicate current dashboard** - Save a [complete copy of a dashboard](dashboards/index.md#duplicate-a-gitlab-defined-dashboard). Only available on GitLab-defined dashboards.
- **Star dashboard** **{star-o}** - Click to mark a dashboard as a favorite.
- **Star dashboard** **{star-o}** - Mark a dashboard as a favorite.
Starred dashboards display a solid star **{star}** button, and display first
in the **Dashboard** dropdown list.
([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214582) in GitLab 13.0.)

6
doc/subscriptions/index.md
View File

@ -53,8 +53,8 @@ at each tier for each product, see:
## Find your subscription
The following chart should help you determine your subscription model. Click
on the list item to go to the respective help page.
The following chart should help you determine your subscription model. Select
the list item to go to the respective help page.
```mermaid
graph TD
@ -164,7 +164,7 @@ Only one namespace can be linked to a subscription.
To change the password for this customers portal account:
1. Log in to the [Customers Portal](https://customers.gitlab.com/customers/sign_in).
1. Select the **My account** drop-down and select on **Account details**.
1. Select the **My account** drop-down and select **Account details**.
1. Make the required changes to the **Your password** section.
1. Select **Save changes**.

17
doc/update/deprecations.md
View File

@ -1565,23 +1565,6 @@ In GitLab 15.0 and later, the default value for this configuration option will c
**Planned removal milestone: <span class="removal-milestone">15.0</span> (2022-05-22)**
</div>
<div class="deprecation removal-150 breaking-change">
### Must explicitly assign `AuthenticationType` for `[runners.cache.s3]`
WARNING:
This feature will be changed or removed in 15.0
as a [breaking change](https://docs.gitlab.com/ee/development/contributing/#breaking-changes).
Before updating GitLab, review the details carefully to determine if you need to make any
changes to your code, settings, or workflow.
In GitLab 15.0 and later, to access the AWS S3 cache, you must specify the `AuthenticationType` for [`[runners.cache.s3]`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerscaches3-section). The `AuthenticationType` must be `IAM` or `credentials`.
Prior to 14.5, if you did not define the `AuthenticationType`, GitLab Runner chose a type for you.
**Planned removal milestone: <span class="removal-milestone">15.0</span> (2022-05-22)**
</div>
<div class="deprecation removal-160 breaking-change">
### Package pipelines in API payload is paginated

2
doc/user/application_security/container_scanning/index.md
View File

@ -260,7 +260,7 @@ Support depends on which scanner is used:
| Distribution | Grype | Trivy |
| -------------- | ----- | ----- |
| Alma Linux | | ✅ |
| Alpine Linux | ✅ | |
| Alpine Linux | ✅ | ✅ |
| Amazon Linux | ✅ | ✅ |
| BusyBox | ✅ | |
| CentOS | ✅ | ✅ |

5
doc/user/application_security/policies/scan-execution-policies.md
View File

@ -86,9 +86,8 @@ This rule enforces the defined actions and schedules a scan on the provided date
| `type` | `string` | `schedule` | The rule's type. |
| `branches` | `array` of `string` | `*` or the branch's name | The branch the given policy applies to (supports wildcard). |
| `cadence` | `string` | CRON expression (for example, `0 0 * * *`) | A whitespace-separated string containing five fields that represents the scheduled time. |
| `agents` | `object` | | The name of the [GitLab agents](../../clusters/agent/index.md) where [cluster image scanning](../../clusters/agent/vulnerabilities.md) will run. The key of the object is the name of the Kubernetes cluster configured for your project in GitLab. In the optionally provided value of the object, you can precisely select Kubernetes resources that are scanned. | <!--- start_remove The following content will be removed on remove_date: '2022-08-22' -->
| `clusters` (removed) | `object` | | This field was [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/356465) in 15.0. Use the `agents` field instead. The cluster where the given policy enforces running selected scans (only for `container_scanning`/`cluster_image_scanning` scans). The key of the object is the name of the Kubernetes cluster configured for your project in GitLab. In the optionally provided value of the object, you can precisely select Kubernetes resources that are scanned. |
<!--- end_remove -->
| `agents` | `object` | | The name of the [GitLab agents](../../clusters/agent/index.md) where [cluster image scanning](../../clusters/agent/vulnerabilities.md) will run. The key of the object is the name of the Kubernetes cluster configured for your project in GitLab. In the optionally provided value of the object, you can precisely select Kubernetes resources that are scanned. <!--- start_remove The following content will be removed on remove_date: '2022-08-22' --> |
| `clusters` (removed) | `object` | | This field was [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/356465) in 15.0. Use the `agents` field instead. The cluster where the given policy enforces running selected scans (only for `container_scanning`/`cluster_image_scanning` scans). The key of the object is the name of the Kubernetes cluster configured for your project in GitLab. In the optionally provided value of the object, you can precisely select Kubernetes resources that are scanned. <!--- end_remove --> |
GitLab supports the following types of CRON syntax for the `cadence` field:

112
doc/user/application_security/vulnerabilities/index.md
View File

@ -4,13 +4,14 @@ group: Threat Insights
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
---
# Vulnerability Pages **(ULTIMATE)**
# Vulnerability Page **(ULTIMATE)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13561) in GitLab 13.0.
Each vulnerability in a project has a Vulnerability Page. This page contains details of the
vulnerability. The details included vary according to the type of vulnerability. Details of each
vulnerability include:
Each vulnerability in a project has a Vulnerability Page, containing details of the
vulnerability. The details included vary according to the type of vulnerability.
Details of each vulnerability include:
- Description
- When it was detected
@ -24,32 +25,41 @@ alert message is included at the top of the vulnerability's page.
On the vulnerability's page, you can:
- [Change the vulnerability's status](#change-vulnerability-status).
- [Create an issue](#create-an-issue-for-a-vulnerability).
- [Link issues to the vulnerability](#linked-issues).
- [Resolve a vulnerability](#resolve-a-vulnerability) if a solution is
- [Change the vulnerability's status](#change-status-of-a-vulnerability).
- [Create an issue](#creating-an-issue-for-a-vulnerability).
- [Link issues to the vulnerability](#linking-a-vulnerability-to-issues).
- [Resolve the vulnerability](#resolve-a-vulnerability) if a solution is
available.
- [View security training specific to the detected vulnerability](#view-security-training-for-a-vulnerability).
## Vulnerability status values
A vulnerability's status can be one of the following:
A vulnerability's status can be:
| Status | Description |
|:----------|:------------|
| Detected | The default state for a newly discovered vulnerability. Appears as "Needs triage" in the UI. |
| Confirmed | A user has seen this vulnerability and confirmed it to be accurate. |
| Dismissed | A user has seen this vulnerability and dismissed it because it is not accurate or otherwise not to be resolved. |
| Resolved | The vulnerability has been fixed or is no longer present. |
- **Detected**: The default state for a newly discovered vulnerability. Appears as "Needs triage" in the UI.
- **Confirmed**: A user has seen this vulnerability and confirmed it to be accurate.
- **Dismissed**: A user has seen this vulnerability and dismissed it because it is not accurate or otherwise not to be resolved.
- **Resolved**: The vulnerability has been fixed or is no longer present.
Dismissed vulnerabilities are ignored if detected in subsequent scans. Resolved vulnerabilities that are reintroduced and detected by subsequent scans have a _new_ vulnerability record created. When an existing vulnerability is no longer detected in a project's `default` branch, you should change its status to Resolved. This ensures that if it is accidentally reintroduced in a future merge, it will be visible again as a new record. You can use the [Activity filter](../vulnerability_report/#activity-filter) to select all vulnerabilities that are no longer detected, and [change their status](../vulnerability_report#change-status-of-vulnerabilities).
Dismissed vulnerabilities are ignored if detected in subsequent scans. Resolved vulnerabilities that
are reintroduced and detected by subsequent scans have a _new_ vulnerability record created. When an
existing vulnerability is no longer detected in a project's `default` branch, you should change its
status to **Resolved**. This ensures that if it is accidentally reintroduced in a future merge, it
is reported again as a new record. You can use the Vulnerability Report's
[Activity filter](../vulnerability_report/#activity-filter) to select all vulnerabilities that are
no longer detected, and change their status.
## Change vulnerability status
## Change status of a vulnerability
To change a vulnerability's status, select a new value from the **Status** dropdown then select
**Change status**. Optionally, add a comment to the log entry at the bottom of the page.
To change a vulnerability's status from its Vulnerability Page:
## Create an issue for a vulnerability
1. On the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Security & Compliance > Vulnerability report**.
1. Select the vulnerability's description.
1. From the **Status** dropdown list select a status, then select **Change status**.
1. Optionally, at the bottom of the page, add a comment to the log entry.
## Creating an issue for a vulnerability
From a vulnerability's page you can create an issue to track all action taken to resolve or
mitigate it.
@ -67,7 +77,9 @@ that when Jira integration is enabled, the GitLab issue feature is not available
To create a GitLab issue for a vulnerability:
1. In GitLab, go to the vulnerability's page.
1. On the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Security & Compliance > Vulnerability report**.
1. Select the vulnerability's description.
1. Select **Create issue**.
An issue is created in the project, pre-populated with information from the vulnerability report.
@ -80,73 +92,85 @@ The issue is then opened so you can take further action.
Prerequisites:
- [Enable Jira integration](../../../integration/jira/index.md).
The **Enable Jira issue creation from vulnerabilities** option must be selected as part of the configuration.
- Each user must have a personal Jira user account with permission to create issues in the target project.
- [Enable Jira integration](../../../integration/jira/index.md). The **Enable Jira issue creation
from vulnerabilities** option must be selected as part of the configuration.
- Each user must have a personal Jira user account with permission to create issues in the target
project.
To create a Jira issue for a vulnerability:
1. Go to the vulnerability's page.
1. On the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Security & Compliance > Vulnerability report**.
1. Select the vulnerability's description.
1. Select **Create Jira issue**.
1. If you're not already logged in to Jira, log in.
The Jira issue is created and opened in a new browser tab. The **Summary** and **Description**
fields are pre-populated from the vulnerability's details.
Unlike GitLab issues, the status of whether a Jira issue is open or closed does not display in the GitLab user interface.
Unlike GitLab issues, the status of whether a Jira issue is open or closed does not display in the
GitLab user interface.
## Linked issues
## Linking a vulnerability to issues
NOTE:
If Jira issue support is enabled, GitLab issues are disabled so this feature is not available.
You can link one or more existing GitLab issues to a vulnerability. Adding a link helps track
You can link a vulnerability to one or more existing GitLab issues. Adding a link helps track
the issue that resolves or mitigates a vulnerability.
Issues linked to a vulnerability are shown in the Vulnerability Report and the vulnerability's page.
Be aware of the following conditions between a vulnerability and a linked issue:
- The vulnerability page shows related issues, but the issue page doesn't show the vulnerability it's related to.
- The vulnerability page shows related issues, but the issue page doesn't show the vulnerability
it's related to.
- An issue can only be related to one vulnerability at a time.
- Issues can be linked across groups and projects.
## Link to existing issues
## Link a vulnerability to existing issues
To link a vulnerability to existing issues:
1. Go to the vulnerability's page.
1. On the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Security & Compliance > Vulnerability report**.
1. Select the vulnerability's description.
1. In the **Linked issues** section, select the plus icon (**{plus}**).
1. For each issue to be linked, either:
- Paste a link to the issue.
- Enter the issue's ID (prefixed with a hash `#`).
1. Select **Add**.
The selected issues are added to the **Linked issues** section, and the linked issues counter is updated.
The selected issues are added to the **Linked issues** section, and the linked issues counter is
updated.
## Resolve a vulnerability
For some vulnerabilities a solution is already known. In those instances, a vulnerability's page
includes a **Resolve with merge request** option.
To resolve a vulnerability, you can either:
- [Resolve a vulnerability with a merge request](#resolve-a-vulnerability-with-a-merge-request).
- [Resolve a vulnerability manually](#resolve-a-vulnerability-manually).
The following scanners are supported:
The following scanners are supported by this feature:
- [Dependency Scanning](../dependency_scanning/index.md).
Automatic Patch creation is only available for Node.js projects managed with
`yarn`.
- [Container Scanning](../container_scanning/index.md).
To resolve a vulnerability, you can either:
- [Resolve a vulnerability with a merge request](#resolve-a-vulnerability-with-a-merge-request).
- [Resolve a vulnerability manually](#resolve-a-vulnerability-manually).
![Create merge request from vulnerability](img/create_mr_from_vulnerability_v13_4.png)
### Resolve a vulnerability with a merge request
To resolve the vulnerability with a merge request, go to the vulnerability's page and from the
**Resolve with merge request** dropdown select **Resolve with merge request**.
To resolve the vulnerability with a merge request:
1. On the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Security & Compliance > Vulnerability report**.
1. Select the vulnerability's description.
1. From the **Resolve with merge request** dropdown list, select **Resolve with merge request**.
A merge request is created which applies the patch required to resolve the vulnerability.
Process the merge request according to your standard workflow.
@ -155,11 +179,15 @@ Process the merge request according to your standard workflow.
To manually apply the patch that GitLab generated for a vulnerability:
1. Go to the vulnerability's page and from the **Resolve with merge request** dropdown select
**Download patch to resolve**.
1. On the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Security & Compliance > Vulnerability report**.
1. Select the vulnerability's description.
1. From the **Resolve with merge request** dropdown list, select **Download patch to resolve**.
1. Ensure your local project has the same commit checked out that was used to generate the patch.
1. Run `git apply remediation.patch`.
1. Verify and commit the changes to your branch.
1. Create a merge request to apply the changes to your main branch.
1. Process the merge request according to your standard workflow.
## Enable security training for vulnerabilities

2
doc/user/application_security/vulnerability_report/index.md
View File

@ -23,7 +23,7 @@ The **Activity** column contains icons to indicate the activity, if any, taken o
in that row:
- Issues **{issues}**: Links to issues created for the vulnerability. For more details, read
[Create an issue for a vulnerability](../vulnerabilities/index.md#create-an-issue-for-a-vulnerability).
[Create an issue for a vulnerability](../vulnerabilities/index.md#creating-an-issue-for-a-vulnerability).
- Wrench **{admin}**: The vulnerability has been remediated.
- False positive **{false-positive}**: The scanner determined this vulnerability to be a false
positive.

1
doc/user/clusters/agent/index.md
View File

@ -70,4 +70,5 @@ Read about how to [migrate to the agent for Kubernetes](../../infrastructure/clu
- [Install the agent](install/index.md)
- [Work with the agent](repository.md)
- [Troubleshooting](troubleshooting.md)
- [Guided explorations for a production ready GitOps setup](https://gitlab.com/groups/guided-explorations/gl-k8s-agent/gitops/-/wikis/home#gitlab-agent-for-kubernetes-gitops-working-examples)
- [Contribute to the agent's development](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/tree/master/doc)

BIN
doc/user/infrastructure/clusters/connect/img/variables_civo.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 73 KiB

137
doc/user/infrastructure/clusters/connect/new_civo_cluster.md Normal file
View File

@ -0,0 +1,137 @@
---
stage: Configure
group: Configure
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
---
# Create a Civo Kubernetes cluster
Every new Civo account receives [$250 in credit](https://civo.com/signup) to get started with the GitLab integration with Civo Kubernetes. You can also use a marketplace app to install GitLab on your Civo Kubernetes cluster.
Learn how to create a new cluster on Civo Kubernetes through
[Infrastructure as Code (IaC)](../../index.md). This process uses the Civo
and Kubernetes Terraform providers to create Civo Kubernetes clusters. You connect the clusters to GitLab
by using the GitLab agent for Kubernetes.
**Prerequisites:**
- A [Civo account](https://civo.com/signup).
- [A runner](https://docs.gitlab.com/runner/install/) you can use to run the GitLab CI/CD pipeline.
**Steps:**
1. [Import the example project](#import-the-example-project).
1. [Register the agent for Kubernetes](#register-the-agent).
1. [Configure your project](#configure-your-project).
1. [Provision your cluster](#provision-your-cluster).
## Import the example project
To create a cluster from GitLab using Infrastructure as Code, you must
create a project to manage the cluster from. In this tutorial, you start with
a sample project and modify it according to your needs.
Start by [importing the example project by URL](../../../project/import/repo_by_url.md).
To import the project:
1. On the top bar, select **Menu > Create new project**.
1. Select **Import project**.
1. Select **Repo by URL**.
1. For the **Git repository URL**, enter `https://gitlab.com/civocloud/gitlab-terraform-civo.git`.
1. Complete the fields and select **Create project**.
This project provides you with:
- A [cluster on Civo](https://gitlab.com/civocloud/gitlab-terraform-civo/-/blob/master/civo.tf) with defaults for name, region, node count, and Kubernetes version.
- The [GitLab agent for Kubernetes](https://gitlab.com/civocloud/gitlab-terraform-civo/-/blob/master/agent.tf) installed in the cluster.
## Register the agent
To create a GitLab agent for Kubernetes:
1. On the left sidebar, select **Infrastructure > Kubernetes clusters**.
1. Select **Connect a cluster (agent)**.
1. From the **Select an agent** dropdown list, select `civo-agent` and select **Register an agent**.
1. GitLab generates a registration token for the agent. Securely store this secret token, as you will need it later.
1. GitLab provides an address for the agent server (KAS), which you will also need later.
## Configure your project
Use CI/CD environment variables to configure your project.
**Required configuration:**
1. On the left sidebar, select **Settings > CI/CD**.
1. Expand **Variables**.
1. Set the variable `BASE64_CIVO_CREDENTIALS` to the [token](https://www.civo.com/account/security) from your Civo account.
1. Set the variable `TF_VAR_agent_token` to the agent token you received in the previous task.
1. Set the variable `TF_VAR_kas_address` to the agent server address in the previous task.
![img/variables_civo.png](img/variables_civo.png)
**Optional configuration:**
The file [`variables.tf`](https://gitlab.com/civocloud/gitlab-terraform-civo/-/blob/master/variables.tf)
contains other variables that you can override according to your needs:
- `TF_VAR_civo_region`: Set your cluster's region.
- `TF_VAR_cluster_name`: Set your cluster's name.
- `TF_VAR_cluster_description`: Set a description for the cluster. To create a reference to your GitLab project on your Civo cluster detail page, set this value to `$CI_PROJECT_URL`. This value helps you determine which project was responsible for provisioning the cluster you see on the Civo dashboard.
- `TF_VAR_machine_type`: Set the machine type for the Kubernetes nodes.
- `TF_VAR_node_count`: Set the number of Kubernetes nodes.
- `TF_VAR_agent_version`: Set the version of the GitLab agent.
- `TF_VAR_agent_namespace`: Set the Kubernetes namespace for the GitLab agent.
Refer to the [Civo Terraform provider](https://registry.terraform.io/providers/civo/civo/latest/docs/resources/kubernetes_cluster) and the [Kubernetes Terraform provider](https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs) documentation for further resource options.
## Provision your cluster
After configuring your project, manually trigger the provisioning of your cluster. In GitLab:
1. On the left sidebar, go to **CI/CD > Pipelines**.
1. Next to **Play** (**{play}**), select the dropdown icon (**{angle-down}**).
1. Select **Deploy** to manually trigger the deployment job.
When the pipeline finishes successfully, you can see your new cluster:
- In Civo dashboard: on your [Kubernetes tab](https://www.civo.com/account/kubernetes).
- In GitLab: from your project's sidebar, select **Infrastructure > Kubernetes clusters**.
## Use your cluster
After you provision the cluster, it is connected to GitLab and is ready for deployments. To check the connection:
1. On the left sidebar, select **Infrastructure > Kubernetes clusters**.
1. In the list, view the **Connection status** column.
For more information about the capabilities of the connection, see [the GitLab agent for Kubernetes documentation](../index.md).
## Remove the cluster
A cleanup job is not included in your pipeline by default. To remove all created resources, you
must modify your GitLab CI/CD template before running the cleanup job.
To remove all resources:
1. Add the following to your `.gitlab-ci.yml` file:
```yaml
stages:
- init
- validate
- build
- deploy
- cleanup
destroy:
extends: .destroy
needs: []
```
1. On the left sidebar, select **CI/CD > Pipelines** and select the most recent pipeline.
1. For the `destroy` job, select **Play** (**{play}**).
## Civo support
This Civo integration is supported by Civo. Send your support requests to [Civo support](https://www.civo.com/contact).

4
doc/user/project/merge_requests/approvals/rules.md
View File

@ -250,6 +250,10 @@ For more information about this validation error, read
You can use [scan result policies](../../../application_security/policies/scan-result-policies.md#scan-result-policy-editor) to define security approvals based on the status of vulnerabilities in the merge request and the default branch.
Details for each security policy is shown in the Security Approvals section of your Merge Request configuration.
The security approval rules are applied to all merge requests until the pipeline is complete. The application of the
security approval rules prevents users from merging in code before the security scans run. Once the pipeline is
complete, the security approval rules are checked to determine if the security approvals are still required.
![Security Approvals](img/security_approvals_v15_0.png)
These policies are both created and edited in the [security policy editor](../../../application_security/policies/index.md#policy-editor).

5
doc/user/project/merge_requests/test_coverage_visualization.md
View File

@ -68,6 +68,11 @@ A single Cobertura XML file can be no more than 10MiB. For large projects, split
smaller files. See [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/328772) for more details.
When submitting many files, it can take a few minutes for coverage to show on a merge request.
The visualization only displays after the pipeline is complete. If the pipeline has
a [blocking manual job](../../../ci/jobs/job_control.md#types-of-manual-jobs), the
pipeline waits for the manual job before continuing and is not considered complete.
The visualization cannot be displayed if the blocking manual job did not run.
### Artifact expiration
By default, the [pipeline artifact](../../../ci/pipelines/pipeline_artifacts.md#storage) used

3
locale/gitlab.pot
View File

@ -33822,9 +33822,6 @@ msgstr ""
msgid "SecurityOrchestration|Policy definition"
msgstr ""
msgid "SecurityOrchestration|Policy description"
msgstr ""
msgid "SecurityOrchestration|Policy editor"
msgstr ""

31
spec/initializers/omniauth_spec.rb
View File

@ -3,7 +3,7 @@
require 'spec_helper'
RSpec.describe 'OmniAuth initializer for GitLab' do
let(:load_omniauth_initializer) do
def load_omniauth_initializer
load Rails.root.join('config/initializers/omniauth.rb')
end
@ -15,32 +15,15 @@ RSpec.describe 'OmniAuth initializer for GitLab' do
before do
allow(Settings).to receive(:gitlab).and_return({ 'base_url' => base_url })
allow(Gitlab::OmniauthInitializer).to receive(:full_host).and_return('proc')
load_omniauth_initializer
end
context 'with feature flags not available' do
before do
expect(Feature).to receive(:feature_flags_available?).and_return(false)
load_omniauth_initializer
end
it { is_expected.to eq(base_url) }
# to clear existing mocks and prevent order-dependent failures
after(:all) do
load_omniauth_initializer
end
context 'with the omniauth_initializer_fullhost_proc FF disabled' do
before do
stub_feature_flags(omniauth_initializer_fullhost_proc: false)
load_omniauth_initializer
end
it { is_expected.to eq(base_url) }
end
context 'with the omniauth_initializer_fullhost_proc FF disabled' do
before do
load_omniauth_initializer
end
it { is_expected.to eq('proc') }
end
it { is_expected.to eq('proc') }
end
end