VladPolskiy/gitlab-foss
1
0
Fork 0
mirror of https://gitlab.com/gitlab-org/gitlab-foss.git synced 2025-08-15 21:39:00 +00:00
Code Issues Packages Projects Releases 1 Wiki Activity

Add latest changes from gitlab-org/gitlab@master

Browse Source
This commit is contained in:
GitLab Bot
2024-07-04 03:21:22 +00:00
parent 9aa21d51a5
commit 1f0568c2a9
21 changed files with 237 additions and 206 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
app/services/users/build_service.rb
View File

@ -143,8 +143,6 @@ module Users
end
def build_user_detail
return unless Feature.enabled?(:create_user_details_all_user_creation, Feature.current_request)
# This will ensure we either load an existing record or create it.
user.user_detail
end

12
app/services/users/registrations_build_service.rb
View File

@ -6,18 +6,6 @@ module Users
private
override :build_user_detail
def build_user_detail
# This will ensure we either load an existing record or create it.
# TODO: Eventually we should specifically build here once we get away from the lazy loading in
# https://gitlab.com/gitlab-org/gitlab/-/issues/462919.
if Feature.enabled?(:create_user_details_all_user_creation, Feature.current_request)
super
else
user.user_detail
end
end
def signup_params
super + [:skip_confirmation]
end

9
config/feature_flags/gitlab_com_derisk/create_user_details_all_user_creation.yml
View File

@ -1,9 +0,0 @@
---
name: create_user_details_all_user_creation
feature_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/462909
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/155991
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/466709
milestone: '17.1'
group: group::acquisition
type: gitlab_com_derisk
default_enabled: false

4
doc/administration/job_artifacts_troubleshooting.md
View File

@ -252,6 +252,8 @@ These commands remove data permanently from database and storage. Before running
#### Delete old artifacts for a project
This step also erases artifacts that users have [chosen to keep](../ci/jobs/job_artifacts.md#with-an-expiry):
```ruby
project = Project.find_by_full_path('path/to/project')
builds_with_artifacts = project.builds.with_downloadable_artifacts
@ -279,6 +281,8 @@ end
#### Delete old artifacts instance wide
This step also erases artifacts that users have [chosen to keep](../ci/jobs/job_artifacts.md#with-an-expiry):
```ruby
builds_with_artifacts = Ci::Build.with_downloadable_artifacts
builds_with_artifacts.where("finished_at < ?", 1.year.ago).each_batch do |batch|

2
doc/architecture/blueprints/clickhouse_usage/index.md
View File

@ -47,7 +47,7 @@ In FY24 Q2 we began working to integrate ClickHouse with GitLab.com to support m
#### FY25 H1 (current)
After we have formulated best practices of managing ClickHouse ourselves for GitLab.com, we will begin to offer supported recommendations for self-managed instances that want to run ClickHouse themselves. During this phase we will allow users to "Bring your own ClickHouse" similar to our [approach for Elasticsearch](../../../integration/advanced_search/elasticsearch.md#install-elasticsearch). For the features that require ClickHouse for optimal usage (Value Streams Dashboard, [Product Analytics](https://gitlab.com/groups/gitlab-org/-/epics/8921)), this will be the initial go-to-market action. Notably, the Observability team has made the decision to support self-managed users via GitLab Cloud Connector instead of following this approach.
After we have formulated best practices of managing ClickHouse ourselves for GitLab.com, we will begin to offer supported recommendations for self-managed instances that want to run ClickHouse themselves. During this phase we will allow users to "Bring your own ClickHouse" similar to our [approach for Elasticsearch](../../../integration/advanced_search/elasticsearch.md#install-elasticsearch-or-aws-opensearch-cluster). For the features that require ClickHouse for optimal usage (Value Streams Dashboard, [Product Analytics](https://gitlab.com/groups/gitlab-org/-/epics/8921)), this will be the initial go-to-market action. Notably, the Observability team has made the decision to support self-managed users via GitLab Cloud Connector instead of following this approach.
#### Long-term

2
doc/architecture/blueprints/gitlab_rag/elasticsearch.md
View File

@ -89,7 +89,7 @@ Elasticsearch currently supports [Reciprocal rank fusion (RRF)](https://www.elas
Elasticsearch is available on GitLab.com and can be integrated on Dedicated and Self-Managed instances. To use as a vector store only:
- [Install Elasticsearch version `8.12`](../../../integration/advanced_search/elasticsearch.md#install-elasticsearch) or upgrade to at least version `8.12`.
- [Install Elasticsearch version `8.12`](../../../integration/advanced_search/elasticsearch.md#install-elasticsearch-or-aws-opensearch-cluster) or upgrade to at least version `8.12`.
- Add URL, Username and Password on the Advanced Search settings page: `admin/application_settings/advanced_search`
After the integration is configured, instance admins don't need to do further work to use it as a vector store since the GitLab Elasticsearch framework handles setting mappings, settings and indexing data.

2
doc/development/adding_service_component.md
View File

@ -48,7 +48,7 @@ In addition, it needs to cover the following:
The first iteration should be to add the ability to connect and use the service as an externally installed component. Often this involves providing settings in GitLab to connect to the service, or allow connections from it. And then shipping documentation on how to install and configure the service with GitLab.
[Elasticsearch](../integration/advanced_search/elasticsearch.md#install-elasticsearch) is an example of a service that has been integrated this way. Many of the other services, including internal projects like Gitaly, started off as separately installed alternatives.
[Elasticsearch](../integration/advanced_search/elasticsearch.md#install-elasticsearch-or-aws-opensearch-cluster) is an example of a service that has been integrated this way. Many of the other services, including internal projects like Gitaly, started off as separately installed alternatives.
**For services that depend on the existing GitLab codebase:**

11
doc/gitlab-basics/add-file.md
View File

@ -270,7 +270,16 @@ You can use push options to skip [secret push protection](../user/application_se
| Push option | Description | Example |
|--------------------------------|-------------|---------|
| `secret_detection.skip_all` | Do not perform secret push protection for any commit in this push. | `git push -o secret_detection.skip_all` |
| `secret_push_protection.skip_all` | Do not perform secret push protection for any commit in this push. | `git push -o secret_push_protection.skip_all` |
### Push options for GitGuardian integration
You can use the same [push option for Secret push protection](#push-options-for-secret-push-protection) to skip GitGuardian secret detection.
| Push option | Description | Example |
|--------------------------------|-------------|---------|
| `secret_detection.skip_all` | Deprecated in GitLab 17.2. Use `secret_push_protection.skip_all` instead. | `git push -o secret_detection.skip_all` |
| `secret_push_protection.skip_all` | Do not perform GitGuardian secret detection. | `git push -o secret_push_protection.skip_all` |
### Formats for push options

268
doc/integration/advanced_search/elasticsearch.md
View File

@ -50,27 +50,174 @@ Elasticsearch requires additional resources to those documented in the
Memory, CPU, and storage resource amounts vary depending on the amount of data you index into the Elasticsearch cluster. Heavily used Elasticsearch clusters may require more resources. The [`estimate_cluster_size`](#gitlab-advanced-search-rake-tasks) Rake task uses the total repository size to estimate the advanced search storage requirements.
## Install Elasticsearch
## Install Elasticsearch or AWS OpenSearch cluster
Elasticsearch is *not* included in the Linux package or when you self-compile your installation.
You must [install it separately](https://www.elastic.co/guide/en/elasticsearch/reference/7.16/install-elasticsearch.html "Elasticsearch 7.x installation documentation") and ensure you select your version. Detailed information on how to install Elasticsearch is out of the scope of this page.
Elasticsearch and AWS OpenSearch are **not** included in the Linux package or when you perform a direct package installation. Detailed information on how to install Elasticsearch is out of the scope of this page.
You can install Elasticsearch yourself, or use a cloud hosted offering such as [Elasticsearch Service](https://www.elastic.co/elasticsearch/service) (available on AWS, GCP, or Azure) or the [Amazon OpenSearch](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/gsg.html)
You can install a search cluster yourself, or use a cloud hosted offering such as [Elasticsearch Service](https://www.elastic.co/elasticsearch/service) (available on AWS, GCP, or Azure) or the [Amazon OpenSearch](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/gsg.html)
service.
You should install Elasticsearch on a separate server. Running Elasticsearch on the same server as GitLab is not recommended and can cause a degradation in GitLab instance performance.
You should install the search cluster on a separate server. Running the search cluster on the same server as GitLab is not recommended and can cause a degradation in GitLab instance performance.
For a single node Elasticsearch cluster, the functional cluster health status is always yellow due to the allocation of the primary shard. Elasticsearch cannot assign replica shards to the same node as primary shards.
For a single node search cluster, the functional cluster health status is always yellow due to the allocation of the primary shard. The cluster cannot assign replica shards to the same node as primary shards.
The search index updates after you:
- Add data to the database or repository.
- [Enable Elasticsearch](#enable-advanced-search) in the Admin Area.
- [Enable advanced search](#enable-advanced-search) in the Admin Area.
NOTE:
Before you use a new Elasticsearch cluster in production, see the
[Elasticsearch documentation on important settings](https://www.elastic.co/guide/en/elasticsearch/reference/current/important-settings.html).
### Elasticsearch access control configuration
Elasticsearch offers role based access control to secure the cluster. To access and perform operations in the
Elasticsearch cluster, the `Username` configured in the Admin UI must have role(s) assigned that grant the following
privileges. The `Username` makes requests from GitLab to the search cluster.
For more information,
see [Elasticsearch role based access control](https://www.elastic.co/guide/en/elasticsearch/reference/current/authorization.html#roles)
and [Elasticsearch security privileges](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-privileges.html).
```json
{
"cluster": ["monitor"],
"indices": [
{
"names": ["gitlab-*"],
"privileges": [
"create_index",
"delete_index",
"view_index_metadata",
"read",
"manage",
"write"
]
}
]
}
```
### AWS OpenSearch service configuration
AWS OpenSearch offers multiple methods of access control which are supported by GitLab:
- [Domain level access policy](#domain-level-access-policy-configuration)
- Fine-grained access control
- [With IAM ARN as master user](#connecting-with-an-iam-user)
- [With master user](#connecting-with-a-master-user-in-the-internal-database)
For more details on fine-grained access control see
[recommended configurations](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac.html#fgac-recommendations)
#### Domain level access policy configuration
Configure the AWS OpenSearch domain access policy to allow `es:ESHttp*` actions. You can customize
the following example configuration to limit principals or resources:
NOTE:
All `es:ESHttp` actions are required by GitLab.
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"*"
]
},
"Action": [
"es:ESHttp*"
],
"Resource": "arn:aws:es:REGION:AWS_ACCOUNT_ID:domain/DOMAIN_NAME/*"
}
]
}
```
For more information,
see [Identity and Access Management in Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ac.html).
##### Service linked role configuration
The GitLab Rails and Sidekiq nodes require permissions to communicate with the search cluster.
Create an IAM role with the following options and attach the role to the GitLab Rails and Sidekiq nodes:
- Trusted entity type: `AWS Service` for `EC2` service
- Permission policy: `AmazonOpenSearchServiceFullAccess`
##### Connecting with a domain level access policy only
When using a domain level access policy, you must check the box **Use AWS OpenSearch Service with IAM credentials** and
fill in **AWS region** while leaving **AWS Access Key** and **AWS Secret Access Key** blank in the advanced search settings.
NOTE:
Domain level access policy can be used standalone or in addition to fine-grained access control policies.
#### Fine-grained access control configuration
To access and perform operations in the AWS OpenSearch cluster, the user in **Username** must have role(s) assigned that
grant the following privileges. This user makes requests from GitLab to the search cluster.
For more information,
see [OpenSearch access control permissions](https://opensearch.org/docs/latest/security/access-control/permissions/)
and [Creating roles](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac.html#fgac-roles).
NOTE:
The index pattern `*` requires a few permissions for Advanced search to work.
```json
{
"cluster_permissions": [
"cluster_composite_ops",
"cluster_monitor"
],
"index_permissions": [
{
"index_patterns": [
"gitlab*"
],
"allowed_actions": [
"data_access",
"manage_aliases",
"search",
"create_index",
"delete",
"manage"
]
},
{
"index_patterns": [
"*"
],
"allowed_actions": [
"indices:admin/aliases/get",
"indices:monitor/stats"
]
}
]
}
```
##### Connecting with a master user in the internal database
When using fine-grained access control with a user in the internal database, you should use HTTP basic
authentication to connect to AWS OpenSearch. You can provide the master username and password as part of the
AWS OpenSearch URL or in the **Username** and **Password** text boxes in the advanced search settings. See
[Tutorial: Internal user database and HTTP basic authentication](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac-walkthrough-basic.html)
for details.
##### Connecting with an IAM user
When using fine-grained access control with IAM credentials, you must check the box **Use AWS OpenSearch Service with
IAM credentials** in the **AWS OpenSearch IAM credentials** section in the advanced search settings.
Provide the **AWS region**, **AWS Access Key**, and **AWS Secret Access Key**.
## Upgrade to a new Elasticsearch major version
> - Support for Elasticsearch 6.8 [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/350275) in GitLab 15.0.
@ -282,113 +429,6 @@ Sidekiq performance. Return them to their default values if you see increased `s
in your Sidekiq logs. For more information, see
[issue 322147](https://gitlab.com/gitlab-org/gitlab/-/issues/322147).
### Access requirements
#### Elasticsearch with role privileges
To access and perform operations in Elasticsearch, GitLab requires a role with the following privileges:
```json
{
"cluster": ["monitor"],
"indices": [
{
"names": ["gitlab-*"],
"privileges": [
"create_index",
"delete_index",
"view_index_metadata",
"read",
"manage",
"write"
]
}
]
}
```
For more information, see [Elasticsearch security privileges](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-privileges.html).
#### AWS OpenSearch Service with fine-grained access control
To use the self-managed AWS OpenSearch Service with GitLab using fine-grained access control, try one of the
[recommended configurations](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac.html#fgac-recommendations).
Configure your instance's domain access policies to allow `es:ESHttp*` actions. You can customize
the following example configuration to limit principals or resources:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"*"
]
},
"Action": [
"es:ESHttp*"
],
"Resource": "domain-arn/*"
}
]
}
```
For more information, see [Identity and Access Management in Amazon OpenSearch Service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ac.html).
##### Connecting with a master user in the internal database
When using fine-grained access control with a user in the internal database, you should use HTTP basic
authentication to connect to OpenSearch. You can provide the master username and password as part of the
OpenSearch URL or in the **Username** and **Password** text boxes in the advanced search settings. See
[Tutorial: Internal user database and HTTP basic authentication](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac-walkthrough-basic.html) for details.
##### Connecting with an IAM user
When using fine-grained access control with IAM credentials, you can provide the credentials in the **AWS OpenSearch IAM credentials** section in the advanced search settings.
##### Permissions for fine-grained access control
The following permissions are required for advanced search. See [Creating roles](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac.html#fgac-roles) for details.
```json
{
"cluster_permissions": [
"cluster_composite_ops",
"cluster_monitor"
],
"index_permissions": [
{
"index_patterns": [
"gitlab*"
],
"allowed_actions": [
"data_access",
"manage_aliases",
"search",
"create_index",
"delete",
"manage"
]
},
{
"index_patterns": [
"*"
],
"allowed_actions": [
"indices:admin/aliases/get",
"indices:monitor/stats"
]
}
]
}
```
The index pattern `*` requires a few permissions for advanced search to work.
### Limit the amount of namespace and project data to index
When you select the **Limit the amount of namespace and project data to index**

53
doc/integration/advanced_search/elasticsearch_troubleshooting.md
View File

@ -143,6 +143,49 @@ There are a couple of ways to achieve that:
::Gitlab::CurrentSettings.search_using_elasticsearch?(scope: Project.find_by_full_path("/my-namespace/my-project"))
```
## Troubleshooting access
### User: anonymous is not authorized to perform: es:ESHttpGet
When using a domain level access policy with AWS OpenSearch or Elasticsearch, the AWS role is not assigned to the
correct GitLab nodes. The GitLab Rails and Sidekiq nodes require permission to communicate with the search cluster.
```plaintext
User: anonymous is not authorized to perform: es:ESHttpGet because no resource-based policy allows the es:ESHttpGet
action
```
To fix this, ensure the AWS role is assigned to the correct GitLab nodes.
### Credential should be scoped to a valid region
When using AWS authorization with Advanced search, the region must be valid.
### No permissions for [indices:data/write/bulk]
When using fine-grained access control with an IAM role or a role created using AWS OpenSearch Dashboards, you might
encounter the following error:
```json
{
"error": {
"root_cause": [
{
"type": "security_exception",
"reason": "no permissions for [indices:data/write/bulk] and User [name=arn:aws:iam::xxx:role/INSERT_ROLE_NAME_HERE, backend_roles=[arn:aws:iam::xxx:role/INSERT_ROLE_NAME_HERE], requestedTenant=null]"
}
],
"type": "security_exception",
"reason": "no permissions for [indices:data/write/bulk] and User [name=arn:aws:iam::xxx:role/INSERT_ROLE_NAME_HERE, backend_roles=[arn:aws:iam::xxx:role/INSERT_ROLE_NAME_HERE], requestedTenant=null]"
},
"status": 403
}
```
To fix this, you need
to [map the roles to users](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac.html#fgac-mapping)
in the AWS OpenSearch Dashboards.
## Troubleshooting indexing
Troubleshooting indexing issues can be tricky. It can pretty quickly go to either GitLab
@ -512,16 +555,6 @@ however, searches only surface results that can be viewed by the user.
Advanced search honors all permission checks in the application by
filtering out projects that a user does not have access to at search time.
### Role mapping when using fine-grained access control with AWS Elasticsearch or OpenSearch
When using fine-grained access control with an IAM role or a role created using OpenSearch Dashboards, you might encounter the following error:
```plaintext
{"error":{"root_cause":[{"type":"security_exception","reason":"no permissions for [indices:data/write/bulk] and User [name=arn:aws:iam::xxx:role/INSERT_ROLE_NAME_HERE, backend_roles=[arn:aws:iam::xxx:role/INSERT_ROLE_NAME_HERE], requestedTenant=null]"}],"type":"security_exception","reason":"no permissions for [indices:data/write/bulk] and User [name=arn:aws:iam::xxx:role/INSERT_ROLE_NAME_HERE, backend_roles=[arn:aws:iam::xxx:role/INSERT_ROLE_NAME_HERE], requestedTenant=null]"},"status":403}
```
To fix this, you need to [map the roles to users](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac.html#fgac-mapping) in Kibana.
## Elasticsearch workers overload Sidekiq
In some cases, Elasticsearch cannot connect to GitLab anymore because:

2
doc/update/patch_versions.md
View File

@ -109,7 +109,7 @@ DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-managed
Follow the [install instruction](../integration/advanced_search/elasticsearch.md#install-elasticsearch).
Follow the [install instruction](../integration/advanced_search/elasticsearch.md#install-elasticsearch-or-aws-opensearch-cluster).
### 9. Start application

2
doc/update/upgrading_from_ce_to_ee.md
View File

@ -88,7 +88,7 @@ DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-managed
Follow the [install instruction](../integration/advanced_search/elasticsearch.md#install-elasticsearch).
Follow the [install instruction](../integration/advanced_search/elasticsearch.md#install-elasticsearch-or-aws-opensearch-cluster).
### 5. Start application

5
doc/user/analytics/analytics_dashboards.md
View File

@ -154,9 +154,10 @@ To change the location of a group's dashboards:
### Project dashboards
Dashboards are usually defined in the project where the analytics data is being retrieved from.
By default custom dashboards are saved to the current project, because
dashboards are usually defined in the project where the analytics data is retrieved from.
However, you can also have a separate project for dashboards.
This is recommended if you want to enforce specific access rules to the dashboard definitions or share dashboards across multiple projects.
This setup is recommended if you want to enforce specific access rules to the dashboard definitions or share dashboards across multiple projects.
NOTE:
You can share dashboards only between projects that are located in the same group.

7
doc/user/application_security/policies/pipeline_execution_policies.md
View File

@ -12,6 +12,11 @@ DETAILS:
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/13266) in GitLab 17.2 [with a flag](../../../administration/feature_flags.md) named `pipeline_execution_policy_type`. Disabled by default.
FLAG:
The availability of this feature is controlled by a feature flag.
For more information, see the history.
This feature is available for testing, but not ready for production use.
Use Pipeline execution policies to enforce CI/CD jobs for all applicable projects.
- <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> For a video walkthrough, see [Security Policies: Pipeline Execution Policy Type](https://www.youtube.com/watch?v=QQAOpkZ__pA).
@ -48,7 +53,7 @@ Note the following:
- Users triggering a pipeline must have at least read access to CI file specified in `content`.
- Pipeline execution policy jobs can be assigned to one of the two reserved stages:
- `.pipeline-policy-pre` at the beginning of the pipeline, before the `.pre` stage.
- `.pipeline-policy-post` at the very end of the pipeline, after the .post stage.
- `.pipeline-policy-post` at the very end of the pipeline, after the `.post` stage.
- Injecting jobs in any of the reserved stages is guaranteed to always work. Execution policy jobs can also be assigned to any standard (build, test, deploy) or user-declared stages. However, in this case, the jobs may be ignored depending on the project pipeline configuration.
- It is not possible to assign jobs to reserved stages outside of a pipeline execution policy.

8
doc/user/application_security/secret_detection/secret_push_protection/index.md
View File

@ -144,7 +144,7 @@ scanned after they are pushed to the repository.
To skip secret push protection for all commits in a push, either:
- If you're using the Git CLI client, [instruct Git to skip secret push protection](#skip-when-using-the-git-cli-client).
- If you're using any other client, [add `[skip secret detection]` to one of the commit messages](#skip-when-using-the-git-cli-client).
- If you're using any other client, [add `[skip secret push protection]` to one of the commit messages](#skip-when-using-the-git-cli-client).
#### Skip when using the Git CLI client
@ -156,16 +156,16 @@ To skip secret push protection when using the Git CLI client:
contains a secret. To skip secret push protection, you append the push option to the Git command.
```shell
git push -o secret_detection.skip_all
git push -o secret_push_protection.skip_all
```
#### Skip when using any Git client
To skip secret push protection when using any Git client:
- Add `[skip secret detection]` to one of the commit messages, on either an existing line or a new
- Add `[skip secret push protection]` to one of the commit messages, on either an existing line or a new
line, then push the commits.
For example, you are using the GitLab Web IDE and have several commits that are blocked from being
pushed because one of them contains a secret. To skip secret push protection, edit the latest
commit message and add `[skip secret detection]`, then push the commits.
commit message and add `[skip secret push protection]`, then push the commits.

4
doc/user/project/integrations/git_guardian.md
View File

@ -81,8 +81,8 @@ You can skip GitGuardian secret detection, if needed. The options to skip
secret detection for all commits in a push are identical to the options for
[Native Secret Detection](../../application_security/secret_detection/secret_push_protection/index.md#skip-secret-push-protection). Either:
- Add `[skip secret detection]` to one of the commit messages.
- Use the `secret_detection.skip_all` push option.
- Add `[skip secret push protection]` to one of the commit messages.
- Use the `secret_push_protection.skip_all` [push option](../../../gitlab-basics/add-file.md#push-options-for-gitguardian-integration).
## Known issues

3
lib/gitlab/push_options.rb
View File

@ -28,6 +28,9 @@ module Gitlab
},
secret_detection: {
keys: [:skip_all]
},
secret_push_protection: {
keys: [:skip_all]
}
}).freeze

3
locale/gitlab.pot
View File

@ -41426,6 +41426,9 @@ msgstr ""
msgid "ProjectSettings|Build, test, and deploy your changes. Does not apply to project integrations."
msgstr ""
msgid "ProjectSettings|By default the current project is used."
msgstr ""
msgid "ProjectSettings|Checkbox is visible and selected by default."
msgstr ""

12
spec/services/users/build_service_spec.rb
View File

@ -24,18 +24,6 @@ RSpec.describe Users::BuildService, feature_category: :user_management do
expect { user.save! }.to change { UserDetail.count }.by(1)
end
context 'when create_user_details_all_user_creation feature flag is disabled' do
before do
stub_feature_flags(create_user_details_all_user_creation: false)
end
it 'does not create the user_detail record' do
user = service.execute
expect { user.save! }.not_to change { UserDetail.count }
end
end
end
context 'with nil current_user' do

20
spec/services/users/create_service_spec.rb
View File

@ -37,16 +37,6 @@ RSpec.describe Users::CreateService, feature_category: :user_management do
it 'creates the user_detail record' do
expect { service.execute }.to change { UserDetail.count }.by(1)
end
context 'when create_user_details_all_user_creation feature flag is disabled' do
before do
stub_feature_flags(create_user_details_all_user_creation: false)
end
it 'does not create the user_detail record' do
expect { service.execute }.not_to change { UserDetail.count }
end
end
end
context 'when the current_user is not persisted' do
@ -192,16 +182,6 @@ RSpec.describe Users::CreateService, feature_category: :user_management do
it 'creates the user_detail record' do
expect { service.execute }.to change { UserDetail.count }.by(1)
end
context 'when create_user_details_all_user_creation feature flag is disabled' do
before do
stub_feature_flags(create_user_details_all_user_creation: false)
end
it 'does not create the user_detail record' do
expect { service.execute }.not_to change { UserDetail.count }
end
end
end
end
end

12
spec/services/users/registrations_build_service_spec.rb
View File

@ -20,18 +20,6 @@ RSpec.describe Users::RegistrationsBuildService, feature_category: :system_acces
expect { user.save! }.to change { UserDetail.count }.by(1)
end
context 'when create_user_details_all_user_creation feature flag is disabled' do
before do
stub_feature_flags(create_user_details_all_user_creation: false)
end
it 'creates the user_detail record' do
user = service.execute
expect { user.save! }.to change { UserDetail.count }.by(1)
end
end
end
context 'when automatic user confirmation is not enabled' do