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-06-17 18:12:06 +00:00
parent a6a2c2c757
commit 22a5ad5901
10 changed files with 429 additions and 112 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

256
doc/api/graphql/ai_impact_analytics.md Normal file
View File

@ -0,0 +1,256 @@
---
stage: Plan
group: Optimize
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Retrieve AI impact analytics data
---
{{< details >}}
- Tier: Free, Premium, Ultimate
- Add-on: GitLab Duo Pro, GitLab Duo Enterprise
- Offering: GitLab Self-Managed
{{< /details >}}
Use the GraphQL API to retrieve and export AI impact analytics data.
## Retrieve AI usage data
{{< details >}}
- Add-on: GitLab Duo Enterprise
{{< /details >}}
{{< history >}}
- [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/474469) in GitLab 17.5 with a flag named `code_suggestions_usage_events_in_pg`. Disabled by default.
- Feature flag `move_ai_tracking_to_instrumentation_layer` [added](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/167415) in GitLab 17.7. Disabled by default.
- Dependency on `move_ai_tracking_to_instrumentation_layer` [removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/179527) in GitLab 17.8.
- Feature flag `code_suggestions_usage_events_in_pg` [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/486469) in GitLab 17.8.
{{< /history >}}
The `AiUsageData` endpoint provides raw event data for Code Suggestions:
- Size
- Language
- User
- Type (shown, accepted, or rejected)
You can use this endpoint to import events into a BI tool or write scripts that aggregate the data, acceptance rates, and per-user metrics for Code Suggestions events.
Data is retained for three months.
For example, to retrieve usage data for all Code Suggestions events for the `gitlab-org` group:
```graphql
query {
group(fullPath: "gitlab-org") {
aiUsageData {
codeSuggestionEvents {
nodes {
event
timestamp
language
suggestionSize
user {
username
}
}
}
}
}
}
```
The query returns the following output:
```graphql
{
"data": {
"group": {
"aiUsageData": {
"codeSuggestionEvents": {
"nodes": [
{
"event": "CODE_SUGGESTION_SHOWN_IN_IDE",
"timestamp": "2024-12-22T18:17:25Z",
"language": null,
"suggestionSize": null,
"user": {
"username": "jasbourne"
}
},
{
"event": "CODE_SUGGESTION_REJECTED_IN_IDE",
"timestamp": "2024-12-22T18:13:45Z",
"language": null,
"suggestionSize": null,
"user": {
"username": "jasbourne"
}
},
{
"event": "CODE_SUGGESTION_ACCEPTED_IN_IDE",
"timestamp": "2024-12-22T18:13:44Z",
"language": null,
"suggestionSize": null,
"user": {
"username": "jasbourne"
}
}
]
}
}
}
}
}
```
## Retrieve AI user metrics
{{< details >}}
- Add-on: GitLab Duo Enterprise
{{< /details >}}
{{< history >}}
- [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/483049) in GitLab 17.6.
{{< /history >}}
The `AiUserMetrics` endpoint provides pre-aggregated per-user metrics for Code Suggestions and GitLab Duo Chat.
You can use this endpoint to list all Duo users and their usage frequency for Code Suggestions and Duo Chat.
Prerequisites:
- You must have ClickHouse configured.
For example, to retrieve the number of accepted Code Suggestions and interactions with Duo Chat for all users
in the `gitlab-org` group:
```graphql
query {
group(fullPath:"gitlab-org") {
aiUserMetrics {
nodes {
codeSuggestionsAcceptedCount
duoChatInteractionsCount
user {
username
}
}
}
}
}
```
The query returns the following output:
```graphql
{
"data": {
"group": {
"aiUserMetrics": {
"nodes": [
{
"codeSuggestionsAcceptedCount": 10,
"duoChatInteractionsCount": 22,
"user": {
"username": "USER_1"
}
},
{
"codeSuggestionsAcceptedCount": 12,
"duoChatInteractionsCount": 30,
"user": {
"username": "USER_2"
}
}
]
}
}
}
}
```
## Retrieve AI impact metrics
{{< details >}}
- Add-on: GitLab Duo Pro
{{< /details >}}
{{< history >}}
- [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/443696) in GitLab 16.11.
- Add-on requirement [changed](https://gitlab.com/gitlab-org/gitlab/-/issues/498497) from GitLab Duo Enterprise to GitLab Duo Pro in GitLab 17.6.
{{< /history >}}
The `AiMetrics` endpoint powers the AI impact analytics dashboard and provides the following pre-aggregated metrics for Code Suggestions and Duo Chat:
- `codeSuggestionsShown`
- `codeSuggestionsAccepted`
- `codeSuggestionAcceptanceRate`
- `codeSuggestionUsers`
- `duoChatUsers`
Prerequisites:
- You must have ClickHouse configured.
For example, to retrieve Code Suggestions and Duo Chat usage data for a specified time period for the `gitlab-org` group:
```graphql
query {
group(fullPath: "gitlab-org") {
aiMetrics(startDate: "2024-12-01", endDate: "2024-12-31") {
codeSuggestions{
shownCount
acceptedCount
acceptedLinesOfCode
shownLinesOfCode
}
codeContributorsCount
duoChatContributorsCount
duoAssignedUsersCount
duoUsedCount
}
}
}
```
The query returns the following output:
```graphql
{
"data": {
"group": {
"aiMetrics": {
"codeSuggestions": {
"shownCount": 88728,
"acceptedCount": 7016,
"acceptedLinesOfCode": 9334,
"shownLinesOfCode": 124118
},
"codeContributorsCount": 719,
"duoChatContributorsCount": 681,
"duoAssignedUsersCount": 1910,
"duoUsedCount": 714
}
}
},
}
```
## Export AI metrics data to CSV
You can export AI metrics data to a CSV file with the
[GitLab AI Metrics Exporter tool](https://gitlab.com/smathur/custom-duo-metrics).

1
doc/api/graphql/examples.md
View File

@ -15,3 +15,4 @@ GraphQL examples are available for you to test and modify.
- [Query users](users_example.md)
- [Use custom emoji](custom_emoji.md)
- [Migrate epic APIs to work items](epic_work_items_api_migration_guide.md)
- [Retrieve AI impact analytics data](ai_impact_analytics.md)

102
doc/ci/docker/buildah_rootless_multi_arch.md Normal file
View File

@ -0,0 +1,102 @@
---
stage: Verify
group: Pipeline Execution
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Use Buildah to build multi-platform images
---
{{< details >}}
- Tier: Free, Premium, Ultimate
- Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
{{< /details >}}
Use Buildah to build images for multiple CPU architectures. Multi-platform builds
create images that work across different hardware platforms, and Docker automatically
selects the appropriate image for each deployment target.
## Prerequisites
- A Dockerfile to build the image from
- (Optional) GitLab runners running on different CPU architectures
## Build multi-platform images
To build multi-platform images with Buildah:
1. Configure separate build jobs for each target architecture.
1. Create a manifest job that combines the architecture-specific images.
1. Configure the manifest job to push the combined manifest to your registry.
Running jobs on their respective architectures avoids performance issues from CPU instruction translation.
However, you can run both builds on a single architecture if needed. Building for non-native architecture may result in slower build times.
The following example uses two [GitLab-hosted runners on Linux](../../ci/runners/hosted_runners/linux.md):
- `saas-linux-small-arm64`
- `saas-linux-small-amd64`
```yaml
stages:
- build
variables:
STORAGE_DRIVER: vfs
BUILDAH_FORMAT: docker
FQ_IMAGE_NAME: "$CI_REGISTRY_IMAGE:latest"
default:
image: quay.io/buildah/stable
before_script:
- echo "$CI_REGISTRY_PASSWORD" | buildah login -u "$CI_REGISTRY_USER" --password-stdin $CI_REGISTRY
build-amd64:
stage: build
tags:
- saas-linux-small-amd64
script:
- buildah build --platform=linux/amd64 -t $CI_REGISTRY_IMAGE:amd64 .
- buildah push $CI_REGISTRY_IMAGE:amd64
build-arm64:
stage: build
tags:
- saas-linux-small-arm64
script:
- buildah build --platform=linux/arm64/v8 -t $CI_REGISTRY_IMAGE:arm64 .
- buildah push $CI_REGISTRY_IMAGE:arm64
create_manifest:
stage: build
needs: ["build-arm64", "build-amd64"]
tags:
- saas-linux-small-amd64
script:
- buildah manifest create $FQ_IMAGE_NAME
- buildah manifest add $FQ_IMAGE_NAME docker://$CI_REGISTRY_IMAGE:amd64
- buildah manifest add $FQ_IMAGE_NAME docker://$CI_REGISTRY_IMAGE:arm64
- buildah manifest push --all $FQ_IMAGE_NAME
```
This pipeline creates architecture-specific images tagged with `amd64` and `arm64`,
then combines them into a single manifest available under the `latest` tag.
## Troubleshooting
### Build fails with authentication errors
If you encounter registry authentication failures:
- Verify that `CI_REGISTRY_USER` and `CI_REGISTRY_PASSWORD` variables are available.
- Check that you have push permissions to the target registry.
- For external registries, ensure authentication credentials are correctly configured
in your project's CI/CD variables.
### Multi-platform builds fail
For multi-platform build issues:
- Verify that base images in your `Dockerfile` support the target architectures.
- Check that architecture-specific dependencies are available for all target platforms.
- Consider using conditional statements in your `Dockerfile` for architecture-specific logic.

2
doc/development/contributing/design.md
View File

@ -67,7 +67,7 @@ Check visual design properties using your browser's elements inspector ([Chrome]
- Follow [layout guidelines](https://design.gitlab.com/product-foundations/layout#grid).
- Use existing [icons](https://gitlab-org.gitlab.io/gitlab-svgs/) and [illustrations](https://gitlab-org.gitlab.io/gitlab-svgs/illustrations/)
or propose new ones according to [iconography](https://design.gitlab.com/product-foundations/iconography/)
and [illustration](https://design.gitlab.com/product-foundations/illustration/)
and [illustration](https://design.gitlab.com/product-foundations/illustration-creation-guide/)
guidelines.
- Optional: Consider dark mode. For more information, see [Change the mode](../../user/profile/preferences.md#change-the-mode).

2
doc/development/merge_request_concepts/_index.md
View File

@ -64,6 +64,6 @@ Examples of approval rules and settings include:
- [Merge request approval rules](../../user/project/merge_requests/approvals/rules.md)
- [Code owner approvals](../../user/project/codeowners/_index.md)
- [Security approvals](../../user/application_security/_index.md#security-approvals-in-merge-requests)
- [Security approvals](../../user/application_security/policies/merge_request_approval_policies.md)
- [Prevent editing approval rules](../../user/project/merge_requests/approvals/settings.md#prevent-editing-approval-rules-in-merge-requests)
- [Remove all approvals when commits are added](../../user/project/merge_requests/approvals/settings.md#remove-all-approvals-when-commits-are-added-to-the-source-branch)

2
doc/development/sec/_index.md
View File

@ -58,7 +58,7 @@ After the data is available as a Report Artifact it can be processed by the GitL
- [Security Dashboards](../../user/application_security/security_dashboard/_index.md), Merge Request widget, Pipeline view, and so on.
- [Security scan results](../../user/application_security/detect/security_scan_results.md).
- [Approval rules](../../user/application_security/_index.md#security-approvals-in-merge-requests).
- [Approval rules](../../user/application_security/policies/merge_request_approval_policies.md).
Depending on the context, the security reports may be stored either in the database or stay as Report Artifacts for on-demand access.

16
doc/user/analytics/ai_impact_analytics.md
View File

@ -54,6 +54,13 @@ It is calculated as the number of accepted code suggestions divided by the total
- **Duo Chat: Unique users**: Percentage of users that engage with GitLab Duo Chat every month.
It is calculated as the number of monthly unique GitLab Duo Chat users divided by the total GitLab Duo assigned users.
{{< alert type="note" >}}
For tracking Code Suggestions events, GitLab collects data only from code editor extensions.
[Epic 14203](https://gitlab.com/groups/gitlab-org/-/epics/14203) proposes support for the Web IDE as well.
{{< /alert >}}
## Metric trends
The **Metric trends** table displays metrics for the last six months, with monthly values, percentage changes in the past six months, and trend sparklines.
@ -70,10 +77,13 @@ The **Metric trends** table displays metrics for the last six months, with month
**Code Suggestions usage**: Monthly user engagement with AI Code Suggestions.
The month-over-month comparison of the AI Usage unique users rate gives a more accurate indication of this metric,
On GitLab.com, data updates every fives minutes.
GitLab counts Code Suggestions usage only if the user has pushed code to the project in the current month.
The month-over-month comparison of the AI Usage unique users rate gives a more accurate indication Code Suggestion usage,
because it eliminates factors such as developer experience level and project type or complexity.
The baseline for the AI Usage trend is the total number of code contributors, not just users with GitLab Duo seats.
The baseline for the AI Usage trend is the total number of code contributors, not only users with GitLab Duo seats.
This baseline gives a more accurate representation of AI usage by team members.
To analyze the performance of teams that use AI versus teams that don't, you can create a custom
@ -92,7 +102,7 @@ For more information, see [epic 12978](https://gitlab.com/groups/gitlab-org/-/ep
Prerequisites:
- [Code Suggestions](../project/repository/code_suggestions/_index.md) must be enabled.
- [ClickHouse for contribution analytics](../group/contribution_analytics/_index.md#contribution-analytics-with-clickhouse) must be configured.
- For GitLab Self-Managed, [ClickHouse for contribution analytics](../group/contribution_analytics/_index.md#contribution-analytics-with-clickhouse) must be configured.
1. On the left sidebar, select **Search or go to** and find your project or group.
1. Select **Analyze > Analytics Dashboards**.

140
doc/user/application_security/_index.md
View File

@ -2,125 +2,73 @@
stage: Application Security Testing
group: Static Analysis
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
title: Application security
title: 'Application security testing'
description: Scanning, vulnerabilities, compliance, customization, and reporting.
---
{{< details >}}
- Tier: Ultimate
- Tier: Free, Premium, Ultimate
- Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
{{< /details >}}
Build security into your development process with GitLab security scanning capabilities. Identify
and address vulnerabilities early in your development lifecycle, before they reach production
environments.
Build security into your development process with GitLab application security testing capabilities.
These features help you identify and address vulnerabilities early in your development lifecycle,
before they reach production environments.
GitLab detects security vulnerabilities throughout your code, dependencies, containers, and deployed
applications, including:
GitLab application security testing provides comprehensive coverage of both repository content and
deployed applications, enabling you to detect potential security issues throughout your software
development lifecycle.
- Unauthorized access points
- Potential data leaks
- Denial of Service (DoS) vulnerabilities
- Supply chain weaknesses
GitLab also helps reduce the risk of vulnerabilities being introduced through several protective
mechanisms:
Secret push protection
: Blocks secrets such as keys and API tokens from being pushed to GitLab.
Merge request approval policies
: Enforce an additional approval on merge requests that would introduce vulnerabilities.
## How application security testing works
GitLab detects security vulnerabilities throughout your code, dependencies, containers, and
deployed applications. Your project's repository and your application's behavior are scanned for
vulnerabilities.
Security findings appear directly in merge requests, providing actionable information before code is
merged. This proactive approach reduces the cost and effort of fixing issues later in development.
For security teams, GitLab security dashboard centralizes vulnerability findings, making
prioritization and remediation tracking more straightforward. For developers, the merge request
integration means fewer context switches and more efficient workflows.
Application security testing can run in several contexts:
For a click-through demo, see [Integrating security to the pipeline](https://gitlab.navattic.com/gitlab-scans).
<!-- Demo published on 2024-01-15 -->
During development
: Automated scans run as part of CI/CD pipelines when code is committed or merge requests are
created.
## Data privacy
Outside development
: Security testing can be run manually on-demand or scheduled to run at regular intervals.
Concerning data privacy in the domain of security scanners, GitLab processes the source code and performs analysis locally on the GitLab Runner. No data is transmitted outside GitLab infrastructure (server and runners).
## Vulnerability management lifecycle
Our scanners access the internet only to download the latest sets of signatures, rules, and patches. If you prefer the scanners do not access the internet, consider using an [offline environment](offline_deployments/_index.md).
GitLab assists in the complete vulnerability management lifecycle through key phases:
## Security scanning
[Detect](detect/_index.md)
: Identify vulnerabilities through automated scanning and security testing.
For security scans that run in a CI/CD pipeline, the results are determined by:
[Triage](triage/_index.md)
: Evaluate and prioritize vulnerabilities to determine which need immediate attention and which
can be addressed later.
- Which security scanning jobs run in the pipeline.
- Each job's status.
- Each job's output.
[Analyze](analyze/_index.md)
: Conduct detailed analysis of confirmed vulnerabilities to understand their impact and determine
appropriate remediation strategies.
### Security jobs in your pipeline
[Remediate](remediate/_index.md)
: Fix the root cause of vulnerabilities or implement appropriate risk mitigation measures.
The security scanning jobs that run in a CI/CD pipeline are determined by the following criteria:
Vulnerabilities are centralized in the vulnerability report and security dashboard, making
prioritization and remediation tracking more straightforward for security teams.
1. Inclusion of security scanning templates
## Get started
The selection of security scanning jobs is first determined by which templates are included.
Templates can be included by using AutoDevOps, a scan execution policy, or the
`.gitlab-ci.yml` configuration file.
1. Evaluation of rules
Each template has defined [rules](../../ci/yaml/_index.md#rules) which determine if the analyzer
is run.
For example, the Secret Detection template includes the following rule. This rule states that
secret detection should be run in branch pipelines. In the case of a merge request pipeline,
secret detection is not run.
```yaml
rules:
- if: $CI_COMMIT_BRANCH
```
1. Analyzer logic
If the template's rules dictate that the job is to be run, a job is created in the pipeline stage
specified in the template. However, each analyzer has its own logic which determines if the
analyzer itself is to be run.
For example, if dependency scanning doesn't detect supported files at the default depth, the
analyzer is not run and no artifacts are output.
After completing successfully, each job outputs artifacts. These artifacts are processed and the
results are available in GitLab. Results are shown only if all jobs are finished, including manual
ones. Additionally for some features, results are shown only if the pipeline runs on the default branch.
#### Job status
Jobs pass if they are able to complete a scan. A pass result does not indicate if they did, or did not, identify findings. The only exception is coverage fuzzing, which fails if it identifies findings.
Jobs fail if they are unable to complete a scan. You can view the pipeline logs for more information.
All jobs are permitted to fail by default. This means that if they fail, it does not fail the pipeline.
If you want to prevent vulnerabilities from being merged, you should do this by adding [Security Approvals in Merge Requests](#security-approvals-in-merge-requests) which prevents unknown, high or critical findings from being merged without an approval from a specific group of people that you choose.
We do not recommend changing the job [`allow_failure` setting](../../ci/yaml/_index.md#allow_failure) as that fails the entire pipeline.
#### Job artifacts
A security scan job may generate one or more artifacts. From GitLab 17.0, these artifacts are
restricted to the [`developer` role](../permissions.md#roles).
The security report artifact generated by the secure analyzer contains all findings it discovers on the target branch, regardless of whether they were previously found, dismissed, or completely new (it puts in everything that it finds).
## Security approvals in merge requests
{{< history >}}
- [Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/357300) the Vulnerability-Check feature in GitLab 15.0.
- [Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/397067) the License-Check feature in GitLab 16.0.
{{< /history >}}
You can enforce an additional approval for merge requests that would introduce one of the following
security issues:
- A security vulnerability. For more details, read [Merge request approval policies](policies/merge_request_approval_policies.md).
## Self managed installation options
For GitLab Self-Managed instances, you can choose to run most of the GitLab security scanners even when [not connected to the internet](offline_deployments/_index.md).
GitLab Self-Managed instances can also run the security scanners on a GitLab Runner [running inside OpenShift](../../install/openshift_and_gitlab/_index.md).
To get started, see [Get started securing your application](get-started-security.md).

18
doc/user/permissions.md
View File

@ -494,18 +494,18 @@ Project permissions for [wikis](project/wiki/_index.md):
Project permissions for [container registry](packages/_index.md):
| Action | Guest | Planner | Reporter | Developer | Maintainer | Owner | |
| ------------------------------------------------------------------------------------------------- | :---: | :-----: | :------: | :-------: | :--------: | :---: |
| Pull an image from the container registry <sup>1</sup> | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Push an image to the container registry | x | x | x | ✓ | ✓ | ✓ |
| Delete a container registry image | x | x | x | ✓ | ✓ | ✓ |
| Manage cleanup policies | x | x | x | x | ✓ | ✓ |
| Create [tag protection](packages/container_registry/protected_container_tags.md) rule | x | x | x | x | ✓ | ✓ |
| Create [immutable tag protection](packages/container_registry/immutable_container_tags.md) rule | x | x | x | x | x | ✓ |
| Action | Guest | Planner | Reporter | Developer | Maintainer | Owner | Notes |
|-------------------------------------------------------------------------------------------------|:-----:|:-------:|:--------:|:---------:|:----------:|:-----:|-------|
| Pull an image from the container registry <sup>1</sup> | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
| Push an image to the container registry | | | | ✓ | ✓ | ✓ | |
| Delete a container registry image | | | | ✓ | ✓ | ✓ | |
| Manage cleanup policies | | | | | ✓ | ✓ | |
| Create [tag protection](packages/container_registry/protected_container_tags.md) rule | | | | | ✓ | ✓ | |
| Create [immutable tag protection](packages/container_registry/immutable_container_tags.md) rule | | | | | | ✓ | |
**Footnotes**:
1. Viewing the container registry and pulling images is controlled by [container registry visibility permissions](packages/container_registry/_index.md#container-registry-visibility-permissions).
1. Viewing the container registry and pulling images is controlled by [container registry visibility permissions](packages/container_registry/_index.md#container-registry-visibility-permissions).
Project permissions for [package registry](packages/_index.md):

2
doc/user/project/merge_requests/approvals/_index.md
View File

@ -76,7 +76,7 @@ Use cases include:
- Specify categories of reviewers, such as backend, frontend, quality assurance, database, or documentation.
- Use the [Code Owners](../../codeowners/_index.md) files to determine reviewers.
- Require approval for [declining test coverage](../../../../ci/testing/code_coverage/_index.md#add-a-coverage-check-approval-rule).
- GitLab Ultimate: [Require security team approval](../../../application_security/_index.md#security-approvals-in-merge-requests) for potential vulnerabilities.
- GitLab Ultimate: [Require security team approval](../../../application_security/policies/merge_request_approval_policies.md) for potential vulnerabilities.
## View approval status