root
/
gitlab-ce
mirror of https://gitlab.com/free-releases/gitlab-ce.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2025-02-21 21:12:16 +00:00
parent e503135bfe
commit 6ba461dc20
22 changed files with 471 additions and 381 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
.gitlab/ci/rails.gitlab-ci.yml
View File

@ -19,13 +19,18 @@ setup-test-env:
variables:
SETUP_DB: "false"
script:
- echo $CI_MERGE_REQUEST_APPROVED
- source scripts/gitlab_component_helpers.sh
- run_timed_command "download_and_extract_gitlab_workhorse_package" || true
- section_start "setup-test-env" "Setting up testing environment"; scripts/setup-test-env; section_end "setup-test-env";
- select_gitlab_workhorse_essentials
- section_start "gitaly-test-build" "Compiling Gitaly binaries"; scripts/gitaly-test-build; section_end "gitaly-test-build"; # Do not use 'bundle exec' here
- strip_executable_binaries "${TMP_TEST_FOLDER}"
- |
function setup_test_env() {
echo $CI_MERGE_REQUEST_APPROVED
source scripts/gitlab_component_helpers.sh
run_timed_command "download_and_extract_gitlab_workhorse_package" || true
section_start "setup-test-env" "Setting up testing environment"; scripts/setup-test-env; section_end "setup-test-env";
select_gitlab_workhorse_essentials
section_start "gitaly-test-build" "Compiling Gitaly binaries"; scripts/gitaly-test-build; section_end "gitaly-test-build"; # Do not use 'bundle exec' here
strip_executable_binaries "${TMP_TEST_FOLDER}"
}
run_with_custom_exit_code setup_test_env
artifacts:
expire_in: 7d
paths:

7
.gitlab/ci/rules.gitlab-ci.yml
View File

@ -46,6 +46,11 @@
.if-default-branch-refs: &if-default-branch-refs
if: '$CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH && $CI_MERGE_REQUEST_IID == null'
# This rule ensures the job runs for push pipeline events on stable branches.
# This is used for ensuring jobs run in a pipeline triggered by mirror sync.
.if-sync-changes-on-stable-branches: &if-sync-changes-on-stable-branches
if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_REF_NAME =~ /^[\d-]+-stable(-ee)?$/'
.if-auto-deploy-branches: &if-auto-deploy-branches
if: '$CI_COMMIT_BRANCH =~ /^\d+-\d+-auto-deploy-\d+$/'
@ -1129,6 +1134,7 @@
when: never
- if: '$ENABLE_BUILD_ASSETS_IMAGE == "true"'
- <<: *if-tag
- <<: *if-sync-changes-on-stable-branches
- !reference [".frontend:rules:assets-shared", rules]
# Always build on stable branches to serve release-environments pipeline
# Do not refer directly to .release-environments:rules:start-release-environments-security-pipeline
@ -1349,6 +1355,7 @@
when: never
- if: '$ENABLE_COMPILE_PRODUCTION_ASSETS == "true"'
- <<: *if-tag
- <<: *if-sync-changes-on-stable-branches
- !reference [".frontend:rules:assets-shared", rules]
# Always build on stable branches to serve release-environments pipeline
# Do not refer directly to .release-environments:rules:start-release-environments-security-pipeline

2
Gemfile
View File

@ -549,7 +549,7 @@ group :development, :test do
# For now we only use vite in development / test, and not for production builds
# See: https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/106
gem 'vite_rails', '~> 3.0.17', feature_category: :shared
gem 'vite_ruby', '~> 3.8.0', feature_category: :shared
gem 'vite_ruby', '~> 3.9.0', feature_category: :shared
gem 'gitlab-housekeeper', path: 'gems/gitlab-housekeeper', feature_category: :tooling
end

4
Gemfile.checksum
View File

@ -376,7 +376,7 @@
{"name":"llhttp-ffi","version":"0.4.0","platform":"ruby","checksum":"e5f7327db3cf8007e648342ef76347d6e0ae545a8402e519cca9c886eb37b001"},
{"name":"locale","version":"2.1.4","platform":"ruby","checksum":"522f9973ef3eee64aac9bca06d21db2fba675fa3d2cf61d21f42d1ca18a9f780"},
{"name":"lockbox","version":"1.3.0","platform":"ruby","checksum":"ca8e5806e4e0c56d1d762ac5cf401940ff53fc37554ef623d3313c7a6331a3ea"},
{"name":"logger","version":"1.6.5","platform":"ruby","checksum":"c3cfe56d01656490ddd103d38b8993d73d86296adebc5f58cefc9ec03741e56b"},
{"name":"logger","version":"1.6.6","platform":"ruby","checksum":"dd618d24e637715472732e7eed02e33cfbdf56deaad225edd0f1f89d38024017"},
{"name":"lograge","version":"0.11.2","platform":"ruby","checksum":"4cbd1554b86f545d795eff15a0c24fd25057d2ac4e1caa5fc186168b3da932ef"},
{"name":"loofah","version":"2.24.0","platform":"ruby","checksum":"61e6a710883abb8210887f3dc868cf3ed66594c509d9ff6987621efa6651ee1e"},
{"name":"lookbook","version":"2.3.4","platform":"ruby","checksum":"16484c9eb514ac0c23c4b59cfd5a52697141d35056e3a9c2a22b314c1b887605"},
@ -780,7 +780,7 @@
{"name":"view_component","version":"3.21.0","platform":"ruby","checksum":"7f5a77bca29e7385495fad2b7c1acdcd2c581b3cd2e573a831a9808f6710df5c"},
{"name":"virtus","version":"2.0.0","platform":"ruby","checksum":"8841dae4eb7fcc097320ba5ea516bf1839e5d056c61ee27138aa4bddd6e3d1c2"},
{"name":"vite_rails","version":"3.0.19","platform":"ruby","checksum":"195c44677bc05c1f94e7a69f1264e49d4bad2729ab06538ee858c2962f5bb500"},
{"name":"vite_ruby","version":"3.8.2","platform":"ruby","checksum":"f3f1460d5b61d20be76270ceb61f1cde32f6d22ec954933a1391f742605690b9"},
{"name":"vite_ruby","version":"3.9.1","platform":"ruby","checksum":"e4584a4ba1578602f13a3ac73402007aed044bd660daaac220523a97c49a4cc4"},
{"name":"vmstat","version":"2.3.1","platform":"ruby","checksum":"5587cb430a54dbfc4a5c29dd01bd6a4031b2ff4c1d387504d74ff246f3b39104"},
{"name":"warden","version":"1.2.9","platform":"ruby","checksum":"46684f885d35a69dbb883deabf85a222c8e427a957804719e143005df7a1efd0"},
{"name":"warning","version":"1.3.0","platform":"ruby","checksum":"23695a5d8e50bd5c46068931b529bee0b28e4982cbcefbe77d867800dde8069e"},

8
Gemfile.lock
View File

@ -1125,7 +1125,7 @@ GEM
rake (~> 13.0)
locale (2.1.4)
lockbox (1.3.0)
logger (1.6.5)
logger (1.6.6)
lograge (0.11.2)
actionpack (>= 4)
activesupport (>= 4)
@ -1943,8 +1943,10 @@ GEM
vite_rails (3.0.19)
railties (>= 5.1, < 9)
vite_ruby (~> 3.0, >= 3.2.2)
vite_ruby (3.8.2)
vite_ruby (3.9.1)
dry-cli (>= 0.7, < 2)
logger (~> 1.6)
mutex_m
rack-proxy (~> 0.6, >= 0.6.1)
zeitwerk (~> 2.2)
vmstat (2.3.1)
@ -2350,7 +2352,7 @@ DEPENDENCIES
version_sorter (~> 2.3)
view_component (~> 3.21.0)
vite_rails (~> 3.0.17)
vite_ruby (~> 3.8.0)
vite_ruby (~> 3.9.0)
vmstat (~> 2.3.0)
warning (~> 1.3.0)
webauthn (~> 3.0)

8
Gemfile.next.checksum
View File

@ -379,7 +379,7 @@
{"name":"llhttp-ffi","version":"0.4.0","platform":"ruby","checksum":"e5f7327db3cf8007e648342ef76347d6e0ae545a8402e519cca9c886eb37b001"},
{"name":"locale","version":"2.1.4","platform":"ruby","checksum":"522f9973ef3eee64aac9bca06d21db2fba675fa3d2cf61d21f42d1ca18a9f780"},
{"name":"lockbox","version":"1.3.0","platform":"ruby","checksum":"ca8e5806e4e0c56d1d762ac5cf401940ff53fc37554ef623d3313c7a6331a3ea"},
{"name":"logger","version":"1.6.5","platform":"ruby","checksum":"c3cfe56d01656490ddd103d38b8993d73d86296adebc5f58cefc9ec03741e56b"},
{"name":"logger","version":"1.6.6","platform":"ruby","checksum":"dd618d24e637715472732e7eed02e33cfbdf56deaad225edd0f1f89d38024017"},
{"name":"lograge","version":"0.11.2","platform":"ruby","checksum":"4cbd1554b86f545d795eff15a0c24fd25057d2ac4e1caa5fc186168b3da932ef"},
{"name":"loofah","version":"2.24.0","platform":"ruby","checksum":"61e6a710883abb8210887f3dc868cf3ed66594c509d9ff6987621efa6651ee1e"},
{"name":"lookbook","version":"2.3.4","platform":"ruby","checksum":"16484c9eb514ac0c23c4b59cfd5a52697141d35056e3a9c2a22b314c1b887605"},
@ -727,8 +727,8 @@
{"name":"state_machines","version":"0.5.0","platform":"ruby","checksum":"23e6249d374a920b528dccade403518b4abbd83841a3e2c9ef13e6f1a009b102"},
{"name":"state_machines-activemodel","version":"0.8.0","platform":"ruby","checksum":"e932dab190d4be044fb5f9cab01a3ea0b092c5f113d4676c6c0a0d49bf738d2c"},
{"name":"state_machines-activerecord","version":"0.8.0","platform":"ruby","checksum":"072fb701b8ab03de0608297f6c55dc34ed096e556fa8f77e556f3c461c71aab6"},
{"name":"stringio","version":"3.1.4","platform":"java","checksum":"04cf2b014409c3b5fb36145e7189e7dbfc363b780b95045dbff2bee0ad14430a"},
{"name":"stringio","version":"3.1.4","platform":"ruby","checksum":"7dd68f6f1a88610817c21f6d926dbf36e1fc585d3869fcd4a56c1f3210591d70"},
{"name":"stringio","version":"3.1.5","platform":"java","checksum":"d1e136540e41c833ba39c0468b212f33755b438517b45bebf5868eec2c9422a7"},
{"name":"stringio","version":"3.1.5","platform":"ruby","checksum":"bca92461515a131535743bc81d5559fa1de7d80cff9a654d6c0af6f9f27e35c8"},
{"name":"strings","version":"0.2.1","platform":"ruby","checksum":"933293b3c95cf85b81eb44b3cf673e3087661ba739bbadfeadf442083158d6fb"},
{"name":"strings-ansi","version":"0.2.0","platform":"ruby","checksum":"90262d760ea4a94cc2ae8d58205277a343409c288cbe7c29416b1826bd511c88"},
{"name":"swd","version":"2.0.3","platform":"ruby","checksum":"4cdbe2a4246c19f093fce22e967ec3ebdd4657d37673672e621bf0c7eb770655"},
@ -793,7 +793,7 @@
{"name":"view_component","version":"3.21.0","platform":"ruby","checksum":"7f5a77bca29e7385495fad2b7c1acdcd2c581b3cd2e573a831a9808f6710df5c"},
{"name":"virtus","version":"2.0.0","platform":"ruby","checksum":"8841dae4eb7fcc097320ba5ea516bf1839e5d056c61ee27138aa4bddd6e3d1c2"},
{"name":"vite_rails","version":"3.0.19","platform":"ruby","checksum":"195c44677bc05c1f94e7a69f1264e49d4bad2729ab06538ee858c2962f5bb500"},
{"name":"vite_ruby","version":"3.8.2","platform":"ruby","checksum":"f3f1460d5b61d20be76270ceb61f1cde32f6d22ec954933a1391f742605690b9"},
{"name":"vite_ruby","version":"3.9.1","platform":"ruby","checksum":"e4584a4ba1578602f13a3ac73402007aed044bd660daaac220523a97c49a4cc4"},
{"name":"vmstat","version":"2.3.1","platform":"ruby","checksum":"5587cb430a54dbfc4a5c29dd01bd6a4031b2ff4c1d387504d74ff246f3b39104"},
{"name":"warden","version":"1.2.9","platform":"ruby","checksum":"46684f885d35a69dbb883deabf85a222c8e427a957804719e143005df7a1efd0"},
{"name":"warning","version":"1.3.0","platform":"ruby","checksum":"23695a5d8e50bd5c46068931b529bee0b28e4982cbcefbe77d867800dde8069e"},

10
Gemfile.next.lock
View File

@ -1142,7 +1142,7 @@ GEM
rake (~> 13.0)
locale (2.1.4)
lockbox (1.3.0)
logger (1.6.5)
logger (1.6.6)
lograge (0.11.2)
actionpack (>= 4)
activesupport (>= 4)
@ -1853,7 +1853,7 @@ GEM
state_machines-activerecord (0.8.0)
activerecord (>= 5.1)
state_machines-activemodel (>= 0.8.0)
stringio (3.1.4)
stringio (3.1.5)
strings (0.2.1)
strings-ansi (~> 0.2)
unicode-display_width (>= 1.5, < 3.0)
@ -1977,8 +1977,10 @@ GEM
vite_rails (3.0.19)
railties (>= 5.1, < 9)
vite_ruby (~> 3.0, >= 3.2.2)
vite_ruby (3.8.2)
vite_ruby (3.9.1)
dry-cli (>= 0.7, < 2)
logger (~> 1.6)
mutex_m
rack-proxy (~> 0.6, >= 0.6.1)
zeitwerk (~> 2.2)
vmstat (2.3.1)
@ -2385,7 +2387,7 @@ DEPENDENCIES
version_sorter (~> 2.3)
view_component (~> 3.21.0)
vite_rails (~> 3.0.17)
vite_ruby (~> 3.8.0)
vite_ruby (~> 3.9.0)
vmstat (~> 2.3.0)
warning (~> 1.3.0)
webauthn (~> 3.0)

7
app/controllers/dashboard/todos_controller.rb
View File

@ -1,10 +1,17 @@
# frozen_string_literal: true
class Dashboard::TodosController < Dashboard::ApplicationController
include Gitlab::InternalEventsTracking
feature_category :notifications
urgency :low
def index
track_internal_event(
'view_todo_list',
user: current_user
)
push_frontend_feature_flag(:todos_bulk_actions, current_user)
end

15
config/events/view_todo_list.yml Normal file
View File

@ -0,0 +1,15 @@
---
description: User views the To-Do List
internal_events: true
action: view_todo_list
identifiers:
- user
product_group: personal_productivity
product_categories:
- notifications
milestone: '17.10'
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/182178
tiers:
- free
- premium
- ultimate

23
config/metrics/counts_all/count_distinct_user_id_from_view_todo_list.yml Normal file
View File

@ -0,0 +1,23 @@
---
key_path: redis_hll_counters.count_distinct_user_id_from_view_todo_list
description: Count of unique users that viewed the To-Do List
product_group: personal_productivity
product_categories:
- notifications
performance_indicator_type: []
value_type: number
status: active
milestone: '17.10'
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/182178
time_frame:
- 28d
- 7d
data_source: internal_events
data_category: optional
tiers:
- free
- premium
- ultimate
events:
- name: view_todo_list
unique: user.id

10
doc/administration/gitlab_duo_self_hosted/supported_models_and_hardware_requirements.md
View File

@ -27,7 +27,7 @@ The following table shows the supported models along with their specific feature
## Supported models
The following GitLab-supported large language models (LLMs) are generally available.
Support for the following GitLab-supported large language models (LLMs) is generally available.
- Fully compatible: The model can likely handle the feature without any loss of quality.
- Largely compatible: The model supports the feature, but there might be compromises or limitations.
@ -39,12 +39,12 @@ The following GitLab-supported large language models (LLMs) are generally availa
|-------------|-------|---------------------|-----------------|-----------------|-----------------|
| Mistral Codestral | [Codestral 22B v0.1](https://huggingface.co/mistralai/Codestral-22B-v0.1) | [vLLM](supported_llm_serving_platforms.md#for-self-hosted-model-deployments) | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-filled" >}} Fully compatible | N/A |
| Mistral | [Mistral 7B-it v0.3](https://huggingface.co/mistralai/Mistral-7B-Instruct-v0.3) | [vLLM](supported_llm_serving_platforms.md#for-self-hosted-model-deployments) | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="dash-circle" >}} Not compatible |
| Mistral | [Mixtral 8x7B-it v0.1](https://huggingface.co/mistralai/Mixtral-8x7B-Instruct-v0.1) | [vLLM](supported_llm_serving_platforms.md#for-self-hosted-model-deployments), [AWS Bedrock](https://aws.amazon.com/bedrock/mistral/) | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-dashed" >}} Limited compatibility |
| Mistral | [Mixtral 8x22B-it v0.1](https://huggingface.co/mistralai/Mixtral-8x22B-Instruct-v0.1) | [vLLM](supported_llm_serving_platforms.md#for-self-hosted-model-deployments) | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-dashed" >}} Limited compatibility |
| Mistral | [Mixtral 8x7B-it v0.1](https://huggingface.co/mistralai/Mixtral-8x7B-Instruct-v0.1) | [vLLM](supported_llm_serving_platforms.md#for-self-hosted-model-deployments), [AWS Bedrock](https://aws.amazon.com/bedrock/mistral/) | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-dashed" >}} Largely compatible |
| Mistral | [Mixtral 8x22B-it v0.1](https://huggingface.co/mistralai/Mixtral-8x22B-Instruct-v0.1) | [vLLM](supported_llm_serving_platforms.md#for-self-hosted-model-deployments) | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-dashed" >}} Largely compatible |
| Claude 3 | [Claude 3.5 Sonnet](https://www.anthropic.com/news/claude-3-5-sonnet) | [AWS Bedrock](https://aws.amazon.com/bedrock/claude/) | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-filled" >}} Fully compatible |
| GPT | [GPT-4 Turbo](https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/models?tabs=python-secure#gpt-4) | [Azure OpenAI](https://learn.microsoft.com/en-us/azure/ai-services/openai/overview) | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-dashed" >}} Limited compatibility |
| GPT | [GPT-4 Turbo](https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/models?tabs=python-secure#gpt-4) | [Azure OpenAI](https://learn.microsoft.com/en-us/azure/ai-services/openai/overview) | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-dashed" >}} Largely compatible |
| GPT | [GPT-4o](https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/models?tabs=python-secure#gpt-4o-and-gpt-4-turbo) | [Azure OpenAI](https://learn.microsoft.com/en-us/azure/ai-services/openai/overview) | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-filled" >}} Fully compatible |
| GPT | [GPT-4o-mini](https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/models?tabs=python-secure#gpt-4o-and-gpt-4-turbo) | [Azure OpenAI](https://learn.microsoft.com/en-us/azure/ai-services/openai/overview) | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-dashed" >}} Limited compatibility |
| GPT | [GPT-4o-mini](https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/models?tabs=python-secure#gpt-4o-and-gpt-4-turbo) | [Azure OpenAI](https://learn.microsoft.com/en-us/azure/ai-services/openai/overview) | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-filled" >}} Fully compatible | {{< icon name="check-circle-dashed" >}} Largely compatible |
### Experimental and beta models

18
doc/api/api_resources.md
View File

@ -12,16 +12,14 @@ title: REST API resources
{{< /details >}}
Available resources for the [GitLab REST API](_index.md) can be grouped in the following contexts:
The GitLab REST API provides HTTP endpoints to control and interact
with GitLab resources and features programmatically.
The REST API resources are organized into:
- [Projects](#project-resources)
- [Groups](#group-resources)
- [Standalone](#standalone-resources)
See also:
- Adding [deploy keys for multiple projects](deploy_keys.md#add-deploy-keys-to-multiple-projects)
- [API Resources for various templates](#templates-api-resources)
- [Project endpoints](#project-resources)
- [Group endpoints](#group-resources)
- [Standalone endpoints](#standalone-resources)
- [Template endpoints](#template-resources)
## Project resources
@ -212,7 +210,7 @@ The following API resources are available outside of project and group contexts
| [Web commits](web_commits.md) | `/web_commits/public_key` |
| [Version](version.md) | `/version` |
## Templates API resources
## Template resources
Endpoints are available for:

576
doc/api/merge_request_approvals.md
View File

@ -23,256 +23,102 @@ Configuration for
[approvals on all merge requests](../user/project/merge_requests/approvals/_index.md)
in the project. All endpoints require authentication.
## Group approval rules
## Approve merge request
{{< details >}}
- Status: Experiment
{{< /details >}}
{{< history >}}
- [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/428051) in GitLab 16.7 [with a flag](../administration/feature_flags.md) named `approval_group_rules`. Disabled by default. This feature is an [experiment](../policy/development_stages_support.md).
{{< /history >}}
{{< alert type="flag" >}}
On GitLab Self-Managed, by default this feature is not available. To make it available, an administrator can [enable the feature flag](../administration/feature_flags.md) named `approval_group_rules`.
On GitLab.com and GitLab Dedicated, this feature is not available.
This feature is not ready for production use.
{{< /alert >}}
Group approval rules apply to all protected branches of projects belonging to the group. This feature is an [experiment](../policy/development_stages_support.md).
### Get group approval rules
{{< history >}}
- [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/440638) in GitLab 16.10.
{{< /history >}}
Group admins can request information about a group's approval rules using the following endpoint:
Users with the appropriate role can approve a merge request using this endpoint:
```plaintext
GET /groups/:id/approval_rules
```
Use the `page` and `per_page` [pagination](rest/_index.md#offset-based-pagination) parameters to restrict the list of approval rules.
Supported attributes:
| Attribute | Type | Required | Description |
|-----------|-------------------|----------|-------------|
| `id` | integer or string | Yes | The ID or [URL-encoded path of a project](rest/_index.md#namespaced-paths). |
Example request:
```shell
curl --request GET \
--header "PRIVATE-TOKEN: <your_access_token>" \
--url "https://gitlab.example.com/api/v4/groups/29/approval_rules"
```
Example response:
```json
[
{
"id": 2,
"name": "rule1",
"rule_type": "any_approver",
"report_type": null,
"eligible_approvers": [],
"approvals_required": 3,
"users": [],
"groups": [],
"contains_hidden_groups": false,
"protected_branches": [],
"applies_to_all_protected_branches": true
},
{
"id": 3,
"name": "rule2",
"rule_type": "code_owner",
"report_type": null,
"eligible_approvers": [],
"approvals_required": 2,
"users": [],
"groups": [],
"contains_hidden_groups": false,
"protected_branches": [],
"applies_to_all_protected_branches": true
},
{
"id": 4,
"name": "rule2",
"rule_type": "report_approver",
"report_type": "code_coverage",
"eligible_approvers": [],
"approvals_required": 2,
"users": [],
"groups": [],
"contains_hidden_groups": false,
"protected_branches": [],
"applies_to_all_protected_branches": true
}
]
```
### Create group approval rules
Group admins can create approval rules for a group using the following endpoint:
```plaintext
POST /groups/:id/approval_rules
POST /projects/:id/merge_requests/:merge_request_iid/approve
```
Supported attributes:
| Attribute | Type | Required | Description |
|----------------------|-------------------|----------|-------------|
| `id` | integer or string | Yes | The ID or [URL-encoded path of a group](rest/_index.md#namespaced-paths). |
| `approvals_required` | integer | Yes | The number of required approvals for this rule. |
| `name` | string | Yes | The name of the approval rule. |
| `group_ids` | array | No | The IDs of groups as approvers. |
| `rule_type` | string | No | The rule type. `any_approver` is a pre-configured default rule with `approvals_required` at `0`. Other rules are `regular` (used for regular [merge request approval rules](../user/project/merge_requests/approvals/rules.md)) and `report_approver`. Don't use this field to build approval rules from the API. The `report_approver` field is used when GitLab creates an approval rule from configured and enabled [merge request approval policies](../user/application_security/policies/merge_request_approval_policies.md). |
| `user_ids` | array | No | The IDs of users as approvers. |
| Attribute | Type | Required | Description |
|---------------------|-------------------|----------|-------------|
| `id` | integer or string | Yes | The ID or [URL-encoded path of a project](rest/_index.md#namespaced-paths). |
| `approval_password` | string | No | Current user's password. Required if [**Require user re-authentication to approve**](../user/project/merge_requests/approvals/settings.md#require-user-re-authentication-to-approve) is enabled in the project settings. Always fails if the group or GitLab Self-Managed instance is configured to force SAML authentication. |
| `merge_request_iid` | integer | Yes | The IID of the merge request. |
| `sha` | string | No | The `HEAD` of the merge request. |
Example request:
```shell
curl --request POST \
--header "PRIVATE-TOKEN: <your_access_token>" \
--url "https://gitlab.example.com/api/v4/groups/29/approval_rules?name=security&approvals_required=2"
```
Example response:
The `sha` parameter works in the same way as
when [accepting a merge request](merge_requests.md#merge-a-merge-request): if passed, then it must
match the current HEAD of the merge request to add the approval. If it
does not match, the response code is `409`.
```json
{
"id": 5,
"name": "security",
"rule_type": "any_approver",
"eligible_approvers": [],
"iid": 5,
"project_id": 1,
"title": "Approvals API",
"description": "Test",
"state": "opened",
"created_at": "2016-06-08T00:19:52.638Z",
"updated_at": "2016-06-09T21:32:14.105Z",
"merge_status": "can_be_merged",
"approvals_required": 2,
"users": [],
"groups": [],
"contains_hidden_groups": false,
"protected_branches": [
"approvals_left": 0,
"approved_by": [
{
"id": 5,
"name": "master",
"push_access_levels": [
{
"id": 5,
"access_level": 40,
"access_level_description": "Maintainers",
"deploy_key_id": null,
"user_id": null,
"group_id": null
}
],
"merge_access_levels": [
{
"id": 5,
"access_level": 40,
"access_level_description": "Maintainers",
"user_id": null,
"group_id": null
}
],
"allow_force_push": false,
"unprotect_access_levels": [],
"code_owner_approval_required": false,
"inherited": false
"user": {
"name": "Administrator",
"username": "root",
"id": 1,
"state": "active",
"avatar_url": "http://www.gravatar.com/avatar/e64c7d89f26bd1972efa854d13d7dd61?s=80\u0026d=identicon",
"web_url": "http://localhost:3000/root"
}
},
{
"user": {
"name": "Nico Cartwright",
"username": "ryley",
"id": 2,
"state": "active",
"avatar_url": "http://www.gravatar.com/avatar/cf7ad14b34162a76d593e3affca2adca?s=80\u0026d=identicon",
"web_url": "http://localhost:3000/ryley"
}
}
],
"applies_to_all_protected_branches": true
]
}
```
### Update group approval rules
## Unapprove merge request
{{< history >}}
If you did approve a merge request, you can unapprove it using the following
endpoint:
- [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/440639) in GitLab 16.10.
{{< /history >}}
Group admins can update group approval rules using the following endpoint:
```shell
PUT /groups/:id/approval_rules/:approval_rule_id
```plaintext
POST /projects/:id/merge_requests/:merge_request_iid/unapprove
```
Supported attributes:
| Attribute | Type | Required | Description |
|----------------------|-------------------|----------|-------------|
| `approval_rule_id`. | integer | Yes | The ID of the approval rule. |
| `id` | integer or string | Yes | The ID or [URL-encoded path of a group](rest/_index.md#namespaced-paths). |
| `approvals_required` | string | No | The number of required approvals for this rule. |
| `group_ids` | integer | No | The IDs of users as approvers. |
| `name` | string | No | The name of the approval rule. |
| `rule_type` | array | No | The rule type. `any_approver` is a pre-configured default rule with `approvals_required` at `0`. Other rules are `regular` (used for regular [merge request approval rules](../user/project/merge_requests/approvals/rules.md)) and `report_approver`. Don't use this field to build approval rules from the API. The `report_approver` field is used when GitLab creates an approval rule from configured and enabled [merge request approval policies](../user/application_security/policies/merge_request_approval_policies.md). |
| `user_ids` | array | No | The IDs of groups as approvers. |
| Attribute | Type | Required | Description |
|---------------------|-------------------|----------|-------------|
| `id` | integer or string | Yes | The ID or [URL-encoded path of a project](rest/_index.md#namespaced-paths). |
| `merge_request_iid` | integer | Yes | The IID of a merge request. |
Example request:
## Reset approvals of a merge request
Clear all approvals of merge request.
Available only for [bot users](../user/project/settings/project_access_tokens.md#bot-users-for-projects)
based on project or group tokens. Users without bot permissions receive a `401 Unauthorized` response.
```plaintext
PUT /projects/:id/merge_requests/:merge_request_iid/reset_approvals
```
| Attribute | Type | Required | Description |
|---------------------|-------------------|----------|-------------|
| `id` | integer or string | Yes | The ID or [URL-encoded path of the project](rest/_index.md#namespaced-paths). |
| `merge_request_iid` | integer | Yes | The internal ID of the merge request. |
```shell
curl --request PUT \
--header "PRIVATE-TOKEN: <your_access_token>" \
--url "https://gitlab.example.com/api/v4/groups/29/approval_rules/5?name=security2&approvals_required=1"
```
Example response:
```json
{
"id": 5,
"name": "security2",
"rule_type": "any_approver",
"eligible_approvers": [],
"approvals_required": 1,
"users": [],
"groups": [],
"contains_hidden_groups": false,
"protected_branches": [
{
"id": 5,
"name": "master",
"push_access_levels": [
{
"id": 5,
"access_level": 40,
"access_level_description": "Maintainers",
"deploy_key_id": null,
"user_id": null,
"group_id": null
}
],
"merge_access_levels": [
{
"id": 5,
"access_level": 40,
"access_level_description": "Maintainers",
"user_id": null,
"group_id": null
}
],
"allow_force_push": false,
"unprotect_access_levels": [],
"code_owner_approval_required": false,
"inherited": false
}
],
"applies_to_all_protected_branches": true
}
--url "https://gitlab.example.com/api/v4/projects/76/merge_requests/1/reset_approvals"
```
## Project approval rules
@ -1428,100 +1274,254 @@ Supported attributes:
| `approval_rule_id` | integer | Yes | The ID of an approval rule. |
| `merge_request_iid` | integer | Yes | The IID of the merge request. |
## Approve merge request
## Group approval rules
Users with the appropriate role can approve a merge request using this endpoint:
{{< details >}}
- Status: Experiment
{{< /details >}}
{{< history >}}
- [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/428051) in GitLab 16.7 [with a flag](../administration/feature_flags.md) named `approval_group_rules`. Disabled by default. This feature is an [experiment](../policy/development_stages_support.md).
{{< /history >}}
{{< alert type="flag" >}}
On GitLab Self-Managed, by default this feature is not available. To make it available, an administrator can [enable the feature flag](../administration/feature_flags.md) named `approval_group_rules`.
On GitLab.com and GitLab Dedicated, this feature is not available.
This feature is not ready for production use.
{{< /alert >}}
Group approval rules apply to all protected branches of projects belonging to the group. This feature is an [experiment](../policy/development_stages_support.md).
### Get group approval rules
{{< history >}}
- [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/440638) in GitLab 16.10.
{{< /history >}}
Group admins can request information about a group's approval rules using the following endpoint:
```plaintext
POST /projects/:id/merge_requests/:merge_request_iid/approve
GET /groups/:id/approval_rules
```
Use the `page` and `per_page` [pagination](rest/_index.md#offset-based-pagination) parameters to restrict the list of approval rules.
Supported attributes:
| Attribute | Type | Required | Description |
|-----------|-------------------|----------|-------------|
| `id` | integer or string | Yes | The ID or [URL-encoded path of a project](rest/_index.md#namespaced-paths). |
Example request:
```shell
curl --request GET \
--header "PRIVATE-TOKEN: <your_access_token>" \
--url "https://gitlab.example.com/api/v4/groups/29/approval_rules"
```
Example response:
```json
[
{
"id": 2,
"name": "rule1",
"rule_type": "any_approver",
"report_type": null,
"eligible_approvers": [],
"approvals_required": 3,
"users": [],
"groups": [],
"contains_hidden_groups": false,
"protected_branches": [],
"applies_to_all_protected_branches": true
},
{
"id": 3,
"name": "rule2",
"rule_type": "code_owner",
"report_type": null,
"eligible_approvers": [],
"approvals_required": 2,
"users": [],
"groups": [],
"contains_hidden_groups": false,
"protected_branches": [],
"applies_to_all_protected_branches": true
},
{
"id": 4,
"name": "rule2",
"rule_type": "report_approver",
"report_type": "code_coverage",
"eligible_approvers": [],
"approvals_required": 2,
"users": [],
"groups": [],
"contains_hidden_groups": false,
"protected_branches": [],
"applies_to_all_protected_branches": true
}
]
```
### Create group approval rules
Group admins can create approval rules for a group using the following endpoint:
```plaintext
POST /groups/:id/approval_rules
```
Supported attributes:
| Attribute | Type | Required | Description |
|---------------------|-------------------|----------|-------------|
| `id` | integer or string | Yes | The ID or [URL-encoded path of a project](rest/_index.md#namespaced-paths). |
| `approval_password` | string | No | Current user's password. Required if [**Require user re-authentication to approve**](../user/project/merge_requests/approvals/settings.md#require-user-re-authentication-to-approve) is enabled in the project settings. Always fails if the group or GitLab Self-Managed instance is configured to force SAML authentication. |
| `merge_request_iid` | integer | Yes | The IID of the merge request. |
| `sha` | string | No | The `HEAD` of the merge request. |
| Attribute | Type | Required | Description |
|----------------------|-------------------|----------|-------------|
| `id` | integer or string | Yes | The ID or [URL-encoded path of a group](rest/_index.md#namespaced-paths). |
| `approvals_required` | integer | Yes | The number of required approvals for this rule. |
| `name` | string | Yes | The name of the approval rule. |
| `group_ids` | array | No | The IDs of groups as approvers. |
| `rule_type` | string | No | The rule type. `any_approver` is a pre-configured default rule with `approvals_required` at `0`. Other rules are `regular` (used for regular [merge request approval rules](../user/project/merge_requests/approvals/rules.md)) and `report_approver`. Don't use this field to build approval rules from the API. The `report_approver` field is used when GitLab creates an approval rule from configured and enabled [merge request approval policies](../user/application_security/policies/merge_request_approval_policies.md). |
| `user_ids` | array | No | The IDs of users as approvers. |
The `sha` parameter works in the same way as
when [accepting a merge request](merge_requests.md#merge-a-merge-request): if passed, then it must
match the current HEAD of the merge request to add the approval. If it
does not match, the response code is `409`.
Example request:
```shell
curl --request POST \
--header "PRIVATE-TOKEN: <your_access_token>" \
--url "https://gitlab.example.com/api/v4/groups/29/approval_rules?name=security&approvals_required=2"
```
Example response:
```json
{
"id": 5,
"iid": 5,
"project_id": 1,
"title": "Approvals API",
"description": "Test",
"state": "opened",
"created_at": "2016-06-08T00:19:52.638Z",
"updated_at": "2016-06-09T21:32:14.105Z",
"merge_status": "can_be_merged",
"name": "security",
"rule_type": "any_approver",
"eligible_approvers": [],
"approvals_required": 2,
"approvals_left": 0,
"approved_by": [
"users": [],
"groups": [],
"contains_hidden_groups": false,
"protected_branches": [
{
"user": {
"name": "Administrator",
"username": "root",
"id": 1,
"state": "active",
"avatar_url": "http://www.gravatar.com/avatar/e64c7d89f26bd1972efa854d13d7dd61?s=80\u0026d=identicon",
"web_url": "http://localhost:3000/root"
}
},
{
"user": {
"name": "Nico Cartwright",
"username": "ryley",
"id": 2,
"state": "active",
"avatar_url": "http://www.gravatar.com/avatar/cf7ad14b34162a76d593e3affca2adca?s=80\u0026d=identicon",
"web_url": "http://localhost:3000/ryley"
}
"id": 5,
"name": "master",
"push_access_levels": [
{
"id": 5,
"access_level": 40,
"access_level_description": "Maintainers",
"deploy_key_id": null,
"user_id": null,
"group_id": null
}
],
"merge_access_levels": [
{
"id": 5,
"access_level": 40,
"access_level_description": "Maintainers",
"user_id": null,
"group_id": null
}
],
"allow_force_push": false,
"unprotect_access_levels": [],
"code_owner_approval_required": false,
"inherited": false
}
]
],
"applies_to_all_protected_branches": true
}
```
## Unapprove merge request
### Update group approval rules
If you did approve a merge request, you can unapprove it using the following
endpoint:
{{< history >}}
```plaintext
POST /projects/:id/merge_requests/:merge_request_iid/unapprove
- [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/440639) in GitLab 16.10.
{{< /history >}}
Group admins can update group approval rules using the following endpoint:
```shell
PUT /groups/:id/approval_rules/:approval_rule_id
```
Supported attributes:
| Attribute | Type | Required | Description |
|---------------------|-------------------|----------|-------------|
| `id` | integer or string | Yes | The ID or [URL-encoded path of a project](rest/_index.md#namespaced-paths). |
| `merge_request_iid` | integer | Yes | The IID of a merge request. |
| Attribute | Type | Required | Description |
|----------------------|-------------------|----------|-------------|
| `approval_rule_id`. | integer | Yes | The ID of the approval rule. |
| `id` | integer or string | Yes | The ID or [URL-encoded path of a group](rest/_index.md#namespaced-paths). |
| `approvals_required` | string | No | The number of required approvals for this rule. |
| `group_ids` | integer | No | The IDs of users as approvers. |
| `name` | string | No | The name of the approval rule. |
| `rule_type` | array | No | The rule type. `any_approver` is a pre-configured default rule with `approvals_required` at `0`. Other rules are `regular` (used for regular [merge request approval rules](../user/project/merge_requests/approvals/rules.md)) and `report_approver`. Don't use this field to build approval rules from the API. The `report_approver` field is used when GitLab creates an approval rule from configured and enabled [merge request approval policies](../user/application_security/policies/merge_request_approval_policies.md). |
| `user_ids` | array | No | The IDs of groups as approvers. |
## Reset approvals of a merge request
Clear all approvals of merge request.
Available only for [bot users](../user/project/settings/project_access_tokens.md#bot-users-for-projects)
based on project or group tokens. Users without bot permissions receive a `401 Unauthorized` response.
```plaintext
PUT /projects/:id/merge_requests/:merge_request_iid/reset_approvals
```
| Attribute | Type | Required | Description |
|---------------------|-------------------|----------|-------------|
| `id` | integer or string | Yes | The ID or [URL-encoded path of the project](rest/_index.md#namespaced-paths). |
| `merge_request_iid` | integer | Yes | The internal ID of the merge request. |
Example request:
```shell
curl --request PUT \
--header "PRIVATE-TOKEN: <your_access_token>" \
--url "https://gitlab.example.com/api/v4/projects/76/merge_requests/1/reset_approvals"
--url "https://gitlab.example.com/api/v4/groups/29/approval_rules/5?name=security2&approvals_required=1"
```
Example response:
```json
{
"id": 5,
"name": "security2",
"rule_type": "any_approver",
"eligible_approvers": [],
"approvals_required": 1,
"users": [],
"groups": [],
"contains_hidden_groups": false,
"protected_branches": [
{
"id": 5,
"name": "master",
"push_access_levels": [
{
"id": 5,
"access_level": 40,
"access_level_description": "Maintainers",
"deploy_key_id": null,
"user_id": null,
"group_id": null
}
],
"merge_access_levels": [
{
"id": 5,
"access_level": 40,
"access_level_description": "Maintainers",
"user_id": null,
"group_id": null
}
],
"allow_force_push": false,
"unprotect_access_levels": [],
"code_owner_approval_required": false,
"inherited": false
}
],
"applies_to_all_protected_branches": true
}
```

9
doc/api/rest/_index.md
View File

@ -13,7 +13,14 @@ title: REST API
{{< /details >}}
Use the GitLab REST API to retrieve data by using any compatible REST API client.
The GitLab REST API provides programmatic access to read and modify GitLab resources
by using standard HTTP methods and JSON data formats.
The REST API offers tools to:
- Create, update, and retrieve projects, groups, repositories, and other GitLab resources.
- Integrate GitLab data and functionality into external applications.
- Automate GitLab tasks and workflows.
- Control user access and permissions.
## Make a REST API request

85
doc/user/group/repositories_analytics/_index.md
View File

@ -12,64 +12,69 @@ title: Repository analytics for groups
{{< /details >}}
Repositories analytics for groups provides information about test coverage for all projects in a group. An
[issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/273527) to also extend support for all projects in
subgroups.
Repository analytics for groups provides test coverage data for all projects in a group.
It is similar to [repository analytics for projects](../../analytics/repository_analytics.md).
You can use group repository analytics to:
## Current group code coverage
- Monitor code coverage trends across all projects in a group.
- Track the total number of projects and jobs that generate coverage reports.
- Download historical coverage data for analysis.
The **Analyze > Repository analytics** group page displays the overall test coverage of all your projects in your group.
In the **Overall activity** section, you can see:
Support for subgroups is proposed in [issue 273527](https://gitlab.com/gitlab-org/gitlab/-/issues/273527).
- The number of projects with coverage reports.
- The average percentage of coverage across all your projects.
- The total number of pipeline jobs that produce coverage reports.
## View group repository analytics
## Average group test coverage from the last 30 days
Prerequisites:
The **Analyze > Repository analytics** group page displays the average test coverage of all your projects in your group in a graph for the last 30 days.
- Projects within the group must be configured to collect test coverage data.
## Latest project test coverage list
To see the latest code coverage for each project in your group:
To view repository analytics for a group:
1. On the left sidebar, select **Search or go to** and find your group.
1. Select **Analyze > Repository analytics**.
1. In the **Latest test coverage results** section, from the **Select projects** dropdown list, choose the projects you want to check.
You can download code coverage data for specific projects to view
[code coverage history](../../../ci/testing/code_coverage/_index.md#view-coverage-history).
## Coverage metrics
## Download historic test coverage data
The group **Repository analytics** page displays:
You can get a CSV of the code coverage data for all of the projects in your group. This report has a maximum of 1000 records. The code coverage data is from the default branch in each project.
- **Current group code coverage**:
- Number of projects with coverage reports.
- Average coverage percentage across all projects.
- Total number of pipeline jobs that produce coverage reports.
To get the report:
- **Average test coverage**: A graph that shows the average test coverage across all projects in your group for the last 30 days.
1. On the left sidebar, select **Search or go to** and find your group.
1. Select **Analyze > Repository analytics**.
1. Select **Download historic test coverage data (.csv)**.
1. Select the projects and date range you want to include in the report.
- **Latest test coverage results**: A list of the most recent coverage data for each project in your group. Select projects from the dropdown list to filter the results.
## Download coverage data
You can download a CSV file containing historical coverage data for projects in your group.
The CSV report:
- Contains up to 1000 records.
- Includes data from the default branch of each project.
- Shows one row per day when coverage was reported.
- Uses the last value of the day if multiple coverage reports were generated.
- Contains the following information for each coverage report:
- Date the coverage job ran
- Name of the job that generated the report
- Project name
- Coverage percentage
To download the coverage data:
1. On the group **Repository analytics** page, select **Download historic test coverage data (.csv)**.
1. Select the projects to include:
- From the **Projects** dropdown list, choose specific projects. The projects dropdown list shows up to 100 projects.
- Optional. Select **Select all** to include all projects in your group.
1. From the **Date range** dropdown list, select the time period to include.
1. Select **Download test coverage data (.csv)**.
The projects dropdown list shows up to 100 projects from your group. If the project you want to check is not in the dropdown list, you can select **All projects** to download the report for all projects in your group, including any projects that are not listed. There is a plan to improve this behavior in this [related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/250684).
## Related topics
For each day that a coverage report was generated by a job in a project's pipeline, a row in the CSV includes:
- The date the coverage job ran
- The name of the job that generated the coverage report
- The name of the project
- The coverage value
If the project's code coverage was calculated more than once in a day, the last value from that day is used.
{{< alert type="note" >}}
Group code coverage data is taken from the configured [default branch](../../project/repository/branches/default.md).
{{< /alert >}}
- [Repository analytics for projects](../../analytics/repository_analytics.md)
- [Code coverage](../../../ci/testing/code_coverage/_index.md)
<!-- ## Troubleshooting

6
doc/user/profile/personal_access_tokens.md
View File

@ -220,10 +220,10 @@ When you delete or block an enterprise user account, their personal access token
{{< /history >}}
Token usage information is updated every 10 minutes. GitLab considers a token used when the token is used to:
Token usage information updates periodically. The time the token was last used updates every 10 minutes, and the most recently used IP address updates every minute. GitLab considers a token used when the token:
- Authenticate with the [REST](../../api/rest/_index.md) or [GraphQL](../../api/graphql/_index.md) APIs.
- Perform a Git operation.
- Authenticates with the [REST](../../api/rest/_index.md) or [GraphQL](../../api/graphql/_index.md) APIs.
- Performs a Git operation.
To view the last time a token was used, and the IP addresses from where the token was used:

18
doc/user/project/integrations/webhooks.md
View File

@ -13,16 +13,13 @@ title: Webhooks
{{< /details >}}
Webhooks are custom HTTP callbacks that send JSON data about events in GitLab to a configured URI.
Webhooks are custom HTTP callbacks that send JSON data about GitLab events to a configured URL.
Webhooks:
You can use webhooks to:
- Trigger CI/CD jobs.
- Update external issue trackers.
- Deploy to your production server.
- [Integrate with Twilio to receive SMS alerts](https://www.datadoghq.com/blog/send-alerts-sms-customizable-webhooks-twilio/)
every time an issue is created for a project or group in GitLab.
- [Assign labels to merge requests automatically](https://about.gitlab.com/blog/2016/08/19/applying-gitlab-labels-automatically/).
- Send real-time notifications about merge requests, issues, and other GitLab events.
- Update external issue trackers and deployment tools.
- Trigger CI/CD pipelines.
- Support custom headers, payload templates, and mutual TLS.
## Webhook events
@ -593,3 +590,6 @@ GitLab does not rewrite image URLs when:
- [Group webhooks API](../../../api/group_webhooks.md)
- [System hooks API](../../../api/system_hooks.md)
- [Troubleshooting](webhooks_troubleshooting.md)
- [Webhook developer guide](../../../development/webhooks.md)
- [Send SMS alerts with webhooks and Twilio](https://www.datadoghq.com/blog/send-alerts-sms-customizable-webhooks-twilio/)
- [Applying GitLab labels automatically](https://about.gitlab.com/blog/2016/08/19/applying-gitlab-labels-automatically/)

12
lib/gitlab/ci/templates/Jobs/Dependency-Scanning.latest.gitlab-ci.yml
View File

@ -257,6 +257,12 @@ dependency-scanning:
exists:
- '**/{$ANALYZER_SUPPORTED_FILES,$ADDITIONAL_SUPPORTED_FILES}'
# Support DS_PIPCOMPILE_REQUIREMENTS_FILE_NAME_PATTERN
- if: $DS_PIPCOMPILE_REQUIREMENTS_FILE_NAME_PATTERN &&
$DS_ENFORCE_NEW_ANALYZER == 'true' &&
$CI_PIPELINE_SOURCE == "merge_request_event" &&
$GITLAB_FEATURES =~ /\bdependency_scanning\b/
## Otherwise, run the job only if the project has files supported by the new DS analyzer and not already supported by
## any gemnasium job and ensure to exclude the files already covered by the gemnasium jobs from the analysis.
- if: $CI_PIPELINE_SOURCE == "merge_request_event" &&
@ -282,6 +288,12 @@ dependency-scanning:
exists:
- '**/{$ANALYZER_SUPPORTED_FILES,$ADDITIONAL_SUPPORTED_FILES}'
# Support DS_PIPCOMPILE_REQUIREMENTS_FILE_NAME_PATTERN
- if: $DS_PIPCOMPILE_REQUIREMENTS_FILE_NAME_PATTERN &&
$DS_ENFORCE_NEW_ANALYZER == 'true' &&
$CI_COMMIT_BRANCH &&
$GITLAB_FEATURES =~ /\bdependency_scanning\b/
## Otherwise, run the job only if the project has files supported by the new DS analyzer and not already supported by
## any gemnasium job and ensure to exclude the files already covered by the gemnasium jobs from the analysis.
- if: $CI_COMMIT_BRANCH &&

1
scripts/frontend/quarantined_vue3_specs.txt
View File

@ -249,7 +249,6 @@ spec/frontend/vue_merge_request_widget/components/mr_widget_pipeline_spec.js
spec/frontend/vue_merge_request_widget/components/states/merge_failed_pipeline_confirmation_dialog_spec.js
spec/frontend/vue_merge_request_widget/components/states/mr_widget_ready_to_merge_spec.js
spec/frontend/vue_popovers_spec.js
spec/frontend/vue_shared/components/color_picker/color_picker_spec.js
spec/frontend/vue_shared/components/confirm_modal_spec.js
spec/frontend/vue_shared/components/design_management/design_note_pin_spec.js
spec/frontend/vue_shared/components/diff_stats_dropdown_spec.js

4
scripts/utils.sh
View File

@ -581,8 +581,8 @@ function find_custom_exit_code() {
if grep -i -q \
-e "Failed to connect to 127.0.0.1" \
-e "Failed to open TCP connection to" \
-e "connection reset by peer" "$trace_file"; then
-e "connection reset by peer" \
-e "OpenSSL::SSL::SSLError" "$trace_file"; then
echoerr "Detected network connection error. Changing exit code to 110."
exit_code=110
alert_job_in_slack "$exit_code" "Network connection error"

8
spec/controllers/dashboard/todos_controller_spec.rb
View File

@ -21,5 +21,13 @@ RSpec.describe Dashboard::TodosController, feature_category: :notifications do
it_behaves_like 'disabled when using an external authorization service'
end
it_behaves_like 'internal event tracking' do
subject { get :index }
let(:event) { 'view_todo_list' }
let(:category) { described_class.name }
let(:user) { create(:user) }
end
end
end

2
spec/frontend/vue_shared/components/color_picker/color_picker_spec.js
View File

@ -69,7 +69,7 @@ describe('ColorPicker', () => {
createComponent();
expect(colorPreview().attributes('style')).toBe(undefined);
expect(colorPicker().attributes('value')).toBe(undefined);
expect(colorPicker().props('value')).toBe('');
expect(colorTextInput().props('value')).toBe('');
expect(colorPreview().attributes('class')).toContain('gl-shadow-inner-1-gray-400');
});