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-01-22 18:36:40 +00:00
parent 5a748c05a8
commit 95e715a492
109 changed files with 2255 additions and 1253 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.gitlab-ci.yml
View File

@ -132,7 +132,7 @@ workflow:
<<: [*default-ruby-variables, *default-branch-pipeline-failure-variables]
CRYSTALBALL: "true"
PIPELINE_NAME: 'Scheduled Ruby $RUBY_VERSION $CI_COMMIT_BRANCH branch'
- if: '$CI_COMMIT_BRANCH == "ruby3_3" && $CI_PIPELINE_SOURCE == "schedule"'
- if: '$CI_COMMIT_BRANCH == "ruby-next" && $CI_PIPELINE_SOURCE == "schedule"'
variables:
<<: *next-ruby-variables
PIPELINE_NAME: 'Scheduled Ruby $RUBY_VERSION $CI_COMMIT_BRANCH branch'

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

@ -30,7 +30,7 @@
|| $CI_COMMIT_REF_NAME =~ /^[\d-]+-stable(-ee)?$/
|| $CI_COMMIT_REF_NAME =~ /^\d+-\d+-auto-deploy-\d+$/
|| $CI_COMMIT_REF_NAME =~ /^security\//
|| $CI_COMMIT_REF_NAME =~ /^ruby\d+(_\d)*$/
|| $CI_COMMIT_REF_NAME =~ /^ruby-next$/
)
)
||
@ -181,7 +181,7 @@
if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_TYPE == "nightly"'
.if-ruby-branch-schedule-nightly: &if-ruby-branch-schedule-nightly
if: '$CI_COMMIT_BRANCH =~ /^ruby\d+(_\d)*$/ && $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_TYPE == "nightly"'
if: '$CI_COMMIT_BRANCH == "ruby-next" && $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_TYPE == "nightly"'
.if-security-schedule: &if-security-schedule
if: '$CI_PROJECT_NAMESPACE == "gitlab-org/security" && $CI_PIPELINE_SOURCE == "schedule"'
@ -214,7 +214,7 @@
if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_EVENT_TYPE == "merge_train" && $CI_SERVER_HOST == "gitlab.com" && $CI_PROJECT_NAMESPACE =~ /^gitlab-org/'
.if-ruby-branch: &if-ruby-branch
if: '$CI_COMMIT_BRANCH =~ /^ruby\d+(_\d)*$/ || (($CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_EVENT_TYPE != "merge_train") && $CI_MERGE_REQUEST_LABELS =~ /pipeline:run-in-ruby\d+(_\d)*/)'
if: '$CI_COMMIT_BRANCH == "ruby-next" || (($CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_EVENT_TYPE != "merge_train") && $CI_MERGE_REQUEST_LABELS =~ /pipeline:run-in-ruby\d+(_\d)*/)'
.if-observability-skip-e2e-jobs: &if-observability-skip-e2e-jobs
if: '$SKIP_GITLAB_OBSERVABILITY_BACKEND_TRIGGER || $GITLAB_OBSERVABILITY_BACKEND_PIPELINE_TRIGGER_TOKEN == null || $GITLAB_OBSERVABILITY_BACKEND_TOKEN_FOR_CI_SCRIPTS == null'

40
CHANGELOG.md
View File

@ -2,6 +2,15 @@
documentation](doc/development/changelog.md) for instructions on adding your own
entry.
## 17.8.1 (2025-01-22)
### Security (4 changes)
- [Fix protected variable exfiltration](https://gitlab.com/gitlab-org/security/gitlab/-/commit/998874eb0ed029872a47991788565213aa6707b8) ([merge request](https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/4713))
- [Enhance rich viewer sanitization](https://gitlab.com/gitlab-org/security/gitlab/-/commit/895088208f7a39aad0bd9cd8dbec8cf6b8f8f1f3) ([merge request](https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/4708))
- [Avoid recursive sidekiq calls on cyclic work item hierarchies](https://gitlab.com/gitlab-org/security/gitlab/-/commit/1872a670e73e294db21773d8289bc51c6b9ec9aa) ([merge request](https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/4711))
- [Respect the private profile constraints](https://gitlab.com/gitlab-org/security/gitlab/-/commit/f434b2e5d6542b3d762852a725a19780d6966db1) ([merge request](https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/4704))
## 17.8.0 (2025-01-15)
### Added (127 changes)
@ -458,6 +467,19 @@ entry.
- [Remove default on `group_saved_replies_flag feature flag](https://gitlab.com/gitlab-org/gitlab/-/commit/75d49fe13646e1e0d3b68233ac4a965c86853917) ([merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/175647))
- [Remove use_actual_plan_in_license_check flag](https://gitlab.com/gitlab-org/gitlab/-/commit/b8c3fe16aedb69c82ff52d1c695d72e933c4b946) ([merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/175649))
## 17.7.3 (2025-01-22)
### Fixed (1 change)
- [Add BoardEpicConnection type policy for pagination](https://gitlab.com/gitlab-org/security/gitlab/-/commit/f49b4349cecbbca2629e4abf9e2746d48537f350) **GitLab Enterprise Edition**
### Security (4 changes)
- [Fix protected variable exfiltration](https://gitlab.com/gitlab-org/security/gitlab/-/commit/ed6f52bb29b7dc1d6fad13c8d62725aa3a3c7283) ([merge request](https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/4714))
- [Enhance rich viewer sanitization](https://gitlab.com/gitlab-org/security/gitlab/-/commit/68187f7e86b936d1d361c78160b3855db7ffa495) ([merge request](https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/4709))
- [Avoid recursive sidekiq calls on cyclic work item hierarchies](https://gitlab.com/gitlab-org/security/gitlab/-/commit/77692306d5122b9a3006667a4bbd695f4e983a33) ([merge request](https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/4673))
- [Respect the private profile constraints](https://gitlab.com/gitlab-org/security/gitlab/-/commit/325eea0ef21773481a0aa753cffacf05a835acbc) ([merge request](https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/4698))
## 17.7.2 (2025-01-14)
### Fixed (1 change)
@ -1296,6 +1318,24 @@ entry.
- [Finalize migration BackfillMlExperimentMetadataProjectId](https://gitlab.com/gitlab-org/gitlab/-/commit/0768d34e5d66ec56aa9104206120d2b691d3781f) ([merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/172003))
- [Finalize migration BackfillDastSiteValidationsProjectId](https://gitlab.com/gitlab-org/gitlab/-/commit/edb777429d66afe879a5bb8d4652a610eb39eb7c) ([merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/171199))
## 17.6.4 (2025-01-22)
### Fixed (2 changes)
- [Add BoardEpicConnection type policy for pagination](https://gitlab.com/gitlab-org/security/gitlab/-/commit/0fc02660321fef5d2fee627bd9b81c0aaca62a82) **GitLab Enterprise Edition**
- [Fix handling of short gzip metadata files](https://gitlab.com/gitlab-org/security/gitlab/-/commit/09c5801a07e2dcbd48a44ea97cb56aa6fb141105)
### Security (4 changes)
- [Fix protected variable exfiltration](https://gitlab.com/gitlab-org/security/gitlab/-/commit/da2d664ff802e6c961a8e463f39d5b7f179ba0f7) ([merge request](https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/4715))
- [Enhance rich viewer sanitization](https://gitlab.com/gitlab-org/security/gitlab/-/commit/fca347dbd3660d89b1a58d39e1cf4ce680363988) ([merge request](https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/4710))
- [Avoid recursive sidekiq calls on cyclic work item hierarchies](https://gitlab.com/gitlab-org/security/gitlab/-/commit/db1de035fb5ddfee1849a411020f22f5808e811b) ([merge request](https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/4660))
- [Respect the private profile constraints](https://gitlab.com/gitlab-org/security/gitlab/-/commit/e834095ace85698c4c32f915e280158bb0ae9e88) ([merge request](https://gitlab.com/gitlab-org/security/gitlab/-/merge_requests/4699))
### Other (1 change)
- [Reorder migrations for ci_deleted_objects](https://gitlab.com/gitlab-org/security/gitlab/-/commit/313e91e2a458db2ebcab4a8bb57384467ee295be)
## 17.6.3 (2025-01-08)
### Fixed (2 changes)

2
app/assets/javascripts/ide/lib/themes/monokai.js
View File

@ -1,6 +1,6 @@
/*
https://github.com/brijeshb42/monaco-themes/blob/master/themes/Tomorrow-Night.json
https://github.com/brijeshb42/monaco-themes/blob/master/themes/Monokai.json
The MIT License (MIT)

5
app/assets/javascripts/vue_shared/components/blob_viewers/rich_viewer.vue
View File

@ -3,7 +3,7 @@ import SafeHtml from '~/vue_shared/directives/safe_html';
import { handleBlobRichViewer } from '~/blob/viewer';
import MarkdownFieldView from '~/vue_shared/components/markdown/field_view.vue';
import { handleLocationHash } from '~/lib/utils/common_utils';
import { sanitize } from '~/lib/dompurify';
import { sanitize, defaultConfig } from '~/lib/dompurify';
import ViewerMixin from './mixins';
import {
MARKUP_FILE_TYPE,
@ -98,7 +98,8 @@ export default {
},
},
safeHtmlConfig: {
ADD_TAGS: ['gl-emoji', 'copy-code'],
...defaultConfig,
FORBID_ATTR: [...defaultConfig.FORBID_ATTR, 'style', 'data-lines-path'],
},
};
</script>

1
app/models/award_emoji.rb
View File

@ -28,6 +28,7 @@ class AwardEmoji < ApplicationRecord
scope :upvotes, -> { named(UPVOTE_NAME) }
scope :named, ->(names) { where(name: names) }
scope :awarded_by, ->(users) { where(user: users) }
scope :by_awardable, ->(type, ids) { where(awardable_type: type, awardable_id: ids) }
after_destroy :expire_cache
after_save :expire_cache

4
app/models/concerns/user_mention_behaviour.rb
View File

@ -3,6 +3,10 @@
module UserMentionBehaviour # rubocop:disable Gitlab/BoundedContexts -- Module is a functional mimic of an existing model
extend ActiveSupport::Concern
included do
scope :for_notes, ->(notes) { where(note_id: notes) }
end
def has_mentions?
mentioned_users_ids.present? || mentioned_groups_ids.present? || mentioned_projects_ids.present?
end

1
app/models/system_note_metadata.rb
View File

@ -38,6 +38,7 @@ class SystemNoteMetadata < ApplicationRecord
belongs_to :note
belongs_to :description_version
scope :for_notes, ->(notes) { where(note_id: notes) }
delegate_missing_to :note
def declarative_policy_delegate

22
app/services/tags/destroy_service.rb
View File

@ -14,19 +14,19 @@ module Tags
return error("You don't have access to delete the tag") unless allowed_to_delete?(tag)
end
if repository.rm_tag(current_user, tag_name)
# When a tag in a repository is destroyed, release assets will be
# destroyed too.
destroy_releases(tag_name)
repository.rm_tag(current_user, tag_name)
unlock_artifacts(tag_name)
# When a tag in a repository is destroyed, release assets will be
# destroyed too.
destroy_releases(tag_name)
success('Tag was removed')
else
error('Failed to remove tag')
end
unlock_artifacts(tag_name)
success('Tag was removed')
rescue Gitlab::Git::PreReceiveError => ex
error(ex.message)
rescue Gitlab::Git::CommandError
failed_to_remove_tag_error
end
def error(message, return_code = 400)
@ -43,6 +43,10 @@ module Tags
Ability.allowed?(current_user, :delete_tag, tag)
end
def failed_to_remove_tag_error
error('Failed to remove tag')
end
def destroy_releases(tag_name)
Releases::DestroyService.new(project, current_user, tag: tag_name).execute
end

156
app/services/work_items/data_sync/handlers/notes/copy_service.rb Normal file
View File

@ -0,0 +1,156 @@
# frozen_string_literal: true
# This service copies Notes from one Noteable to another.
#
# It expects the calling code to have performed the necessary authorization
# checks in order to allow the copy to happen.
module WorkItems
module DataSync
module Handlers
module Notes
class CopyService
BATCH_SIZE = 50
def initialize(current_user, source_noteable, target_noteable)
@current_user = current_user
@source_noteable = source_noteable
@target_noteable = target_noteable
@source_parent = source_noteable.resource_parent
@target_parent = target_noteable.resource_parent
end
def execute
return ServiceResponse.error(message: 'Noteables must be different') if source_noteable == target_noteable
source_noteable.notes_with_associations.each_batch(of: BATCH_SIZE) do |notes_batch|
next if notes_batch.empty?
Note.transaction do
notes_ids_map = allocate_new_ids(notes_batch, :id, 'notes_id_seq')
::Note.insert_all(new_notes(notes_batch, notes_ids_map))
copy_notes_emoji(notes_ids_map)
copy_notes_metadata(notes_ids_map)
copy_notes_user_mentions(notes_ids_map)
end
end
ServiceResponse.success
end
private
attr_reader :current_user, :source_noteable, :target_noteable, :source_parent, :target_parent
def copy_notes_emoji(notes_ids_map)
notes_emoji = ::AwardEmoji.by_awardable('Note', notes_ids_map.keys)
::AwardEmoji.insert_all(new_notes_emoji(notes_emoji, notes_ids_map)) if notes_emoji.any?
end
def copy_notes_metadata(notes_ids_map)
notes_metadata = ::SystemNoteMetadata.for_notes(notes_ids_map.keys)
desc_versions_metadata = notes_metadata.filter_map do |metadata|
metadata if metadata.description_version_id.present?
end
sequence_name = 'description_versions_id_seq'
desc_version_ids_map = allocate_new_ids(desc_versions_metadata, :description_version_id, sequence_name)
DescriptionVersion.insert_all(new_desc_versions(desc_version_ids_map)) if desc_version_ids_map.present?
return if notes_metadata.blank?
::SystemNoteMetadata.insert_all(new_notes_metadata(notes_metadata, notes_ids_map, desc_version_ids_map))
end
def allocate_new_ids(collection, column_name, sequence_name)
return {} if collection.blank?
# rubocop: disable CodeReuse/ActiveRecord, Database/AvoidUsingPluckWithoutLimit -- collection size is limited
ids = collection.pluck(column_name)
# rubocop: enable CodeReuse/ActiveRecord, Database/AvoidUsingPluckWithoutLimit
bind1 = ActiveRecord::Relation::QueryAttribute.new("sequence", sequence_name, ActiveRecord::Type::Value.new)
bind2 = ActiveRecord::Relation::QueryAttribute.new("size", ids.size, ActiveRecord::Type::Value.new)
allocated_ids = ApplicationRecord.connection.select_values(
"SELECT NEXTVAL($1) from GENERATE_SERIES(1, $2)", "allocate_ids", [bind1, bind2]
)
ids.zip(allocated_ids).to_h
end
def new_notes(notes_batch, notes_ids_map)
notes_batch.map do |note|
note.attributes.tap do |attrs|
attrs['id'] = notes_ids_map[note.id]
attrs['noteable_id'] = target_noteable.id
# we want this if we want to use this also to copy notes when promoting issue to epic
attrs['noteable_type'] = target_noteable.class.base_class
# need to use `try` to be able to handle Issue model and legacy Epic model instances
attrs['project_id'] = target_noteable.try(:project_id)
attrs['namespace_id'] = target_noteable.try(:namespace_id) || target_noteable.try(:group_id)
attrs['imported_from'] = 'none' # maintaining current copy notes implementation
# this data is not changed, but it is being serialized and we need it deserialized for bulk inserts
attrs['position'] = note.attributes_before_type_cast['position']
attrs['original_position'] = note.attributes_before_type_cast['original_position']
attrs['change_position'] = note.attributes_before_type_cast['change_position']
attrs['st_diff'] = note.attributes_before_type_cast['st_diff']
attrs['cached_markdown_version'] = note.cached_markdown_version
sanitized_note_params = sanitized_note_params(note)
attrs['note'] = sanitized_note_params['note']
attrs['note_html'] = sanitized_note_params['note_html']
end
end
end
def new_notes_emoji(notes_emoji, notes_ids_map)
notes_emoji.map do |note_emoji|
note_emoji.attributes.except('id').tap do |attrs|
attrs['awardable_id'] = notes_ids_map[note_emoji.awardable_id]
end
end
end
def new_desc_versions(description_version_ids_map)
DescriptionVersion.id_in(description_version_ids_map.keys).map do |description_version|
description_version.attributes.tap do |attrs|
attrs['id'] = description_version_ids_map[description_version.id]
attrs['issue_id'] = target_noteable.id
end
end
end
def new_notes_metadata(system_notes_metadata, notes_ids_map, description_version_ids_map)
system_notes_metadata.map do |note_metadata|
note_metadata.attributes.except('id').tap do |attrs|
attrs['note_id'] = notes_ids_map[note_metadata.note_id]
attrs['description_version_id'] = description_version_ids_map[note_metadata.description_version_id]
end
end
end
def copy_notes_user_mentions(notes_ids_map)
# rebuild user mentions for newly inserted notes
new_user_mentions = new_user_mentions(notes_ids_map)
target_noteable.user_mention_class.insert_all(new_user_mentions) if new_user_mentions.any?
end
def new_user_mentions(notes_ids_map)
source_noteable.user_mentions.for_notes(notes_ids_map.keys).map do |user_mention|
user_mention.attributes.except('id').tap do |attrs|
attrs['issue_id'] = target_noteable.id
attrs['note_id'] = notes_ids_map[user_mention.note_id]
end
end
end
def sanitized_note_params(note)
MarkdownContentRewriterService.new(current_user, note, :note, source_parent, target_parent).execute
end
end
end
end
end
end

21
app/services/work_items/data_sync/widgets/notes.rb
View File

@ -5,13 +5,26 @@ module WorkItems
module Widgets
class Notes < Base
def after_save_commit
# copy notes and resource events
# ::Notes::CopyService.new(current_user, work_item, target_work_item).execute
# ::Gitlab::Issuable::Clone::CopyResourceEventsService.new(current_user, work_item, target_work_item).execute
return if params[:operation] == :clone && !params[:clone_with_notes]
# Copying resource events regardless of notes widget being enabled as besides generating system notes
# some of the resource events are also used to generate burn-down/burn-up charts.
::Gitlab::Issuable::Clone::CopyResourceEventsService.new(current_user, work_item, target_work_item).execute
return unless target_work_item.get_widget(:notes)
# copy notes
::WorkItems::DataSync::Handlers::Notes::CopyService.new(current_user, work_item, target_work_item).execute
end
def post_move_cleanup
# do it
work_item.notes_with_associations.each_batch(of: BATCH_SIZE) do |notes_batch|
# we need to explicitly delete AwardEmoji records for given notes, because there is no FK to take
# care of cascade deleting AwardEmoji records when deleting a note.
::AwardEmoji.by_awardable('Note', notes_batch.select(:id)).delete_all
# Upon note deletion FK cascade delete will also delete other records linked to the given note record.
::Note.id_in(notes_batch.select(:id)).delete_all
end
end
end
end

1
app/views/users/_profile_sidebar.html.haml
View File

@ -27,6 +27,7 @@
- user_local_time = local_time(@user.timezone)
%div{ itemprop: 'address', itemscope: true, itemtype: 'https://schema.org/PostalAddress' }
- unless @user.private_profile?
%h2.gl-text-base.gl-mb-2.gl-mt-4= s_('UserProfile|Info')
- if work_information(@user).present?
.gl-flex.gl-gap-2.gl-mb-2

2
config/sidekiq_queues.yml
View File

@ -789,6 +789,8 @@
- 1
- - search_zoekt_delete_project_event
- 1
- - search_zoekt_index_mark_as_pending_eviction_event
- 1
- - search_zoekt_index_marked_as_ready_event
- 1
- - search_zoekt_index_marked_as_to_delete_event

4
data/deprecations/14-5-certificate-based-integration-with-kubernetes-saas.yml
View File

@ -1,9 +1,9 @@
- title: "SaaS certificate-based integration with Kubernetes"
- title: "GitLab.com certificate-based integration with Kubernetes"
announcement_milestone: "14.5"
removal_milestone: "15.9"
breaking_change: true
body: |
The certificate-based integration with Kubernetes will be [deprecated and removed](https://about.gitlab.com/blog/2021/11/15/deprecating-the-cert-based-kubernetes-integration/). As a GitLab SaaS customer, on new namespaces, you will no longer be able to integrate GitLab and your cluster using the certificate-based approach as of GitLab 15.0. The integration for current users will be enabled per namespace.
The certificate-based integration with Kubernetes will be [deprecated and removed](https://about.gitlab.com/blog/2021/11/15/deprecating-the-cert-based-kubernetes-integration/). As a GitLab.com user, on new namespaces, you will no longer be able to integrate GitLab and your cluster using the certificate-based approach as of GitLab 15.0. The integration for current users will be enabled per namespace.
For a more robust, secure, forthcoming, and reliable integration with Kubernetes, we recommend you use the
[agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/) to connect Kubernetes clusters with GitLab. [How do I migrate?](https://docs.gitlab.com/ee/user/infrastructure/clusters/migrate_to_gitlab_agent.html)

4
data/deprecations/14-5-certificate-based-integration-with-kubernetes.yml
View File

@ -1,4 +1,4 @@
- title: "Self-managed certificate-based integration with Kubernetes"
- title: "GitLab Self-Managed certificate-based integration with Kubernetes"
announcement_milestone: "14.5"
removal_milestone: "19.0"
breaking_change: true
@ -9,7 +9,7 @@
body: |
The certificate-based integration with Kubernetes [will be deprecated and removed](https://about.gitlab.com/blog/2021/11/15/deprecating-the-cert-based-kubernetes-integration/).
As a self-managed customer, we are introducing the [feature flag](https://docs.gitlab.com/ee/administration/feature_flags.html#enable-or-disable-the-feature) `certificate_based_clusters` in GitLab 15.0 so you can keep your certificate-based integration enabled. However, the feature flag will be disabled by default, so this change is a **breaking change**.
For GitLab Self-Managed, we are introducing the [feature flag](https://docs.gitlab.com/ee/administration/feature_flags.html#enable-or-disable-the-feature) `certificate_based_clusters` in GitLab 15.0 so you can keep your certificate-based integration enabled. However, the feature flag will be disabled by default, so this change is a **breaking change**.
In GitLab 18.0 we will remove both the feature and its related code. Until the final removal in 18.0, features built on this integration will continue to work, if you enable the feature flag. Until the feature is removed, GitLab will continue to fix security and critical issues as they arise.

2
data/deprecations/15-8-deprecate-gitlabcom-importer.yml
View File

@ -8,7 +8,7 @@
The GitLab.com importer was deprecated in GitLab 15.8 and will be removed in GitLab 16.0.
The GitLab.com importer was introduced in 2015 for importing a project from GitLab.com to a GitLab Self-Managed instance through the UI.
This feature is available on self-managed instances only. [Migrating GitLab groups and projects by direct transfer](https://docs.gitlab.com/ee/user/group/import/#migrate-groups-by-direct-transfer-recommended)
This feature is available on GitLab Self-Managed only. [Migrating GitLab groups and projects by direct transfer](https://docs.gitlab.com/ee/user/group/import/#migrate-groups-by-direct-transfer-recommended)
supersedes the GitLab.com importer and provides a more cohesive importing functionality.
See [migrated group items](https://docs.gitlab.com/ee/user/group/import/#migrated-group-items) and [migrated project items](https://docs.gitlab.com/ee/user/group/import/#migrated-project-items) for an overview.

2
data/deprecations/15-8-jira-connect-app-cookie-auth.yml
View File

@ -7,6 +7,6 @@
issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/387299 # (required) Link to the deprecation issue in GitLab
body: | # (required) Do not modify this line, instead modify the lines below.
Cookie authentication in the GitLab for Jira Cloud app is now deprecated in favor of OAuth authentication.
On self-managed, you must [set up OAuth authentication](https://docs.gitlab.com/ee/integration/jira/connect-app.html#set-up-oauth-authentication-for-self-managed-instances)
On GitLab Self-Managed, you must [set up OAuth authentication](https://docs.gitlab.com/ee/integration/jira/connect-app.html#set-up-oauth-authentication-for-self-managed-instances)
to continue to use the GitLab for Jira Cloud app. Without OAuth, you can't manage linked namespaces.
tiers: [Core, Premium, Ultimate] # (optional - may be required in the future) An array of tiers that the feature is available in currently. e.g., [Free, Silver, Gold, Core, Premium, Ultimate]

2
data/deprecations/15-8-third-party-registries.yml
View File

@ -6,7 +6,7 @@
stage: Package # (required) String value of the stage that the feature was created in. e.g., Growth
issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/376216 # (required) Link to the deprecation issue in GitLab
body: | # (required) Do not modify this line, instead modify the lines below.
Using third-party container registries with GitLab as an auth endpoint is deprecated in GitLab 15.8 and the [end of support](https://docs.gitlab.com/ee/development/deprecation_guidelines/#terminology) is scheduled for GitLab 16.0. This impacts self-managed customers that have connected their external registry to the GitLab user interface to find, view, and delete container images.
Using third-party container registries with GitLab as an auth endpoint is deprecated in GitLab 15.8 and the [end of support](https://docs.gitlab.com/ee/development/deprecation_guidelines/#terminology) is scheduled for GitLab 16.0. This impacts users on GitLab Self-Managed that have connected their external registry to the GitLab user interface to find, view, and delete container images.
Supporting both the GitLab container registry as well as third-party container registries is challenging for maintenance, code quality, and backward compatibility. This hinders our ability to stay [efficient](https://handbook.gitlab.com/handbook/values/#efficiency). As a result we will not support this functionality moving forward.

2
data/deprecations/15-9-ci-builds-column-validations.yml
View File

@ -19,7 +19,7 @@
- The `ref`, which is the Git branch or tag name for the pipeline.
- The `description` and `target_url` parameter, used by external CI/CD integrations.
Users on self-managed instances should update their pipelines to ensure they do not use parameters that exceed 255 characters. Users on GitLab.com do not need to make any changes, as these are already limited in that database.
Users on GitLab Self-Managed should update their pipelines to ensure they do not use parameters that exceed 255 characters. Users on GitLab.com do not need to make any changes, as these are already limited in that database.
#
# OPTIONAL FIELDS
#

4
data/deprecations/15-9-deprecate-ci-pre-clone-script.yml
View File

@ -1,4 +1,4 @@
- title: "Deprecation and planned removal for `CI_PRE_CLONE_SCRIPT` variable on GitLab SaaS" # (required) Clearly explain the change, or planned change. For example, "The `confidential` field for a `Note` is deprecated" or "CI/CD job names will be limited to 250 characters."
- title: "Deprecation and planned removal for `CI_PRE_CLONE_SCRIPT` variable on GitLab.com" # (required) Clearly explain the change, or planned change. For example, "The `confidential` field for a `Note` is deprecated" or "CI/CD job names will be limited to 250 characters."
announcement_milestone: "15.9" # (required) The milestone when this feature was first announced as deprecated.
removal_milestone: "16.0" # (required) The milestone when this feature is planned to be removed
breaking_change: true # (required) Change to false if this is not a breaking change.
@ -6,7 +6,7 @@
stage: Verify # (required) String value of the stage that the feature was created in. e.g., Growth
issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/391896 # (required) Link to the deprecation issue in GitLab
body: | # (required) Do not modify this line, instead modify the lines below.
The [`CI_PRE_CLONE_SCRIPT` variable](https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html#pre-clone-script) supported by GitLab SaaS Runners is deprecated as of GitLab 15.9 and will be removed in 16.0. The `CI_PRE_CLONE_SCRIPT` variable enables you to run commands in your CI/CD job prior to the runner executing Git init and get fetch. For more information about how this feature works, see [Pre-clone script](https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html#pre-clone-script). As an alternative, you can use the [`pre_get_sources_script`](https://docs.gitlab.com/ee/ci/yaml/#hookspre_get_sources_script).
The [`CI_PRE_CLONE_SCRIPT` variable](https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html#pre-clone-script) supported by GitLab.com Runners is deprecated as of GitLab 15.9 and will be removed in 16.0. The `CI_PRE_CLONE_SCRIPT` variable enables you to run commands in your CI/CD job prior to the runner executing Git init and get fetch. For more information about how this feature works, see [Pre-clone script](https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html#pre-clone-script). As an alternative, you can use the [`pre_get_sources_script`](https://docs.gitlab.com/ee/ci/yaml/#hookspre_get_sources_script).
#
# OPTIONAL END OF SUPPORT FIELDS
#

2
data/deprecations/15-9-deprecate-option-to-remove-project-immediately.yml
View File

@ -8,6 +8,6 @@
body: | # (required) Do not modify this line, instead modify the lines below.
The group and project deletion protection setting in the **Admin** area had an option to delete groups and projects immediately. Starting with 16.0, this option will no longer be available, and delayed group and project deletion will become the default behavior.
The option will no longer appear as a group setting. Users on GitLab Self-Managed will still have the option to define the deletion delay period, and SaaS users have a non-adjustable default retention period of 7 days. Users can still immediately delete the project from the project settings, and the group from the group settings.
The option will no longer appear as a group setting. Users on GitLab Self-Managed will still have the option to define the deletion delay period, and GitLab.com users have a non-adjustable default retention period of 7 days. Users can still immediately delete the project from the project settings, and the group from the group settings.
The option to delete groups and projects immediately by default was deprecated to prevent users from accidentally taking this action and permanently losing groups and projects.

2
data/deprecations/15-9-required-pipeline-configuration.yml
View File

@ -9,7 +9,7 @@
stage: Compliance Management # (required) String value of the stage that the feature was created in. e.g., Growth
issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/389467 # (required) Link to the deprecation issue in GitLab
body: | # (required) Do not modify this line, instead modify the lines below.
Required pipeline configuration will be removed in GitLab 17.0. This impacts self-managed users on the Ultimate tier.
Required pipeline configuration will be removed in GitLab 17.0. This impacts users on GitLab Self-Managed on the Ultimate tier.
You should replace required pipeline configuration with either:

4
data/deprecations/16-9-custom-role-creation.yml
View File

@ -1,4 +1,4 @@
- title: "Deprecate custom role creation for group owners on self-managed"
- title: "Deprecate custom role creation for group owners on GitLab Self-Managed"
removal_milestone: "17.0"
announcement_milestone: "16.9"
breaking_change: true
@ -11,7 +11,7 @@
Group owners on GitLab.com can continue to manage custom roles and assign at the group level.
If using the API to manage custom roles on a self-managed instance, a new instance endpoint has been added and is required to continue API operations.
If using the API to manage custom roles on GitLab Self-Managed, a new instance endpoint has been added and is required to continue API operations.
- List all member roles on the instance - `GET /api/v4/member_roles`
- Add member role to the instance - `POST /api/v4/member_roles`

4
data/deprecations/16-9-deprecate-small-saas-runner-tags.yml
View File

@ -1,4 +1,4 @@
- title: "Removal of tags from small SaaS runners on Linux"
- title: "Removal of tags from small GitLab.com runners on Linux"
removal_milestone: "17.0"
announcement_milestone: "16.9"
breaking_change: true
@ -7,7 +7,7 @@
issue_url: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/30829
manual_task: true
body: | # (required) Don't change this line.
Due to historical reasons, small Linux SaaS Runners had a lot of tags attached because they were used as labels. We want to streamline the tag to just use `saas-linux-small-amd64` and be consistent across all SaaS runners.
Due to historical reasons, small Linux GitLab.com Runners had a lot of tags attached because they were used as labels. We want to streamline the tag to just use `saas-linux-small-amd64` and be consistent across all GitLab.com runners.
We are deprecating the tags: `docker`, `east-c`, `gce`, `git-annex`, `linux`, `mongo`, `mysql`, `postgres`, `ruby`, `shared`.

4
data/deprecations/16-9-deprecate-terraform-cicd-templates.yml
View File

@ -27,10 +27,10 @@
and maintain them as needed.
As an alternative we recommend using the new OpenTofu CI/CD component on GitLab.com
or the new OpenTofu CI/CD template on self-managed.
or the new OpenTofu CI/CD template on GitLab Self-Managed.
CI/CD components are not yet available on GitLab Self-Managed,
but [Issue #415638](https://gitlab.com/gitlab-org/gitlab/-/issues/415638)
proposes to add this feature. If CI/CD components become available on self-managed,
proposes to add this feature. If CI/CD components become available on GitLab Self-Managed,
the OpenTofu CI/CD template will be removed.
You can read more about the new OpenTofu CI/CD component [here](https://gitlab.com/components/opentofu).

4
data/deprecations/16-9-deprecation-windows-server-2019.yml
View File

@ -7,6 +7,6 @@
issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/438554
manual_task: true
body: | # (required) Don't change this line.
We have recently announced the release of Windows Server 2022 for our SaaS runners on Windows (Beta). With it, we are deprecating Windows 2019 in GitLab 17.0.
We have recently announced the release of Windows Server 2022 for our GitLab.com runners on Windows (Beta). With it, we are deprecating Windows 2019 in GitLab 17.0.
For more information about how to migrate to using Windows 2022, see [Windows 2022 support for GitLab SaaS runners now available](https://about.gitlab.com/blog/2024/01/22/windows-2022-support-for-gitlab-saas-runners/).
For more information about how to migrate to using Windows 2022, see [Windows 2022 support for GitLab.com runners now available](https://about.gitlab.com/blog/2024/01/22/windows-2022-support-for-gitlab-saas-runners/).

4
data/deprecations/16-9-updating-cos-image-saas-runners.yml
View File

@ -1,4 +1,4 @@
- title: "Upgrading the operating system version of GitLab SaaS runners on Linux"
- title: "Upgrading the operating system version of GitLab.com runners on Linux"
removal_milestone: "17.0"
announcement_milestone: "16.9"
breaking_change: true
@ -7,7 +7,7 @@
issue_url: https://gitlab.com/gitlab-org/ci-cd/shared-runners/infrastructure/-/issues/60
manual_task: true
body: | # (required) Don't change this line.
GitLab is upgrading the container-optimized operating system (COS) of the ephemeral VMs used to execute jobs for SaaS runners on Linux.
GitLab is upgrading the container-optimized operating system (COS) of the ephemeral VMs used to execute jobs for GitLab.com runners on Linux.
That COS upgrade includes a Docker Engine upgrade from Version 19.03.15 to Version 23.0.5, which introduces a known compatibility issue.
Docker-in-Docker prior to version 20.10 or Kaniko images older than v1.9.0, will be unable to detect the container runtime and fail.

4
data/deprecations/17-1-opentofu-ci-template.yml
View File

@ -15,8 +15,8 @@
manual_task: true
window: 1
body: | # (required) Don't change this line.
We introduces the OpenTofu CI/CD template in 16.8 as CI/CD components were not available for self-managed installations yet.
With the introduction of [GitLab CI/CD components for self-managed users](https://docs.gitlab.com/ee/ci/components/#use-a-gitlabcom-component-in-a-self-managed-instance)
We introduced the OpenTofu CI/CD template in 16.8 as CI/CD components were not available for GitLab Self-Managed yet.
With the introduction of [GitLab CI/CD components for GitLab Self-Managed](https://docs.gitlab.com/ee/ci/components/#use-a-gitlabcom-component-in-a-self-managed-instance)
we are removing the redundant OpenTofu CI/CD templates in favor of the CI/CD components.
For information about migrating from the CI/CD template to the component, see the [OpenTofu component documentation](https://gitlab.com/components/opentofu#usage-on-self-managed).

2
data/deprecations/17-5-scan-execution-policy-action-limits.yml
View File

@ -17,4 +17,4 @@
If additional actions are needed, limit existing polices to no more than 10 actions. Then, create new scan execution policies with additional actions, within the limit of 5 scan execution policies per security policy project.
For self-managed users, you can configure a custom limit on self-managed instances with the `scan_execution_policies_action_limit` application setting.
For GitLab Self-Managed administrators, you can configure a custom limit with the `scan_execution_policies_action_limit` application setting.

46
data/deprecations/17-9-secure-analyzers-bump.yml Normal file
View File

@ -0,0 +1,46 @@
- title: "Application Security Testing analyzers major version update"
announcement_milestone: "17.9"
removal_milestone: "18.0"
breaking_change: true
window: 1
reporter: thiagocsf
stage: application security testing
issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/513417
impact: low
scope: project
resolution_role: Developer
manual_task: false
body: | # Do not modify this line, instead modify the lines below.
The Application Security Testing stage will be bumping the major versions of its analyzers in
tandem with the GitLab 18.0 release.
If you are not using the default included templates, or have pinned your analyzer versions, you
must update your CI/CD job definition to either remove the pinned version or update
the latest major version.
Users of GitLab 17.0 to GitLab 15.11 will continue to experience analyzer updates until the
release of GitLab 18.0, after which all newly fixed bugs and released features will be
released only in the new major version of the analyzers.
We do not backport bugs and features to deprecated versions as per our maintenance policy. As
required, security patches will be backported within the latest 3 minor releases.
Specifically, the following analyzers are being deprecated and will no longer be updated after
the GitLab 18.0 release:
- Advanced SAST: version 1
- Container Scanning: version 7
- Dependency Scanning: version 0
- Gemnasium: [all versions](https://gitlab.com/gitlab-org/gitlab/-/issues/501308)
- DAST: version 5
- DAST API: version 4
- Fuzz API: version 4
- IaC Scanning: version 5
- Pipeline Secret Detection: version 6
- Static Application Security Testing (SAST): version 5 of [all analyzers](https://docs.gitlab.com/ee/user/application_security/sast/analyzers/)
- `kics`
- `kubesec`
- `pmd-apex`
- `semgrep`
- `sobelow`
- `spotbugs`

4
db/docs/routes.yml
View File

@ -8,5 +8,7 @@ feature_categories:
description: Stores routes per namespaces and projects
introduced_by_url: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7121
milestone: '9.0'
gitlab_schema: gitlab_main_clusterwide
gitlab_schema: gitlab_main_cell
sharding_key:
namespace_id: namespaces
table_size: medium

13
db/docs/security_pipeline_execution_policy_config_links.yml Normal file
View File

@ -0,0 +1,13 @@
---
table_name: security_pipeline_execution_policy_config_links
classes:
- Security::PipelineExecutionPolicyConfigLink
feature_categories:
- security_policy_management
description: Pipeline execution policy/CI config project join table.
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/176307
milestone: '17.9'
gitlab_schema: gitlab_main_cell
sharding_key:
project_id: projects
table_size: small

21
db/migrate/20250109140113_create_security_pipeline_execution_policy_config_links.rb Normal file
View File

@ -0,0 +1,21 @@
# frozen_string_literal: true
class CreateSecurityPipelineExecutionPolicyConfigLinks < Gitlab::Database::Migration[2.2]
milestone '17.9'
POLICY_INDEX_NAME = 'index_pep_policy_config_links_security_policy_id'
UNIQUE_INDEX_NAME = 'unique_pep_policy_config_links_project_security_policy'
def up
create_table :security_pipeline_execution_policy_config_links do |t|
t.bigint :project_id, null: false
t.bigint :security_policy_id, null: false, index: { name: POLICY_INDEX_NAME }
t.index [:project_id, :security_policy_id], unique: true, name: UNIQUE_INDEX_NAME
end
end
def down
drop_table :security_pipeline_execution_policy_config_links
end
end

17
db/migrate/20250113122443_add_foreign_key_to_security_pipeline_execution_policy_config_links_project_id.rb Normal file
View File

@ -0,0 +1,17 @@
# frozen_string_literal: true
class AddForeignKeyToSecurityPipelineExecutionPolicyConfigLinksProjectId < Gitlab::Database::Migration[2.2]
milestone '17.9'
disable_ddl_transaction!
def up
add_concurrent_foreign_key :security_pipeline_execution_policy_config_links, :projects, column: :project_id,
on_delete: :cascade
end
def down
with_lock_retries do
remove_foreign_key :security_pipeline_execution_policy_config_links, column: :project_id
end
end
end

17
db/migrate/20250113165441_add_foreign_key_to_security_pipeline_execution_policy_config_links_policy_id.rb Normal file
View File

@ -0,0 +1,17 @@
# frozen_string_literal: true
class AddForeignKeyToSecurityPipelineExecutionPolicyConfigLinksPolicyId < Gitlab::Database::Migration[2.2]
milestone '17.9'
disable_ddl_transaction!
def up
add_concurrent_foreign_key :security_pipeline_execution_policy_config_links, :security_policies,
column: :security_policy_id, on_delete: :cascade
end
def down
with_lock_retries do
remove_foreign_key :security_pipeline_execution_policy_config_links, column: :security_policy_id
end
end
end

17
db/post_migrate/20250114140739_prepare_noteable_id_noteable_type_and_id_index_in_notes_table.rb Normal file
View File

@ -0,0 +1,17 @@
# frozen_string_literal: true
class PrepareNoteableIdNoteableTypeAndIdIndexInNotesTable < Gitlab::Database::Migration[2.2]
milestone '17.9'
INDEX_NAME = 'index_notes_on_noteable_id_noteable_type_and_id'
def up
# rubocop:disable Migration/PreventIndexCreation -- needed to iterate through notes of a single issuable when it has a lot of notes
prepare_async_index :notes, [:noteable_id, :noteable_type, :id], name: INDEX_NAME
# rubocop:enable Migration/PreventIndexCreation
end
def down
unprepare_async_index :notes, [:noteable_id, :noteable_type, :id], name: INDEX_NAME
end
end

1
db/schema_migrations/20250109140113 Normal file
View File

@ -0,0 +1 @@
a4edbd9b83ea8214e55cb1fb4bfbf4ffd7c0fd9b94144b4df0f81189a519e319

1
db/schema_migrations/20250113122443 Normal file
View File

@ -0,0 +1 @@
178adf2c3e6cf1277c7ec69268c895d39cf2f2330520199a130e9d02f2f3b4a1

1
db/schema_migrations/20250113165441 Normal file
View File

@ -0,0 +1 @@
340c40e5f8050b8e06972dcc1d89b9afb15cba58e9de5bc1bdb954f5ff893f64

1
db/schema_migrations/20250114140739 Normal file
View File

@ -0,0 +1 @@
221fbfc39fcf40a05130264befca56737ddf2db254f3f929a01292111fdec7c0

30
db/structure.sql
View File

@ -20531,6 +20531,21 @@ CREATE SEQUENCE security_orchestration_policy_rule_schedules_id_seq
ALTER SEQUENCE security_orchestration_policy_rule_schedules_id_seq OWNED BY security_orchestration_policy_rule_schedules.id;
CREATE TABLE security_pipeline_execution_policy_config_links (
id bigint NOT NULL,
project_id bigint NOT NULL,
security_policy_id bigint NOT NULL
);
CREATE SEQUENCE security_pipeline_execution_policy_config_links_id_seq
START WITH 1
INCREMENT BY 1
NO MINVALUE
NO MAXVALUE
CACHE 1;
ALTER SEQUENCE security_pipeline_execution_policy_config_links_id_seq OWNED BY security_pipeline_execution_policy_config_links.id;
CREATE TABLE security_pipeline_execution_project_schedules (
id bigint NOT NULL,
created_at timestamp with time zone NOT NULL,
@ -25133,6 +25148,8 @@ ALTER TABLE ONLY security_orchestration_policy_configurations ALTER COLUMN id SE
ALTER TABLE ONLY security_orchestration_policy_rule_schedules ALTER COLUMN id SET DEFAULT nextval('security_orchestration_policy_rule_schedules_id_seq'::regclass);
ALTER TABLE ONLY security_pipeline_execution_policy_config_links ALTER COLUMN id SET DEFAULT nextval('security_pipeline_execution_policy_config_links_id_seq'::regclass);
ALTER TABLE ONLY security_pipeline_execution_project_schedules ALTER COLUMN id SET DEFAULT nextval('security_pipeline_execution_project_schedules_id_seq'::regclass);
ALTER TABLE ONLY security_policies ALTER COLUMN id SET DEFAULT nextval('security_policies_id_seq'::regclass);
@ -27946,6 +27963,9 @@ ALTER TABLE ONLY security_orchestration_policy_configurations
ALTER TABLE ONLY security_orchestration_policy_rule_schedules
ADD CONSTRAINT security_orchestration_policy_rule_schedules_pkey PRIMARY KEY (id);
ALTER TABLE ONLY security_pipeline_execution_policy_config_links
ADD CONSTRAINT security_pipeline_execution_policy_config_links_pkey PRIMARY KEY (id);
ALTER TABLE ONLY security_pipeline_execution_project_schedules
ADD CONSTRAINT security_pipeline_execution_project_schedules_pkey PRIMARY KEY (id);
@ -33200,6 +33220,8 @@ CREATE INDEX index_pats_on_expiring_at_thirty_days_notification_sent_at ON perso
CREATE INDEX index_pe_approval_rules_on_required_approvals_and_created_at ON protected_environment_approval_rules USING btree (required_approvals, created_at);
CREATE INDEX index_pep_policy_config_links_security_policy_id ON security_pipeline_execution_policy_config_links USING btree (security_policy_id);
CREATE INDEX index_personal_access_token_last_used_ips_on_organization_id ON personal_access_token_last_used_ips USING btree (organization_id);
CREATE INDEX index_personal_access_tokens_on_id_and_created_at ON personal_access_tokens USING btree (id, created_at);
@ -34974,6 +34996,8 @@ CREATE UNIQUE INDEX unique_organizations_on_path_case_insensitive ON organizatio
CREATE UNIQUE INDEX unique_packages_project_id_and_name_and_version_when_debian ON packages_packages USING btree (project_id, name, version) WHERE ((package_type = 9) AND (status <> 4));
CREATE UNIQUE INDEX unique_pep_policy_config_links_project_security_policy ON security_pipeline_execution_policy_config_links USING btree (project_id, security_policy_id);
CREATE UNIQUE INDEX unique_pool_repositories_on_disk_path_and_shard_id ON pool_repositories USING btree (disk_path, shard_id);
CREATE UNIQUE INDEX unique_postgres_async_fk_validations_name_and_table_name ON postgres_async_foreign_key_validations USING btree (name, table_name);
@ -37600,6 +37624,9 @@ ALTER TABLE ONLY import_failures
ALTER TABLE ONLY project_ci_cd_settings
ADD CONSTRAINT fk_24c15d2f2e FOREIGN KEY (project_id) REFERENCES projects(id) ON DELETE CASCADE;
ALTER TABLE ONLY security_pipeline_execution_policy_config_links
ADD CONSTRAINT fk_256bbe966d FOREIGN KEY (security_policy_id) REFERENCES security_policies(id) ON DELETE CASCADE;
ALTER TABLE ONLY agent_activity_events
ADD CONSTRAINT fk_256c631779 FOREIGN KEY (project_id) REFERENCES projects(id) ON DELETE SET NULL;
@ -37807,6 +37834,9 @@ ALTER TABLE ONLY abuse_reports
ALTER TABLE ONLY protected_environment_approval_rules
ADD CONSTRAINT fk_405568b491 FOREIGN KEY (group_id) REFERENCES namespaces(id) ON DELETE CASCADE;
ALTER TABLE ONLY security_pipeline_execution_policy_config_links
ADD CONSTRAINT fk_40c1d0c74a FOREIGN KEY (project_id) REFERENCES projects(id) ON DELETE CASCADE;
ALTER TABLE ONLY subscription_add_on_purchases
ADD CONSTRAINT fk_410004d68b FOREIGN KEY (subscription_add_on_id) REFERENCES subscription_add_ons(id) ON DELETE CASCADE;

2
doc/administration/reference_architectures/index.md
View File

@ -600,7 +600,7 @@ remain compliant.
### Why we perform the tests
The Quality Department measures and improves the performance of GitLab. They create and validate architectures
to ensure reliable configurations for self-managed users.
to ensure reliable configurations for GitLab Self-Managed.
For more information, see our [handbook page](https://handbook.gitlab.com/handbook/engineering/infrastructure/test-platform/performance-and-scalability/).

2
doc/administration/settings/import_and_export_settings.md
View File

@ -85,7 +85,7 @@ To enable silent admin project and group file exports:
## Allow contribution mapping to administrators
> - Introduced in GitLab 17.5 [with flag](../../administration/feature_flags.md) named `importer_user_mapping`. Disabled by default.
> - Introduced in GitLab 17.5 [with a flag](../../administration/feature_flags.md) named `importer_user_mapping`. Disabled by default.
Allow mapping of imported user contributions to administrators.

5
doc/api/events.md
View File

@ -47,7 +47,10 @@ YYYY-MM-DD
### Event Time Period Limit
GitLab removes events older than 3 years from the events table for performance reasons.
For information about activity retention limits, see:
- [User activity time period limit](../user/profile/contributions_calendar.md#event-time-period-limit)
- [Project activity time period limit](../user/project/working_with_projects.md#event-time-period-limit)
## List currently authenticated user's events

2
doc/development/ai_architecture.md
View File

@ -142,7 +142,7 @@ The following table documents functionality that Code Suggestions offers today,
### Self-managed support
Code Suggestions for self-managed users was introduced as part of the [Cloud Connector MVC](https://gitlab.com/groups/gitlab-org/-/epics/10516).
Code Suggestions for GitLab Self-Managed was introduced as part of the [Cloud Connector MVC](https://gitlab.com/groups/gitlab-org/-/epics/10516).
For more information on the technical solution for this project see the [Cloud Connector architecture documentation](cloud_connector/architecture.md).

2
doc/development/ai_features/index.md
View File

@ -539,7 +539,7 @@ An [example](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/
AI actions were initially implemented inside the GitLab monolith. As part of our
[AI gateway as the Sole Access Point for Monolith to Access Models Epic](https://gitlab.com/groups/gitlab-org/-/epics/13024)
we're migrating prompts, model selection and model parameters into the AI gateway. This will increase the speed at which
we can deliver improvements to self-managed users, by decoupling prompt and model changes from monolith releases. To
we can deliver improvements to users on GitLab Self-Managed, by decoupling prompt and model changes from monolith releases. To
migrate an existing action:
1. Follow steps 1 through 3 on [How to implement a new action](#how-to-implement-a-new-action).

2
doc/development/contributing/first_contribution/index.md
View File

@ -30,7 +30,7 @@ You can follow this tutorial to familiarize yourself with the contribution proce
members and the wider community are ready and waiting to answer your questions and offer support
for making contributions.
1. Once your community forks access request is approved you can start using [GitLab Duo](../../../user/gitlab_duo/index.md),
our AI-powered features including Code Suggestions, Chat, Root Cause Analysis and more.
our AI-powered features including Code Suggestions, Chat, Root Cause Analysis, and more.
## Choose how you want to contribute

35
doc/development/duo_workflow/index.md
View File

@ -4,9 +4,13 @@ group: Duo Workflow
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
---
# Setting up local development for Duo Workflow
# Set up local development for GitLab Duo Workflow
This detailed guide describes setting up the local development environment for [Duo Workflow](../../user/duo_workflow/index.md). Alternatively, you can also [set up Duo Workflow directly with GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/duo_workflow.md?ref_type=heads).
This guide describes how to set up the local development environment for the various projects that make up [GitLab Duo Workflow](../../user/duo_workflow/index.md).
Alternatively, you can also [set up Duo Workflow directly with the GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/duo_workflow.md?ref_type=heads).
Follow [these instructions](#duo-workflow-ui-in-visual-studio-code-vs-code) to see Duo Workflow UI local build in VS Code.
## Prerequisites
@ -16,6 +20,13 @@ This detailed guide describes setting up the local development environment for [
- Docker
- See which Docker tooling is approved for GitLab team members in the [handbook](https://handbook.gitlab.com/handbook/tools-and-tips/mac/#docker-desktop).
## Duo Workflow UI in Visual Studio Code (VS Code)
There is no need for the GDK, Duo Workflow service or Duo Workflow executor local build to test Duo Workflow UI.
Only set these up if you are making changes to one of these packages and need to test their integration with the Duo Workflow UI in VS Code.
Please refer to the [Duo Workflow README.md](https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp/-/blob/main/packages/webview_duo_workflow/README.md) file in the Language Server project to get started with local development of Duo Workflow UI.
## Set up your local GitLab instance
1. Configure the Duo Workflow Service URL in your local GitLab instance by updating the `config/gitlab.yml` file:
@ -172,26 +183,6 @@ This detailed guide describes setting up the local development environment for [
$GDK_GITLAB_URL/api/v4/ai/duo_workflows/workflows/$WORKFLOW_ID/checkpoints
```
## Configure the GitLab Duo Workflow extension for VS Code
The above steps show how to start a workflow directly from the Duo Workflow
Executor.
If you would like to start Duo Workflow with the VS Code extension instead,
follow [these steps](../../user/duo_workflow/index.md#prerequisites).
If you would like to start Duo Workflow with a locally running VS Code extension and GitLab Language Server (for debugging or making changes to the extension)
1. Clone [language server](https://gitlab.com/gitlab-org/editor-extensions/gitlab-lsp).
1. Clone [VSCode extension](https://gitlab.com/gitlab-org/gitlab-vscode-extension).
1. Change directory (`cd`) into language server.
1. Run `npm install`.
1. Run `npm run watch -- --editor=vscode --packages webview-duo-workflow workflow-api --vscode-path path-to-vscode-extension-from-step-2`.
1. Open VSCode extension project in VSCode.
1. Click **Run and Debug**, choose **Run Extension** in the dropdown and select **Play**.
1. If prompted with **All installed extensions are temporarily disabled**, do not click **Reload and Enable extensions** because that will use native extensions.
1. In the command palette, run `GitLab: Show Duo Workflow`.
## Troubleshooting
### Issues connecting to 50052 port

2
doc/development/enabling_features_on_dedicated.md
View File

@ -24,7 +24,7 @@ Instead, all per-instance configurations must be made using the application (UI
## Enabling features
All features need to be Generally Available before they can be deployed to GitLab Dedicated. In most cases, this means any feature flags are defaulted to on, and the feature is being used on GitLab.com and by Self-Managed users.
All features need to be Generally Available before they can be deployed to GitLab Dedicated. In most cases, this means any feature flags are defaulted to on, and the feature is being used on GitLab.com and by users on GitLab Self-Managed.
New versions of GitLab and any other changes, are deployed using automation during scheduled maintenance windows. Because of the required automation and the timing of deployments, features must be safe for auto-rollout. This means that new features don't require any immediate manual adjustment from operators or customers.

218
doc/development/fe_guide/analytics_dashboards.md Normal file
View File

@ -0,0 +1,218 @@
---
stage: Monitor
group: Platform Insights
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
---
# Analytics dashboards
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/98610) in GitLab 15.5 as an [experiment](../../policy/development_stages_support.md#experiment).
Analytics dashboards provide a configuration-based [dashboard](https://design.gitlab.com/patterns/dashboards)
structure, which is used to render and modify dashboard configurations created by GitLab or users.
NOTE:
Analytics dashboards is intended for Premium and Ultimate subscriptions.
## Customizable dashboard framework
Analytics dashboards utilize a set of standardized UI components that ensure a consistent user experience. These components are modular and can be integrated into other dashboard interfaces where basic visualization capabilities are needed, without advanced features like data fetching, filtering, or editing.
Note that we are currently migrating these components to GitLab UI. During this transition period, components may be located in either the legacy system or the new GitLab UI framework.
- [vue_shared/components/customizable_dashboard](https://gitlab.com/gitlab-org/gitlab/-/tree/master/app/assets/javascripts/vue_shared/components/customizable_dashboard)
- [GlDashboardPanel](https://gitlab-org.gitlab.io/gitlab-ui/?path=/docs/dashboards-dashboards-panel--docs)
## Overview
Analytics dashboard can be broken down into the following logical components:
- Dashboard: The container that organizes and displays all visualizations
- Panels: Individual sections that host visualizations
- Visualizations: Data display templates (charts, tables, etc.)
- Data sources: Connections to the underlying data
### Dashboard
A dashboard combines a collection of data sources, panels and visualizations into a single page to visually represent data.
Each panel in the dashboard queries the relevant data source and displays the resulting data as the specified visualization. Visualizations serve as templates for how to display data and can be reused across different panels.
A typical dashboard structure looks like this:
```plaintext
dashboard
├── panelA
│ └── visualizationX
│ └── datasource1
├── panelB
│ └── visualizationY
│ └── datasource2
├── panelC
│ └── visualizationY
│ └── datasource1
```
#### Dashboard filters
Dashboards support the following filters:
- **Date range**: Date selector to filter data by date.
- **Anonymous users**: Toggle to include or exclude anonymous users from the dataset.
### Panel
Panels form the foundation of a dashboard and act as containers for your visualizations. Each panel is built using the GitLab standardized UI component called [GlDashboardPanel](https://gitlab-org.gitlab.io/gitlab-ui/?path=/docs/dashboards-dashboards-panel--docs).
### Visualization
A visualization transforms your data into a graphical format like a chart or table. You can use the following standard visualization types:
- LineChart
- ColumnChart
- DataTable
- SingleStats
For a list of all supported visualization types, see `AnalyticsVisualization.type` enum in [`analytics_visualization`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/validators/json_schemas/analytics_visualization.json).
You're not limited to these options though - you can create new visualization types as needed.
### Data source
A data source is a connection to a database, an endpoint or a collection of data which can be used by your dashboard to query, retrieve, filter, and visualize results.
While there's a core set of supported data sources (see `Data.type` enum in [`analytics_visualizations`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/validators/json_schemas/analytics_visualization.json)), you can add new ones to meet your needs.
Note that each panel fetches data from the data source separately and independently from other panels.
## Create a built-in dashboard
GitLab provides predefined dashboards that are labeled **By GitLab**. Users cannot edit them, but they can clone or use them as the basis for creating similar custom dashboards.
To create a built-in analytics dashboard:
1. Create a folder for the new dashboard under `ee/lib/gitlab/analytics`, for example:
```plaintext
ee/lib/gitlab/analytics/cool_dashboard
```
1. Create a dashboard configuration file (for example `dashboard.yaml`) in the new folder. The configuration must conform to the JSON schema defined in [`ee/app/validators/json_schemas/analytics_dashboard.json`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/validators/json_schemas/analytics_dashboard.json). Example:
```yaml
# cool_dashboard/dashboard.yaml
---
title: My dashboard
description: My cool dashboard
panels: []
```
1. Optionally enable dashboard filters, by setting the filter's `enabled` option to `true` in the `.yaml` configuration file :
```yaml
# cool_dashboard/dashboard.yaml
---
title: My dashboard
filters:
excludeAnonymousUsers:
enabled: true
dateRange:
enabled: true
```
Refer to the `DashboardFilters` type in the [`ee/app/validators/json_schemas/analytics_dashboard.json`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/validators/json_schemas/analytics_dashboard.json) for a list of supported filters.
1. Create a folder for your visualizations (for example `visualizations/`) in your dashboard directory and add configuration files for each visualization. Each file must conform to the JSON schema defined in [`ee/app/validators/json_schemas/analytics_visualization.json`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/validators/json_schemas/analytics_visualization.json). Example:
```yaml
# cool_dashboard/visualizations/cool_viz.yaml
---
version: 1
type: LineChart # The render type of the visualization.
data:
type: my_datasource # The name of the datasource
query: {}
options: {}
```
Both `query` and `options` objects will be passed to the data source and used to build the proper query.
Refer to [Data source](#data-source) for a list of supported data sources, and [Visualization](#visualization) for a list of supported visualization render types.
1. Add panels to your dashboard that reference your visualizations:
```yaml
# cool_dashboard/dashboard.yaml
---
title: My dashboard
description: My cool dashboard
panels:
- title: "My cool panel"
visualization: cool_viz # Must match the visualization config filename
gridAttributes:
yPos: 0
xPos: 0
width: 3
height: 1
```
The `gridAttributes` position the panel within a 12x12 dashboard grid, powered by [gridstack](https://github.com/gridstack/gridstack.js/tree/master/doc#item-options).
1. Register the dashboard by adding it to `builtin_dashboards` in [ee/app/models/product_analytics/dashboard.rb](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/models/product_analytics/dashboard.rb).
Here you can make your dashboard available at project-level or group-level (or both), restrict access based on feature flags, license or user role etc.
1. Register the visualization by adding it to `get_path_for_visualization` in [ee/app/models/product_analytics/visualization.rb](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/models/product_analytics/visualization.rb).
For a complete example, refer to the AI Impact [dashboard config](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/gitlab/analytics/ai_impact_dashboard/dashboard.yaml).
### Adding a new data source
To add a new data source:
1. Create a new JavaScript module that exports a `fetch` method. See [analytics_dashboards/data_sources/index.js](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/analytics/analytics_dashboards/data_sources/index.js) for the full documentation of the `fetch` API. You can also take a look at[`cube_analytics.js`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/analytics/analytics_dashboards/data_sources/cube_analytics.js) as an example
1. Add your module to the list exports in [`data_sources/index.js`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/analytics/analytics_dashboards/data_sources/index.js).
1. Add your data source to the schema's list of `Data` types in [`analytics_visualizations.json`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/validators/json_schemas/analytics_visualization.json).
NOTE:
Your data source must respect the filters so that all panels shows the same filtered data.
### Adding a new visualization render type
To add a new visualization render type:
1. Create a new Vue component that accepts `data` and `options` properties.
See [`line_chart.vue`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/analytics/analytics_dashboards/components/visualizations/line_chart.vue) as an example.
1. Add your component to the list of conditional components imports in [`analytics_dashboard_panel.vue`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/analytics/analytics_dashboards/components/analytics_dashboard_panel.vue).
1. Add your component to the schema's list of `AnalyticsVisualization` enum type in [`analytics_visualization.json`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/validators/json_schemas/analytics_visualization.json).
#### Migrating existing components to visualizations
You can migrate existing components to dashboard visualizations. To do this,
wrap your existing component in a new visualization that provides the component with the
required context and data. See [`dora_performers_score.vue`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/analytics/analytics_dashboards/components/visualizations/dora_performers_score.vue) as an example.
As an upgrade path, your component may fetch its own data internally.
But you should ensure to plan how to migrate your visualization to use the shared analytics data sources method.
See [`value_stream.js`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/analytics/analytics_dashboards/data_sources/value_stream.js) as an example.
#### Introducing visualizations behind a feature flag
While developing new visualizations we can use [feature flags](../feature_flags/index.md#create-a-new-feature-flag) to mitigate risks of disruptions or incorrect data for users.
The [`from_data`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/models/product_analytics/panel.rb) method builds the panel objects for a dashboard. Using the `filter_map` method, we can add a condition to skip rendering panels that include the visualization we are developing.
For example, here we have added the `enable_usage_overview_visualization` feature flag and can check it's current state to determine whether panels using the `usage_overview` visualization should be rendered:
```ruby
panel_yaml.filter_map do |panel|
# Skip processing the usage_overview panel if the feature flag is disabled
next if panel['visualization'] == 'usage_overview' && Feature.disabled?(:enable_usage_overview_visualization)
new(
title: panel['title'],
project: project,
grid_attributes: panel['gridAttributes'],
query_overrides: panel['queryOverrides'],
visualization: panel['visualization']
)
end
```

399
doc/development/fe_guide/customizable_dashboards.md
View File

@ -1,396 +1,13 @@
---
stage: Monitor
group: Platform Insights
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
redirect_to: 'analytics_dashboards.md'
remove_date: '2025-04-17'
---
# Customizable dashboards
<!-- markdownlint-disable -->
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/98610) in GitLab 15.5 as an [experiment](../../policy/development_stages_support.md#experiment).
This document was moved to [another location](analytics_dashboards.md).
Customizable dashboards provide a configuation-based [dashboard](https://design.gitlab.com/patterns/dashboards)
structure, which is used to render and modify dashboard configurations created by GitLab or users.
The dashboard structure does not provide the means to save and version control
user configuration files on a repository. This functionality is provided by [Analytics dashboards](../../user/analytics/analytics_dashboards.md)
which uses the customizable dashboard component.
NOTE:
Customizable dashboards is intended for Premium and Ultimate subscriptions.
## Overview
Customizable dashboard can be broken down into 3 logical components:
- Dashboard
- Panels
- Visualizations
A dashboard consists of a list of panels to render, each panel references one
visualization, and a single visualization can be shared by many panels.
A typical dashboard structure looks like this:
```plaintext
dashboard
├── panelA
│ └── visualizationX
├── panelB
│ └── visualizationY
├── panelC
│ └── visualizationY
```
## Usage
To use customizable dashboards:
1. Create a new Vue component for your dashboard.
1. Create a [visualization configuration](#visualization-configuration).
1. Create your [dashboard configuration](#dashboard-configuration).
1. Render an instance of `CustomizableDashboard` and pass it your [dashboard configuration](#using-the-component).
### Visualization configuration
Each visualization is a graphical representation of query results fetched from a data source.
```javascript
// visualizations.js
export const pageViewsOverTime = {
// The name of the Vue component used to render the query.
type: 'LineChart',
// Chart options defined by the charting library being used by the panel.
options: {
xAxis: { name: __('Time'), type: 'time' },
yAxis: { name: __('Counts'), type: 'value' },
},
// The data to query
data: {
// The data source to query. Here it is Product Analytics.
type: 'cube_analytics',
// The query to run on the data source. Here in Cube.js format.
query: {
dimensions: [],
filters: [
{
member: 'TrackedEvents.eventName',
operator: 'equals',
values: ['page_view']
}
],
measures: ['TrackedEvents.pageViewsCount'],
timeDimensions: [
{
dimension: 'TrackedEvents.derivedTstamp',
granularity: 'day',
},
],
limit: 100,
timezone: 'UTC',
},
},
};
```
#### Adding a new visualization render type
To add a new visualization render type:
1. Create a new Vue component that accepts `data` and `options` properties.
See [`line_chart.vue`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/analytics/analytics_dashboards/components/visualizations/line_chart.vue) as an example.
1. Add your component to the list of conditional imports in [`panel_base.vue`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/vue_shared/components/customizable_dashboard/panels_base.vue#L13).
1. Add your component to the schema's list of `AnalyticsVisualization` types in [`analytics_visualizations.json`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/validators/json_schemas/analytics_visualization.json).
##### Migrating existing components to visualizations
You can migrate existing components to dashboard visualizations. To do this,
wrap your existing component in a new visualization that provides the component with the
required context and data. See [`dora_performers_score.vue`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/analytics/analytics_dashboards/components/visualizations/dora_performers_score.vue) as an example.
As an upgrade path, your component may fetch its own data internally.
This method is fine for the first few iterations, but eventually you should migrate
your visualization to use the standard and shared analytics data sources method.
See [`value_stream.js`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/analytics/analytics_dashboards/data_sources/value_stream.js) as an example.
#### Adding a new visualization data source
To add a new data source:
1. Create a new JavaScript module that exports a `fetch` method. See [`cube_analytics.js`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/analytics/analytics_dashboards/data_sources/cube_analytics.js#L122) as an example.
1. Add your module to the list exports in [`data_sources/index.js`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/assets/javascripts/analytics/analytics_dashboards/data_sources/index.js).
1. Add your data source to the schema's list of `Data` types in [`analytics_visualizations.json`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/validators/json_schemas/analytics_visualization.json).
NOTE:
Your data source must respect the filters so that all panels show data for
the same date range.
#### Feedback and error handling
Visualizations can provide panel-specific feedback in the form of an alert. This allows you to highlight the panel and add a popover to
display additional information when the user hovers over the panel. You can view online examples in the [GitLab storybook](https://gitlab-org.gitlab.io/gitlab/storybook/?path=/story/ee-vue-shared-components-panels-base--default).
The supported alert variants based on our [Pajamas guidelines](https://design.gitlab.com/components/alert#variants) are:
- `danger`: For unrecoverable errors encountered when loading the data or the panel.
- `warning`: For errors or additional information that impact the data displayed in the panel.
- `info`: For additional information or tips about the panel.
Visualization panels provide props for rendering alerts:
- `showAlertState`: A boolean used to show or hide an alert.
- `alertVariant`: The type of alert, which defaults to the `danger` variant.
- `alertPopoverTitle`: The title text for the alert.
The `alert-popover` slot can be used to customize the body content of the alert:
```vue
<!-- Displays a danger popover state with a list of failures -->
<panels-base
:title="Test panel with error"
:show-alert-state="true"
:alert-variant="VARIANT_DANGER"
:alert-popover-title="Very bad!"
>
<template #alert-popover>
<p>{{ "The following failures occurred:" }}</p>
<ul>
<li>{{ "Failed to load api" }}</li>
<li>{{ "Failed to load ui" }}</li>
</ul>
</template>
</panels-base>
```
::Tabs
:::TabTitle `danger` alert
Here's an example of a `danger` alert for a panel.
![Panel danger alert](img/panel_error_v17_1.png)
:::TabTitle `warning` alert
Here's an example of a `warning` alert for a panel.
![Panel warning alert](img/panel_warning_v17_1.png)
:::TabTitle `info` alert
Here's an example of an `info` alert for a panel.
![Panel info alert](img/panel_info_v17_1.png)
::EndTabs
### Dashboard configuration
Here is an example dashboard configuration:
```javascript
// constants.js
import { pageViewsOverTime } from './visualizations';
export const dashboard = {
slug: 'my_dashboard', // Used to set the URL path for the dashboard.
title: 'My dashboard title', // The title to display.
description: 'This is a description of the dashboard', // A description of the dashboard
userDefined: true, // The dashboard editor is only available when true.
// Each dashboard consists of an array of panels to display.
panels: [
{
id: 1,
title: 'Page views over time', // The panel title to display.
// The visualization configuration. This can be shared by many panels.
visualization: pageViewsOverTime,
// Gridstack settings based upon https://github.com/gridstack/gridstack.js/tree/master/doc#item-options.
// All values are grid row/column numbers up to 12.
// We use the default 12 column grid https://github.com/gridstack/gridstack.js#change-grid-columns.
gridAttributes: {
yPos: 1,
xPos: 0,
width: 6,
height: 5,
},
// Optional overrides for the values in `visualization.data.query`.
// Here we override the Cube.js query to get page views per week instead of days.
queryOverrides: {
timeDimensions: {
dimension: 'TrackedEvents.derivedTstamp',
granularity: 'week',
},
},
},
],
};
```
### Using the component
Here is an example component that renders a customizable dashboard:
```vue
<script>
import CustomizableDashboard from '~/vue_shared/components/customizable_dashboard/customizable_dashboard.vue';
import PanelsBase from `~/vue_shared/components/customizable_dashboard/panels_base.vue`;
import { dashboard } from './constants';
export default {
name: 'MyCustomDashboard',
components: {
CustomizableDashboard,
PanelsBase,
},
data() {
return {
// We keep the original (default) dashboard object to track changes.
dashboard: {
...dashboard,
default: { ...dashboard, }
},
// Optional dashboard filters. Currently the only availble filter is date range.
defaultFilters: {
dateRangeOption: 'last_7_days' // 'custom', 'today', 'last_7_days', 'last_30_days'
endDate: new Date(2023, 06, 14),
startDate: new Date(2023, 06, 7),
},
// Set to true to sync the filter object with the URL query string.
syncUrlFilters: true,
// Set to true to show the date range filter.
showDateRangeFilter: true,
// The maximum size of the date range allowed in days. 0 for unlimited.
dateRangeLimit: 0,
// Array of GlDisclosureDropdown items to show on each panel when editing
panelActions: [
{
text: __('Delete'),
action: () => this.$emit('delete'),
icon: 'remove',
},
],
};
},
};
</script>
<template>
<customizable-dashboard
:initial-dashboard="dashboard"
:default-filters="defaultFilters"
:sync-url-filters="syncUrlFilters"
:show-date-range-filter="showDateRangeFilter"
:date-range-limit="dateRangeLimit"
/>
<template #panel="{ panel, filters, editing, deletePanel }">
<!-- Panels base provides a styled wrapper for your visualizations. -->
<panels-base
:title="panel.title"
:editing="editing"
:actions="panelActions"
@delete="deletePanel"
>
<template #body>
<!-- Render the panel's visualization here -->
</template>
</panels-base>
</template>
</customizable-dashboard>
</template>
```
## Dashboard designer
> - Introduced in GitLab 16.1 [with a flag](../../administration/feature_flags.md) named `combined_analytics_dashboards_editor`. Disabled by default.
> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/411407) in GitLab 16.6. Feature flag `combined_analytics_dashboards_editor` removed.
The CustomizableDashboard component provides a graphical interface for users to
modify panels of existing dashboards and create new dashboards.
The dashboard editor is only available when `dashboard.userDefined` is `true`.
```vue
<script>
import CustomizableDashboard from '~/vue_shared/components/customizable_dashboard/customizable_dashboard.vue';
import { s__ } from '~/locale';
import { dashboard } from './constants';
export const I18N_MY_NEW_CATEGORY = s__('Namespace|My data source');
export default {
name: 'MyCustomDashboard',
data() {
return {
...,
// The initial saved dashboard. Used to track changes.
initialDashboard: dashboard,
// Set to true to render the dashboard saving state.
isSaving: false,
// A list of availble visualizations categorized by feature.
availableVisualizations: {
// The visualization category title to display.
[I18N_MY_NEW_CATEGORY]: {
// Set to true when asynchronously loading the visualization IDs
loading: false,
// List of availble visualization IDs for the user to add to the dashboard.
visualizationIds: [
'page_views_over_time',
'events_over_time',
],
},
}
};
},
methods: {
/**
* Event handler for when a user saves changes made to the current dashboard.
* @param {String} dashboardId The current dashboard ID.
* @param {String} newDashboardObject The newly modified dashboard object.
*/
saveDashboard(dashboardId, newDashboardObject) {
this.isSaving = true;
// Save changes somewhere.
// Then update the saved dashboard version
this.initialDashboard = newDashboardObject;
this.isSaving = false;
},
},
}
</script>
<template>
<customizable-dashboard
:initial-dashboard="initialDashboard"
:available-visualizations="availableVisualizations"
:is-saving="isSaving"
@save="saveDashboard"
/>
<template #panel="{ panel, filters, editing, deletePanel }">
<my-dashboard-panel :panel="panel" />
</template>
</customizable-dashboard>
</template>
```
## Introducing visualizations behind a feature flag
While developing new visualizations we can use [feature flags](../feature_flags/index.md#create-a-new-feature-flag) to mitigate risks of disruptions or incorrect data for users.
The [`from_data`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/models/product_analytics/panel.rb#L7) method builds the panel objects for a dashboard. Using the `filter_map` method, we can add a condition to skip rendering panels that include the visualization we are developing.
For example, here we have added the `enable_usage_overview_visualization` feature flag and can check it's current state to determine whether panels using the `usage_overview` visualization should be rendered:
```ruby
panel_yaml.filter_map do |panel|
# Skip processing the usage_overview panel if the feature flag is disabled
next if panel['visualization'] == 'usage_overview' && Feature.disabled?(:enable_usage_overview_visualization)
new(
title: panel['title'],
project: project,
grid_attributes: panel['gridAttributes'],
query_overrides: panel['queryOverrides'],
visualization: panel['visualization']
)
end
```
<!-- This redirect file can be deleted after <2025-04-17>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

2
doc/development/internal_analytics/index.md
View File

@ -133,7 +133,7 @@ For a list of other metrics tables refer to the [Data Models Cheat Sheet](https:
### Product Analytics
Internal Analytics is dogfooding the GitLab [Product Analytics](https://www.youtube.com/watch?v=i8Mze9lRZiY?) functionality, which allows you to visualize events as well.
The [Analytics Dashboards documentation](../../user/analytics/analytics_dashboards.md#define-a-dashboard) explains how to build custom visualizations and dashboards.
The [Analytics Dashboards documentation](../../user/analytics/analytics_dashboards.md#create-a-dashboard-by-configuration) explains how to build custom visualizations and dashboards.
The custom dashboards accessible [within the GitLab project](https://gitlab.com/gitlab-org/gitlab/-/analytics/dashboards) are defined in a [separate repository](https://gitlab.com/gitlab-org/analytics-section/gitlab-com-dashboards).
It is possible to build dashboards based on events instrumented via the Internal events system. Only events emitted by the .com installation will be counted in those visualizations.

2
doc/development/logging.md
View File

@ -428,7 +428,7 @@ end
## Default logging locations
For self-managed users and GitLab.com, GitLab is deployed in two ways:
For GitLab Self-Managed and GitLab.com, GitLab is deployed in two ways:
- [Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab)
- [Cloud Native GitLab](https://gitlab.com/gitlab-org/build/CNG) via a [Helm Chart](https://gitlab.com/gitlab-org/charts/gitlab)

31
doc/development/pipelines/index.md
View File

@ -721,10 +721,10 @@ Exceptions to this general guideline should be motivated and documented.
### Ruby versions testing
We're running Ruby 3.1 on GitLab.com, as well as for the default branch.
To prepare for the next Ruby version, we run merge requests in Ruby 3.2.
We're running Ruby 3.2 on GitLab.com, as well as for the default branch.
To prepare for the next Ruby version, we run merge requests in Ruby 3.3.
Please see the roadmap at
[Ruby 3.2 epic](https://gitlab.com/groups/gitlab-org/-/epics/9684#plan)
[Ruby 3.3 epic](https://gitlab.com/groups/gitlab-org/-/epics/12350)
for more details.
To make sure all supported Ruby versions are working, we also run our test
@ -733,7 +733,7 @@ suite on dedicated 2-hourly scheduled pipelines for each supported versions.
For merge requests, you can add the following labels to run the respective
Ruby version only:
- `pipeline:run-in-ruby3_1`
- `pipeline:run-in-ruby3_3`
### PostgreSQL versions testing
@ -746,25 +746,24 @@ We run our test suite against PostgreSQL 14, 15 and 16 on nightly scheduled pipe
| Where? | PostgreSQL version | Ruby version |
|-----------------------------------------------------------------------------------------------|------------------------------|-----------------------|
| Merge requests | 14 (default version) | 3.1 (default version) |
| `master` branch commits | 14 (default version) | 3.1 (default version) |
| `maintenance` scheduled pipelines for the `master` branch (every even-numbered hour at XX:05) | 14 (default version) | 3.1 (default version) |
| `maintenance` scheduled pipelines for the `ruby3_2` branch (every odd-numbered hour at XX:10) | 14 (default version) | 3.2 |
| `nightly` scheduled pipelines for the `master` branch | 14 (default version), 15, 16 | 3.1 (default version) |
| Merge requests | 14 (default version) | 3.2 (default version) |
| `master` branch commits | 14 (default version) | 3.2 (default version) |
| `maintenance` scheduled pipelines for the `master` branch (every even-numbered hour at XX:05) | 14 (default version) | 3.2 (default version) |
| `maintenance` scheduled pipelines for the `ruby-next` branch (every odd-numbered hour at XX:10) | 14 (default version) | 3.3 |
| `nightly` scheduled pipelines for the `master` branch | 14 (default version), 15, 16 | 3.2 (default version) |
For each current Ruby versions we're testing against with, we run
maintenance scheduled pipelines every 2 hours on their respective `ruby\d_\d`
branches. All these branches must not have any changes. These branches are
only there to run pipelines with their respective Ruby versions in the
scheduled maintenance pipelines.
For the next Ruby versions we're testing against with, we run
maintenance scheduled pipelines every 2 hours on the `ruby-next` branch.
`ruby-next` must not have any changes. The branch is only there to run
pipelines with another Ruby version in the scheduled maintenance pipelines.
Additionally, we have scheduled pipelines running on `ruby-sync` branch also
every 2 hours, updating all the `ruby\d_\d` branches to be up-to-date with
every 2 hours, updating all next branches to be up-to-date with
the default branch `master`. No pipelines will be triggered by this push.
The `gitlab` job in the `ruby-sync` branch uses a `gitlab-org/gitlab` project
token named `RUBY_SYNC` with `write_repository` scope and `Maintainer` role,
expiring on 2024-12-01. The token is stored in the `RUBY_SYNC_TOKEN` variable
expiring on 2025-12-02. The token is stored in the `RUBY_SYNC_TOKEN` variable
in the pipeline schedule for `ruby-sync` branch.
### Redis versions testing

2
doc/development/rake_tasks.md
View File

@ -76,7 +76,7 @@ You can seed groups with subgroups that contain milestones/projects/issues
with the `gitlab:seed:group_seed` task:
```shell
bin/rake "gitlab:seed:group_seed[subgroup_depth, username]"
bin/rake "gitlab:seed:group_seed[subgroup_depth, username, organization_path]"
```
Group are additionally seeded with epics if GitLab instance has epics feature available.

2
doc/development/sidekiq/index.md
View File

@ -55,7 +55,7 @@ end
A past example is the use of `allow_unrouted_sidekiq_calls` in [Geo Rake tasks](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/149958#note_1906072228)
as it does not affect GitLab.com. However, developer should write shard-aware code where possible since
that is a pre-requisite for sharding to be [released as a feature to self-managed users](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/3430).
that is a pre-requisite for sharding to be [released as a feature to users on GitLab Self-Managed](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/3430).
## Retries

4
doc/security/email_verification.md
View File

@ -43,10 +43,10 @@ To unlock your account, sign in and enter the verification code. You can also
## Accounts with 2FA or OAuth
An account is locked when there are ten or more failed sign-in attempts, or more than the
amount defined in the [configurable locked user policy](unlock_user.md#self-managed-users).
amount defined in the [configurable locked user policy](unlock_user.md#gitlab-self-managed-and-gitlab-dedicated-users).
Accounts with 2FA or OAuth are automatically unlocked after ten minutes, or more than the
amount defined in the [configurable locked user policy](unlock_user.md#self-managed-users).
amount defined in the [configurable locked user policy](unlock_user.md#gitlab-self-managed-and-gitlab-dedicated-users).
To unlock an account manually, reset your password.
## Related topics

2
doc/security/unlock_user.md
View File

@ -21,7 +21,7 @@ If 2FA is not enabled user accounts are locked after three failed sign-in attemp
- The next successful sign-in, at which point the user must verify their identity with a code sent to their email.
- GitLab Support verifies the identity of the user and [manually unlocks](https://handbook.gitlab.com/handbook/support/workflows/reinstating-blocked-accounts/#manual-unlock) the account.
## Self-managed users
## GitLab Self-Managed and GitLab Dedicated users
DETAILS:
**Tier:** Free, Premium, Ultimate

1
doc/update/breaking_windows.md
View File

@ -50,6 +50,7 @@ This window takes place on April 21 - 23, 2025 from 09:00 UTC to 22:00 UTC.
| [`RemoteDevelopmentAgentConfig` GraphQL type is deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/509787) | Low | Create | Project |
| [`defaultMaxHoursBeforeTermination` and `maxHoursBeforeTerminationLimit` fields are deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/509787) | Low | Create | Project |
| [SAST jobs no longer use global cache settings](https://gitlab.com/gitlab-org/gitlab/-/issues/512564) | Medium | Application security testing | Instance |
| [Application Security Testing analyzers major version update](https://gitlab.com/gitlab-org/gitlab/-/issues/513417) | Low | Application security testing | Project |
## Window 2

198
doc/update/deprecations.md
View File

@ -129,6 +129,34 @@ For details, see the [migration guide](https://docs.gitlab.com/ee/user/group/com
<div class="deprecation breaking-change" data-milestone="19.0">
### GitLab Self-Managed certificate-based integration with Kubernetes
<div class="deprecation-notes">
- Announced in GitLab <span class="milestone">14.5</span>
- Removal in GitLab <span class="milestone">19.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/groups/gitlab-org/configure/-/epics/8).
</div>
The certificate-based integration with Kubernetes [will be deprecated and removed](https://about.gitlab.com/blog/2021/11/15/deprecating-the-cert-based-kubernetes-integration/).
For GitLab Self-Managed, we are introducing the [feature flag](https://docs.gitlab.com/ee/administration/feature_flags.html#enable-or-disable-the-feature) `certificate_based_clusters` in GitLab 15.0 so you can keep your certificate-based integration enabled. However, the feature flag will be disabled by default, so this change is a **breaking change**.
In GitLab 18.0 we will remove both the feature and its related code. Until the final removal in 18.0, features built on this integration will continue to work, if you enable the feature flag. Until the feature is removed, GitLab will continue to fix security and critical issues as they arise.
For a more robust, secure, forthcoming, and reliable integration with Kubernetes, we recommend you use the
[agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/) to connect Kubernetes clusters with GitLab. [How do I migrate?](https://docs.gitlab.com/ee/user/infrastructure/clusters/migrate_to_gitlab_agent.html)
Although an explicit removal date is set, we don't plan to remove this feature until the new solution has feature parity.
For more information about the blockers to removal, see [this issue](https://gitlab.com/gitlab-org/configure/general/-/issues/199).
For updates and details about this deprecation, follow [this epic](https://gitlab.com/groups/gitlab-org/configure/-/epics/8).
</div>
<div class="deprecation breaking-change" data-milestone="19.0">
### Running a single database is deprecated
<div class="deprecation-notes">
@ -150,34 +178,6 @@ Before upgrading to GitLab 19.0, please ensure you have [migrated](https://docs.
<div class="deprecation breaking-change" data-milestone="19.0">
### Self-managed certificate-based integration with Kubernetes
<div class="deprecation-notes">
- Announced in GitLab <span class="milestone">14.5</span>
- Removal in GitLab <span class="milestone">19.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/groups/gitlab-org/configure/-/epics/8).
</div>
The certificate-based integration with Kubernetes [will be deprecated and removed](https://about.gitlab.com/blog/2021/11/15/deprecating-the-cert-based-kubernetes-integration/).
As a self-managed customer, we are introducing the [feature flag](https://docs.gitlab.com/ee/administration/feature_flags.html#enable-or-disable-the-feature) `certificate_based_clusters` in GitLab 15.0 so you can keep your certificate-based integration enabled. However, the feature flag will be disabled by default, so this change is a **breaking change**.
In GitLab 18.0 we will remove both the feature and its related code. Until the final removal in 18.0, features built on this integration will continue to work, if you enable the feature flag. Until the feature is removed, GitLab will continue to fix security and critical issues as they arise.
For a more robust, secure, forthcoming, and reliable integration with Kubernetes, we recommend you use the
[agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/) to connect Kubernetes clusters with GitLab. [How do I migrate?](https://docs.gitlab.com/ee/user/infrastructure/clusters/migrate_to_gitlab_agent.html)
Although an explicit removal date is set, we don't plan to remove this feature until the new solution has feature parity.
For more information about the blockers to removal, see [this issue](https://gitlab.com/gitlab-org/configure/general/-/issues/199).
For updates and details about this deprecation, follow [this epic](https://gitlab.com/groups/gitlab-org/configure/-/epics/8).
</div>
<div class="deprecation breaking-change" data-milestone="19.0">
### Single database connection is deprecated
<div class="deprecation-notes">
@ -352,6 +352,54 @@ If you encounter any issues after making these changes, try regenerating your AW
<div class="deprecation breaking-change" data-milestone="18.0">
### Application Security Testing analyzers major version update
<div class="deprecation-notes">
- Announced in GitLab <span class="milestone">17.9</span>
- Removal in GitLab <span class="milestone">18.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/513417).
</div>
The Application Security Testing stage will be bumping the major versions of its analyzers in
tandem with the GitLab 18.0 release.
If you are not using the default included templates, or have pinned your analyzer versions, you
must update your CI/CD job definition to either remove the pinned version or update
the latest major version.
Users of GitLab 17.0 to GitLab 15.11 will continue to experience analyzer updates until the
release of GitLab 18.0, after which all newly fixed bugs and released features will be
released only in the new major version of the analyzers.
We do not backport bugs and features to deprecated versions as per our maintenance policy. As
required, security patches will be backported within the latest 3 minor releases.
Specifically, the following analyzers are being deprecated and will no longer be updated after
the GitLab 18.0 release:
- Advanced SAST: version 1
- Container Scanning: version 7
- Dependency Scanning: version 0
- Gemnasium: [all versions](https://gitlab.com/gitlab-org/gitlab/-/issues/501308)
- DAST: version 5
- DAST API: version 4
- Fuzz API: version 4
- IaC Scanning: version 5
- Pipeline Secret Detection: version 6
- Static Application Security Testing (SAST): version 5 of [all analyzers](https://docs.gitlab.com/ee/user/application_security/sast/analyzers/)
- `kics`
- `kubesec`
- `pmd-apex`
- `semgrep`
- `sobelow`
- `spotbugs`
</div>
<div class="deprecation breaking-change" data-milestone="18.0">
### Behavior change for Upcoming and Started milestone filters
<div class="deprecation-notes">
@ -527,10 +575,10 @@ To continue using Terraform, clone the templates and [Terraform image](https://g
and maintain them as needed.
As an alternative we recommend using the new OpenTofu CI/CD component on GitLab.com
or the new OpenTofu CI/CD template on self-managed.
or the new OpenTofu CI/CD template on GitLab Self-Managed.
CI/CD components are not yet available on GitLab Self-Managed,
but [Issue #415638](https://gitlab.com/gitlab-org/gitlab/-/issues/415638)
proposes to add this feature. If CI/CD components become available on self-managed,
proposes to add this feature. If CI/CD components become available on GitLab Self-Managed,
the OpenTofu CI/CD template will be removed.
You can read more about the new OpenTofu CI/CD component [here](https://gitlab.com/components/opentofu).
@ -859,7 +907,7 @@ By adding limits, we can ensure performance and scalability for security policie
If additional actions are needed, limit existing polices to no more than 10 actions. Then, create new scan execution policies with additional actions, within the limit of 5 scan execution policies per security policy project.
For self-managed users, you can configure a custom limit on self-managed instances with the `scan_execution_policies_action_limit` application setting.
For GitLab Self-Managed administrators, you can configure a custom limit with the `scan_execution_policies_action_limit` application setting.
</div>
@ -875,8 +923,8 @@ For self-managed users, you can configure a custom limit on self-managed instanc
</div>
We introduces the OpenTofu CI/CD template in 16.8 as CI/CD components were not available for self-managed installations yet.
With the introduction of [GitLab CI/CD components for self-managed users](https://docs.gitlab.com/ee/ci/components/#use-a-gitlabcom-component-in-a-self-managed-instance)
We introduced the OpenTofu CI/CD template in 16.8 as CI/CD components were not available for GitLab Self-Managed yet.
With the introduction of [GitLab CI/CD components for GitLab Self-Managed](https://docs.gitlab.com/ee/ci/components/#use-a-gitlabcom-component-in-a-self-managed-instance)
we are removing the redundant OpenTofu CI/CD templates in favor of the CI/CD components.
For information about migrating from the CI/CD template to the component, see the [OpenTofu component documentation](https://gitlab.com/components/opentofu#usage-on-self-managed).
@ -2280,7 +2328,7 @@ The ability for Developers to change the status of vulnerabilities is now deprec
<div class="deprecation breaking-change" data-milestone="17.0">
### Deprecate custom role creation for group owners on self-managed
### Deprecate custom role creation for group owners on GitLab Self-Managed
<div class="deprecation-notes">
@ -2295,7 +2343,7 @@ Group Owners will be able to assign custom roles at the group level.
Group owners on GitLab.com can continue to manage custom roles and assign at the group level.
If using the API to manage custom roles on a self-managed instance, a new instance endpoint has been added and is required to continue API operations.
If using the API to manage custom roles on GitLab Self-Managed, a new instance endpoint has been added and is required to continue API operations.
- List all member roles on the instance - `GET /api/v4/member_roles`
- Add member role to the instance - `POST /api/v4/member_roles`
@ -2364,9 +2412,9 @@ The parameters, `sign_in_text` and `help_text`, are deprecated in the [Settings
</div>
We have recently announced the release of Windows Server 2022 for our SaaS runners on Windows (Beta). With it, we are deprecating Windows 2019 in GitLab 17.0.
We have recently announced the release of Windows Server 2022 for our GitLab.com runners on Windows (Beta). With it, we are deprecating Windows 2019 in GitLab 17.0.
For more information about how to migrate to using Windows 2022, see [Windows 2022 support for GitLab SaaS runners now available](https://about.gitlab.com/blog/2024/01/22/windows-2022-support-for-gitlab-saas-runners/).
For more information about how to migrate to using Windows 2022, see [Windows 2022 support for GitLab.com runners now available](https://about.gitlab.com/blog/2024/01/22/windows-2022-support-for-gitlab-saas-runners/).
</div>
@ -3081,7 +3129,7 @@ While the above approach is recommended for most instances, Sidekiq can also be
<div class="deprecation breaking-change" data-milestone="17.0">
### Removal of tags from small SaaS runners on Linux
### Removal of tags from small GitLab.com runners on Linux
<div class="deprecation-notes">
@ -3091,7 +3139,7 @@ While the above approach is recommended for most instances, Sidekiq can also be
</div>
Due to historical reasons, small Linux SaaS Runners had a lot of tags attached because they were used as labels. We want to streamline the tag to just use `saas-linux-small-amd64` and be consistent across all SaaS runners.
Due to historical reasons, small Linux GitLab.com Runners had a lot of tags attached because they were used as labels. We want to streamline the tag to just use `saas-linux-small-amd64` and be consistent across all GitLab.com runners.
We are deprecating the tags: `docker`, `east-c`, `gce`, `git-annex`, `linux`, `mongo`, `mysql`, `postgres`, `ruby`, `shared`.
@ -3111,7 +3159,7 @@ For more information, see [Removing tags from our small SaaS runner on Linux](ht
</div>
Required pipeline configuration will be removed in GitLab 17.0. This impacts self-managed users on the Ultimate tier.
Required pipeline configuration will be removed in GitLab 17.0. This impacts users on GitLab Self-Managed on the Ultimate tier.
You should replace required pipeline configuration with either:
@ -3431,7 +3479,7 @@ You can still access unified approval rules with the API.
<div class="deprecation breaking-change" data-milestone="17.0">
### Upgrading the operating system version of GitLab SaaS runners on Linux
### Upgrading the operating system version of GitLab.com runners on Linux
<div class="deprecation-notes">
@ -3441,7 +3489,7 @@ You can still access unified approval rules with the API.
</div>
GitLab is upgrading the container-optimized operating system (COS) of the ephemeral VMs used to execute jobs for SaaS runners on Linux.
GitLab is upgrading the container-optimized operating system (COS) of the ephemeral VMs used to execute jobs for GitLab.com runners on Linux.
That COS upgrade includes a Docker Engine upgrade from Version 19.03.15 to Version 23.0.5, which introduces a known compatibility issue.
Docker-in-Docker prior to version 20.10 or Kaniko images older than v1.9.0, will be unable to detect the container runtime and fail.
@ -4197,7 +4245,7 @@ The container registry [pull-through cache](https://docs.docker.com/docker-hub/m
</div>
Cookie authentication in the GitLab for Jira Cloud app is now deprecated in favor of OAuth authentication.
On self-managed, you must [set up OAuth authentication](https://docs.gitlab.com/ee/integration/jira/connect-app.html#set-up-oauth-authentication-for-self-managed-instances)
On GitLab Self-Managed, you must [set up OAuth authentication](https://docs.gitlab.com/ee/integration/jira/connect-app.html#set-up-oauth-authentication-for-self-managed-instances)
to continue to use the GitLab for Jira Cloud app. Without OAuth, you can't manage linked namespaces.
</div>
@ -4334,7 +4382,7 @@ For more information, see [the deprecation notes for Consul 1.9.0](https://githu
<div class="deprecation breaking-change" data-milestone="16.0">
### Deprecation and planned removal for `CI_PRE_CLONE_SCRIPT` variable on GitLab SaaS
### Deprecation and planned removal for `CI_PRE_CLONE_SCRIPT` variable on GitLab.com
<div class="deprecation-notes">
@ -4344,7 +4392,7 @@ For more information, see [the deprecation notes for Consul 1.9.0](https://githu
</div>
The [`CI_PRE_CLONE_SCRIPT` variable](https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html#pre-clone-script) supported by GitLab SaaS Runners is deprecated as of GitLab 15.9 and will be removed in 16.0. The `CI_PRE_CLONE_SCRIPT` variable enables you to run commands in your CI/CD job prior to the runner executing Git init and get fetch. For more information about how this feature works, see [Pre-clone script](https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html#pre-clone-script). As an alternative, you can use the [`pre_get_sources_script`](https://docs.gitlab.com/ee/ci/yaml/#hookspre_get_sources_script).
The [`CI_PRE_CLONE_SCRIPT` variable](https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html#pre-clone-script) supported by GitLab.com Runners is deprecated as of GitLab 15.9 and will be removed in 16.0. The `CI_PRE_CLONE_SCRIPT` variable enables you to run commands in your CI/CD job prior to the runner executing Git init and get fetch. For more information about how this feature works, see [Pre-clone script](https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html#pre-clone-script). As an alternative, you can use the [`pre_get_sources_script`](https://docs.gitlab.com/ee/ci/yaml/#hookspre_get_sources_script).
</div>
@ -4419,7 +4467,7 @@ In GitLab 16.0, validation will be added to strictly limit the following to 255
- The `ref`, which is the Git branch or tag name for the pipeline.
- The `description` and `target_url` parameter, used by external CI/CD integrations.
Users on self-managed instances should update their pipelines to ensure they do not use parameters that exceed 255 characters. Users on GitLab.com do not need to make any changes, as these are already limited in that database.
Users on GitLab Self-Managed should update their pipelines to ensure they do not use parameters that exceed 255 characters. Users on GitLab.com do not need to make any changes, as these are already limited in that database.
</div>
@ -4539,7 +4587,7 @@ GitLab self-monitoring gives instance administrators the tools to monitor the he
The GitLab.com importer was deprecated in GitLab 15.8 and will be removed in GitLab 16.0.
The GitLab.com importer was introduced in 2015 for importing a project from GitLab.com to a GitLab Self-Managed instance through the UI.
This feature is available on self-managed instances only. [Migrating GitLab groups and projects by direct transfer](https://docs.gitlab.com/ee/user/group/import/#migrate-groups-by-direct-transfer-recommended)
This feature is available on GitLab Self-Managed only. [Migrating GitLab groups and projects by direct transfer](https://docs.gitlab.com/ee/user/group/import/#migrate-groups-by-direct-transfer-recommended)
supersedes the GitLab.com importer and provides a more cohesive importing functionality.
See [migrated group items](https://docs.gitlab.com/ee/user/group/import/#migrated-group-items) and [migrated project items](https://docs.gitlab.com/ee/user/group/import/#migrated-project-items) for an overview.
@ -4875,7 +4923,7 @@ and `config/redis.shared_state.yml` files.
The group and project deletion protection setting in the **Admin** area had an option to delete groups and projects immediately. Starting with 16.0, this option will no longer be available, and delayed group and project deletion will become the default behavior.
The option will no longer appear as a group setting. Users on GitLab Self-Managed will still have the option to define the deletion delay period, and SaaS users have a non-adjustable default retention period of 7 days. Users can still immediately delete the project from the project settings, and the group from the group settings.
The option will no longer appear as a group setting. Users on GitLab Self-Managed will still have the option to define the deletion delay period, and GitLab.com users have a non-adjustable default retention period of 7 days. Users can still immediately delete the project from the project settings, and the group from the group settings.
The option to delete groups and projects immediately by default was deprecated to prevent users from accidentally taking this action and permanently losing groups and projects.
@ -5328,7 +5376,7 @@ You can use the `vulnerabilityFindingDismiss` GraphQL mutation to set the status
</div>
Using third-party container registries with GitLab as an auth endpoint is deprecated in GitLab 15.8 and the [end of support](https://docs.gitlab.com/ee/development/deprecation_guidelines/#terminology) is scheduled for GitLab 16.0. This impacts self-managed customers that have connected their external registry to the GitLab user interface to find, view, and delete container images.
Using third-party container registries with GitLab as an auth endpoint is deprecated in GitLab 15.8 and the [end of support](https://docs.gitlab.com/ee/development/deprecation_guidelines/#terminology) is scheduled for GitLab 16.0. This impacts users on GitLab Self-Managed that have connected their external registry to the GitLab user interface to find, view, and delete container images.
Supporting both the GitLab container registry as well as third-party container registries is challenging for maintenance, code quality, and backward compatibility. This hinders our ability to stay [efficient](https://handbook.gitlab.com/handbook/values/#efficiency). As a result we will not support this functionality moving forward.
@ -5536,6 +5584,32 @@ We are deprecating support for [uploading backups to remote storage](https://doc
<div class="deprecation breaking-change" data-milestone="15.9">
### GitLab.com certificate-based integration with Kubernetes
<div class="deprecation-notes">
- Announced in GitLab <span class="milestone">14.5</span>
- Removal in GitLab <span class="milestone">15.9</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/groups/gitlab-org/configure/-/epics/8).
</div>
The certificate-based integration with Kubernetes will be [deprecated and removed](https://about.gitlab.com/blog/2021/11/15/deprecating-the-cert-based-kubernetes-integration/). As a GitLab.com user, on new namespaces, you will no longer be able to integrate GitLab and your cluster using the certificate-based approach as of GitLab 15.0. The integration for current users will be enabled per namespace.
For a more robust, secure, forthcoming, and reliable integration with Kubernetes, we recommend you use the
[agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/) to connect Kubernetes clusters with GitLab. [How do I migrate?](https://docs.gitlab.com/ee/user/infrastructure/clusters/migrate_to_gitlab_agent.html)
Although an explicit removal date is set, we don't plan to remove this feature until the new solution has feature parity.
For more information about the blockers to removal, see [this issue](https://gitlab.com/gitlab-org/configure/general/-/issues/199).
For updates and details about this deprecation, follow [this epic](https://gitlab.com/groups/gitlab-org/configure/-/epics/8).
GitLab Self-Managed customers can still use the feature [with a feature flag](https://docs.gitlab.com/ee/update/deprecations.html#self-managed-certificate-based-integration-with-kubernetes).
</div>
<div class="deprecation breaking-change" data-milestone="15.9">
### Live Preview no longer available in the Web IDE
<div class="deprecation-notes">
@ -5552,32 +5626,6 @@ The Live Preview feature of the Web IDE was intended to provide a client-side pr
<div class="deprecation breaking-change" data-milestone="15.9">
### SaaS certificate-based integration with Kubernetes
<div class="deprecation-notes">
- Announced in GitLab <span class="milestone">14.5</span>
- Removal in GitLab <span class="milestone">15.9</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/groups/gitlab-org/configure/-/epics/8).
</div>
The certificate-based integration with Kubernetes will be [deprecated and removed](https://about.gitlab.com/blog/2021/11/15/deprecating-the-cert-based-kubernetes-integration/). As a GitLab SaaS customer, on new namespaces, you will no longer be able to integrate GitLab and your cluster using the certificate-based approach as of GitLab 15.0. The integration for current users will be enabled per namespace.
For a more robust, secure, forthcoming, and reliable integration with Kubernetes, we recommend you use the
[agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/) to connect Kubernetes clusters with GitLab. [How do I migrate?](https://docs.gitlab.com/ee/user/infrastructure/clusters/migrate_to_gitlab_agent.html)
Although an explicit removal date is set, we don't plan to remove this feature until the new solution has feature parity.
For more information about the blockers to removal, see [this issue](https://gitlab.com/gitlab-org/configure/general/-/issues/199).
For updates and details about this deprecation, follow [this epic](https://gitlab.com/groups/gitlab-org/configure/-/epics/8).
GitLab Self-Managed customers can still use the feature [with a feature flag](https://docs.gitlab.com/ee/update/deprecations.html#self-managed-certificate-based-integration-with-kubernetes).
</div>
<div class="deprecation breaking-change" data-milestone="15.9">
### `omniauth-authentiq` gem no longer available
<div class="deprecation-notes">

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

@ -25,17 +25,16 @@ You can use built-in dashboards by GitLab or create your own dashboards with cus
A data source is a connection to a database or collection of data which can be used by your dashboard
filters and visualizations to query and retrieve results.
Analytics dashboards use [Value Stream Management](../analytics/value_streams_dashboard.md) as a data source.
## Built-in dashboards
To help you get started with analytics, GitLab provides built-in dashboards with predefined visualizations.
These dashboards are labeled **By GitLab**.
You cannot edit the built-in dashboards, but you can create custom dashboards with a similar style.
### Value Stream Management dashboard
The following built-in dashboards are available:
- **Value Streams Dashboard** displays metrics related to [DevOps performance, security exposure, and workstream optimization](../analytics/value_streams_dashboard.md#devsecops-metrics-comparison-panels).
- [**Value Streams Dashboard**](../analytics/value_streams_dashboard.md) displays metrics related to DevOps performance, security exposure, and workstream optimization.
- [**AI Impact Dashboard**](../analytics/ai_impact_analytics.md) displays the impact of AI tools on software development lifecycle (SDLC) metrics for a project or group.
## Custom dashboards
@ -113,21 +112,9 @@ To view a list of dashboards (both built-in and custom) for a group:
1. Select **Analyze > Analytics dashboards**.
1. From the list of available dashboards, select the dashboard you want to view.
### View the Value Streams Dashboard
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/132839) in GitLab 16.6 [with a flag](../../administration/feature_flags.md) named `group_analytics_dashboard_dynamic_vsd`. Disabled by default.
> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/432185) in GitLab 17.0.
> - Feature flag `group_analytics_dashboard_dynamic_vsd` [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/441206) in GitLab 17.0.
To view the Value Streams Dashboard as an analytics dashboard for a group:
1. On the left sidebar, select **Search or go to** and find your group.
1. Select **Analyze > Analytics dashboards**.
1. From the list of available dashboards, select **Value Streams Dashboard**.
## Change the location of dashboards
You can change the location of your project or group dashboards.
You can change the location of your project or group custom dashboards.
Prerequisites:
@ -138,7 +125,7 @@ Prerequisites:
NOTE:
[Issue 411572](https://gitlab.com/gitlab-org/gitlab/-/issues/411572) proposes connecting this feature to group-level dashboards.
To change the location of a group's dashboards:
To change the location of a group's custom dashboards:
1. On the left sidebar, select **Search or go to** and find the project you want to store your dashboard files in.
The project must belong to the group for which you create the dashboards.
@ -167,80 +154,6 @@ To change the location of project dashboards:
1. In the **Analytics Dashboards** section, select your dashboard files project.
1. Select **Save changes**.
## Define a dashboard
To define a dashboard:
1. In `.gitlab/analytics/dashboards/`, create a directory named like the dashboard.
Each dashboard should have its own directory.
1. In the new directory, create a `.yaml` file with the same name as the directory, for example `.gitlab/analytics/dashboards/my_dashboard/my_dashboard.yaml`.
This file contains the dashboard definition. It must conform to the JSON schema defined in `ee/app/validators/json_schemas/analytics_dashboard.json`.
1. Optional. To create new visualizations to add to your dashboard, see [defining a chart visualization](#define-a-chart-visualization).
For [example](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/gitlab/analytics/product_analytics/dashboards/audience.yaml), if you want to create three dashboards (Conversion funnels, Demographic breakdown, and North star metrics)
and one visualization (line chart) that applies to all dashboards, the file structure looks like this:
```plaintext
.gitlab/analytics/dashboards
├── conversion_funnels
│ └── conversion_funnels.yaml
├── demographic_breakdown
│ └── demographic_breakdown.yaml
├── north_star_metrics
| └── north_star_metrics.yaml
├── visualizations
│ └── example_line_chart.yaml
```
### Dashboard filters
Dashboards support the following filters:
- **Date range**: Date selector to filter data by date.
- **Anonymous users**: Toggle to include or exclude anonymous users from the dataset.
To enable filters, in the `.yaml` configuration file set the filter's `enabled` option to `true`:
```yaml
title: My dashboard
...
filters:
excludeAnonymousUsers:
enabled: true
dateRange:
enabled: true
```
See a complete [dashboard configuration example](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/gitlab/analytics/product_analytics/dashboards/audience.yaml).
## Define a chart visualization
You can define different charts and add visualization options to some of them, such as:
- Line chart, with the options listed in the [ECharts documentation](https://echarts.apache.org/en/option.html).
- Column chart, with the options listed in the [ECharts documentation](https://echarts.apache.org/en/option.html).
- Data table.
- Single stat, with the only option to set `decimalPlaces` (number, default value is 0).
To define a chart visualization for your dashboards:
1. In the `.gitlab/analytics/dashboards/visualizations/` directory, create a `.yaml` file.
The filename should be descriptive of the visualization it defines.
1. In the `.yaml` file, define the visualization configuration, according to the schema in
`ee/app/validators/json_schemas/analytics_visualization.json`.
For [example](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/gitlab/analytics/product_analytics/visualizations/events_over_time.yaml), to create a line chart that illustrates event count over time, in the `visualizations` folder
create a `line_chart.yaml` file with the following required fields:
- version
- type
- data
- options
To contribute, see [adding a new visualization render type](../../development/fe_guide/customizable_dashboards.md#adding-a-new-visualization-render-type).
## Create a custom dashboard
To create a custom dashboard:
@ -343,6 +256,82 @@ When you change or remove a measure then dependent dimensions may also be remove
<!--- end_remove -->
## Create a dashboard by configuration
For more complex use cases, you can also create dashboards manually by configuration.
To define a dashboard:
1. In `.gitlab/analytics/dashboards/`, create a directory named like the dashboard.
Each dashboard should have its own directory.
1. In the new directory, create a `.yaml` file with the same name as the directory, for example `.gitlab/analytics/dashboards/my_dashboard/my_dashboard.yaml`.
This file contains the dashboard definition. It must conform to the JSON schema defined in `ee/app/validators/json_schemas/analytics_dashboard.json`.
1. Optional. To create new visualizations to add to your dashboard, see [defining a chart visualization](#define-a-chart-visualization).
For [example](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/gitlab/analytics/product_analytics/dashboards/audience.yaml), if you want to create three dashboards (Conversion funnels, Demographic breakdown, and North star metrics)
and one visualization (line chart) that applies to all dashboards, the file structure looks like this:
```plaintext
.gitlab/analytics/dashboards
├── conversion_funnels
│ └── conversion_funnels.yaml
├── demographic_breakdown
│ └── demographic_breakdown.yaml
├── north_star_metrics
| └── north_star_metrics.yaml
├── visualizations
│ └── example_line_chart.yaml
```
### Dashboard filters
Dashboards support the following filters:
- **Date range**: Date selector to filter data by date.
- **Anonymous users**: Toggle to include or exclude anonymous users from the dataset.
To enable filters, in the `.yaml` configuration file set the filter's `enabled` option to `true`:
```yaml
title: My dashboard
...
filters:
excludeAnonymousUsers:
enabled: true
dateRange:
enabled: true
```
See a complete [dashboard configuration example](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/gitlab/analytics/product_analytics/dashboards/audience.yaml).
### Define a chart visualization
You can define different charts and add visualization options to some of them, such as:
- Line chart, with the options listed in the [ECharts documentation](https://echarts.apache.org/en/option.html).
- Column chart, with the options listed in the [ECharts documentation](https://echarts.apache.org/en/option.html).
- Data table.
- Single stat, with the only option to set `decimalPlaces` (number, default value is 0).
To define a chart visualization for your dashboards:
1. In the `.gitlab/analytics/dashboards/visualizations/` directory, create a `.yaml` file.
The filename should be descriptive of the visualization it defines.
1. In the `.yaml` file, define the visualization configuration, according to the schema in
`ee/app/validators/json_schemas/analytics_visualization.json`.
For [example](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/gitlab/analytics/product_analytics/visualizations/events_over_time.yaml), to create a line chart that illustrates event count over time, in the `visualizations` folder
create a `line_chart.yaml` file with the following required fields:
- version
- type
- data
- options
To contribute, see [adding a new visualization render type](../../development/fe_guide/analytics_dashboards.md#adding-a-new-visualization-render-type).
## Troubleshooting
### `Something went wrong while loading the dashboard.`
@ -350,11 +339,11 @@ When you change or remove a measure then dependent dimensions may also be remove
If the dashboard displays a global error message that data could not be loaded, first try reloading the page.
If the error persists:
- Check that your configurations match the [dashboard JSON schema](#define-a-dashboard) defined in `ee/app/validators/json_schemas/analytics_dashboard.json`.
- Check that your configurations match the [dashboard JSON schema](../../development/fe_guide/analytics_dashboards.md) defined in `ee/app/validators/json_schemas/analytics_dashboard.json`.
### `Invalid dashboard configuration`
If the dashboard displays a global error message that the configuration is invalid, check that your configurations match the [dashboard JSON schema](#define-a-dashboard) defined in `ee/app/validators/json_schemas/analytics_dashboard.json`.
If the dashboard displays a global error message that the configuration is invalid, check that your configurations match the [dashboard JSON schema](../../development/fe_guide/analytics_dashboards.md) defined in `ee/app/validators/json_schemas/analytics_dashboard.json`.
### `Invalid visualization configuration`

6
doc/user/analytics/value_streams_dashboard.md
View File

@ -36,6 +36,12 @@ With the Value Streams Dashboard, you can:
For a click-through demo, see [the Value Stream Management product tour](https://gitlab.navattic.com/vsm).
To view the Value Streams Dashboard as an analytics dashboard for a group:
1. On the left sidebar, select **Search or go to** and find your group.
1. Select **Analyze > Analytics dashboards**.
1. From the list of available dashboards, select **Value Streams Dashboard**.
NOTE:
Data displayed on the Value Streams Dashboard is continuously collected in the backend.
If you upgrade to the Ultimate tier, you get access to historical data, and can view metrics about past GitLab usage and performance.

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

@ -95,7 +95,7 @@ Policies enforced on an existing group or subgroup are automatically enforced in
NOTE:
GitLab.com users can enforce policies against their top-level group or across subgroups, but cannot
enforce policies across GitLab.com top-level groups. GitLab Self-Managed users can enforce policies
enforce policies across GitLab.com top-level groups. GitLab Self-Managed administrators can enforce policies
across multiple top-level groups in their instance.
The following example illustrates two groups and their structure:

1
doc/user/duo_amazon_q/setup.md
View File

@ -36,6 +36,7 @@ To set up GitLab Duo with Amazon Q, you must:
- You must have GitLab Self-Managed:
- On GitLab 17.8 or later.
- On an instance in AWS.
- With an HTTPS URL that can be accessed by Amazon Q (the SSL certificate must not be self-signed).
For more details about SSL, see [Configure SSL for a Linux package installation](https://docs.gitlab.com/omnibus/settings/ssl/).
- With an Ultimate subscription that is synchronized with GitLab. (No trial access.)

12
doc/user/gitlab_duo/use_cases.md
View File

@ -11,7 +11,7 @@ The following use cases provide practical examples, exercises, and workflows wit
Learn how to:
- Refactor existing source code.
- Use GitLab Duo Root Cause Analysis to debug problems.
- Use GitLab Duo Root Cause Analysis to troubleshoot failed jobs.
- Solve security vulnerabilities.
NOTE:
@ -56,7 +56,7 @@ you need to configure CI/CD.
Please show a .gitignore and .gitlab-ci.yml configuration for a C# project.
```
- If your CI/CD job fails, use root cause analysis to [troubleshoot failed CI/CD jobs](../gitlab_duo_chat/examples.md#troubleshoot-failed-cicd-jobs-with-root-cause-analysis).
- If your CI/CD job fails, use Root Cause Analysis to [troubleshoot failed CI/CD jobs](../gitlab_duo_chat/examples.md#troubleshoot-failed-cicd-jobs-with-root-cause-analysis).
Alternatively, you can copy the error message into
GitLab Duo Chat, and ask for help:
@ -621,10 +621,10 @@ Resources:
- [Project with source code](https://gitlab.com/gitlab-da/use-cases/ai/gitlab-duo-coffee-chat/gitlab-duo-coffee-chat-2024-02-01)
## Root cause analysis use cases
## Root Cause Analysis use cases
Use root cause analysis to determine the root cause for a CI/CD
pipeline failure. The following examples illustrate common errors, and
Use Root Cause Analysis to determine the root cause of a CI/CD
job failure. The following examples illustrate common errors, and
encourage you to fork and practice finding and fixing the root cause.
For more information, see the blog post [Developing GitLab Duo: Blending AI and Root Cause Analysis to fix CI/CD pipelines](https://about.gitlab.com/blog/2024/06/06/developing-gitlab-duo-blending-ai-and-root-cause-analysis-to-fix-ci-cd/).
@ -650,7 +650,7 @@ The project [Challenge: Root Cause Analysis - Go GitLab Release Fetcher](https:/
provides an exercise to analyze and fix CI/CD problems with a Go Tanuki app. In this exercise,
the `build` and `docker-build` jobs are failing. When you have fixed
the problem, the CI/CD pipeline succeeds and the `build` job prints an output.
The `solution/` directory provides two possible solutions after root cause analysis.
The `solution/` directory provides two possible solutions.
## Use GitLab Duo to contribute to GitLab

52
doc/user/gitlab_duo_chat/examples.md
View File

@ -382,31 +382,47 @@ DETAILS:
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/123692) in GitLab 16.2 as an [experiment](../../policy/development_stages_support.md#experiment) on GitLab.com.
> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/441681) and moved to GitLab Duo Chat in GitLab 17.3.
> - Changed to require GitLab Duo add-on in GitLab 17.6 and later.
> - Failed jobs widget for merge requests [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/174586) in GitLab 17.7.
You can ask GitLab Duo Chat to determine the root cause of a CI/CD job failure by analyzing the logs.
You can use GitLab Duo Root Cause Analysis in GitLab Duo Chat to quickly identify and fix CI/CD job failures.
It analyzes the last 100,000 characters of the job log to determine the cause of failure and provides an example fix.
NOTE:
The last 100,000 characters of the job log are analyzed.
You can access this feature either from the **Pipelines** tab in merge requests or directly from the job log.
Root Cause Analysis does not support:
- Trigger jobs
- Downstream pipelines
Provide feedback on this feature in [epic 13872](https://gitlab.com/groups/gitlab-org/-/epics/13872).
Prerequisites:
- Have permission to view the CI/CD job.
- Have a paid GitLab Duo Enterprise seat.
- You must have permission to view the CI/CD job.
- You must have a paid GitLab Duo Enterprise seat.
To troubleshoot a failed CI/CD job:
### From a merge request
To troubleshoot a failed CI/CD job from a merge request:
1. On the left sidebar, select **Search or go to** and find your project.
1. Go to your merge request.
1. Select the **Pipelines** tab.
1. From the Failed jobs widget, either:
- Select the job ID to go to the job log.
- Select **Troubleshoot** to analyze the failure directly.
### From the job log
To troubleshoot a failed CI/CD job from the job log:
1. On the left sidebar, select **Search or go to** and find your project.
1. Select **Build > Jobs**.
1. Select the failed CI/CD job.
1. From the job log page, do one of the following:
- Below the job log, select **Troubleshoot**.
1. Below the job log, either:
- Select **Troubleshoot**.
- Open GitLab Duo Chat and type `/troubleshoot`.
An analysis of the reasons for the failure and an example fix is displayed.
Provide feedback on this feature in [epic 13872](https://gitlab.com/groups/gitlab-org/-/epics/13872).
## Explain a vulnerability
DETAILS:
@ -464,11 +480,11 @@ DETAILS:
These commands are dynamic and are available only in the GitLab UI when using Duo Chat:
| Command | Purpose | Area |
|------------------------|--------------------------------------------------------------------------------------------------------------------|------------------|
| /summarize_comments | Generate a summary of all comments on the current issue | Issues |
| /troubleshoot | [Troubleshoot failed CI/CD jobs with Root Cause Analysis](#troubleshoot-failed-cicd-jobs-with-root-cause-analysis) | Failed pipelines |
| /vulnerability_explain | [Explain current vulnerability](../application_security/vulnerabilities/index.md#explaining-a-vulnerability) | Vulnerabilities |
| Command | Purpose | Area |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------ | ---- |
| /summarize_comments | Generate a summary of all comments on the current issue | Issues |
| /troubleshoot | [Troubleshoot failed CI/CD jobs with Root Cause Analysis](#troubleshoot-failed-cicd-jobs-with-root-cause-analysis) | Jobs |
| /vulnerability_explain | [Explain current vulnerability](../application_security/vulnerabilities/index.md#explaining-a-vulnerability) | Vulnerabilities |
### IDE

4
doc/user/group/saml_sso/index.md
View File

@ -280,8 +280,8 @@ If [SCIM](scim_setup.md) is configured, see [user access](scim_setup.md#user-acc
When a user tries to sign in with Group SSO, GitLab attempts to find or create a user based on the following:
- Find an existing user with a matching SAML identity. This would mean the user either had their account created by [SCIM](scim_setup.md) or they have previously signed in with the group's SAML IdP.
- If there is no conflicting user with the same email address, create a new account automatically.
- If there is a conflicting user with the same email address, redirect the user to the sign-in page to:
- If an account does not already exist with the same email address, create a new account automatically. GitLab tries to match both the primary and secondary email addresses.
- If an account already exists with the same email address, redirect the user to the sign-in page to:
- Create a new account with another email address.
- Sign-in to their existing account to link the SAML identity.

2
doc/user/infrastructure/clusters/index.md
View File

@ -48,7 +48,7 @@ You can find technical information about why we moved away from cluster certific
the GitLab agent model on the [agent's design document](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/gitlab_to_kubernetes_communication/).
If you need more time to migrate to GitLab agent, you can [enable the feature flag](../../../administration/feature_flags.md)
named `certificate_based_clusters`, which was [introduced in GitLab 15.0](../../../update/deprecations.md#self-managed-certificate-based-integration-with-kubernetes).
named `certificate_based_clusters`, which was [introduced in GitLab 15.0](../../../update/deprecations.md#gitlab-self-managed-certificate-based-integration-with-kubernetes).
This feature flag re-enables the certificate-based Kubernetes integration.
## Deprecated features

4
doc/user/infrastructure/clusters/migrate_to_gitlab_agent.md
View File

@ -20,8 +20,8 @@ The certificate-based integration is
[**deprecated**](https://about.gitlab.com/blog/2021/11/15/deprecating-the-cert-based-kubernetes-integration/)
in GitLab 14.5. The sunsetting plans are described:
- for [GitLab.com customers](../../../update/deprecations.md#saas-certificate-based-integration-with-kubernetes).
- for [Self-managed customers](../../../update/deprecations.md#self-managed-certificate-based-integration-with-kubernetes).
- for [GitLab.com customers](../../../update/deprecations.md#gitlabcom-certificate-based-integration-with-kubernetes).
- for [Self-managed customers](../../../update/deprecations.md#gitlab-self-managed-certificate-based-integration-with-kubernetes).
If you are using the certificate-based integration, you should move to another workflow as soon as possible.

4
doc/user/profile/contributions_calendar.md
View File

@ -107,3 +107,7 @@ To reset your feed token:
1. On the confirmation dialog, select **OK**.
A new token is generated.
### Event time period limit
GitLab removes user activity events older than 3 years from the events table for performance reasons.

18
doc/user/project/import/bitbucket_server.md
View File

@ -85,23 +85,23 @@ The following items are changed when they are imported:
- Project filtering doesn't support fuzzy search. Only **starts with** or **full match** strings are
supported.
## User contribution mapping
## User contribution and membership mapping
> - User mapping by email address or username [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36885) in GitLab 13.4 [with a flag](../../../administration/feature_flags.md) named `bitbucket_server_user_mapping_by_username`. Disabled by default.
> - Mapping user mentions to GitLab users [added](https://gitlab.com/gitlab-org/gitlab/-/issues/433008) in GitLab 16.8.
> - [Changed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/153041) to map users only by email address in GitLab 17.1.
> - [Changed on GitLab.com](https://gitlab.com/groups/gitlab-org/-/epics/14667) to [User contribution and membership mapping](../import/index.md#user-contribution-and-membership-mapping) in 17.8.
> - [Changed on GitLab.com](https://gitlab.com/groups/gitlab-org/-/epics/14667) to [user contribution and membership mapping](../import/index.md#user-contribution-and-membership-mapping) in GitLab 17.8.
> - [Enabled on GitLab.com and GitLab Self-Managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/176675) in GitLab 17.8.
The Bitbucket Server importer uses [an improved method](../import/index.md#user-contribution-and-membership-mapping)
of mapping user contributions for:
- GitLab.com
- GitLab Self-Managed 17.7 or later when the `importer_user_mapping` and `bitbucket_server_user_mapping` feature flags are enabled.
The Bitbucket Server importer uses an [improved method](../import/index.md#user-contribution-and-membership-mapping)
of mapping user contributions for GitLab.com and GitLab Self-Managed.
### Old method of user contribution mapping
You can use the old user contribution mapping method for imports to GitLab Self-Managed and GitLab Dedicated instances. For imports to GitLab.com, you must
use [the improved method](../import/index.md#user-contribution-and-membership-mapping) instead.
You can use the old user contribution mapping method for imports to GitLab Self-Managed and GitLab Dedicated instances.
To use this method, `importer_user_mapping` and `bulk_import_importer_user_mapping` must be disabled.
For imports to GitLab.com, you must
use the [improved method](../import/index.md#user-contribution-and-membership-mapping) instead.
Using the old method, the importer tries to match a Bitbucket Server user's email address with a confirmed email address in the GitLab user database. If no
such user is found:

18
doc/user/project/import/gitea.md
View File

@ -89,19 +89,19 @@ You also can:
imports only selected projects.
- Choose a different name for the project and a different namespace if you have the privileges to do so.
## User contribution mapping
## User contribution and membership mapping
> - [Changed on GitLab.com](https://gitlab.com/groups/gitlab-org/-/epics/14667) to [User contribution and membership mapping](../import/index.md#user-contribution-and-membership-mapping) in 17.8.
> - [Changed on GitLab.com](https://gitlab.com/groups/gitlab-org/-/epics/14667) to [user contribution and membership mapping](../import/index.md#user-contribution-and-membership-mapping) in GitLab 17.8.
> - [Enabled on GitLab.com and GitLab Self-Managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/176675) in GitLab 17.8.
The Gitea importer uses [an improved method](../import/index.md#user-contribution-and-membership-mapping)
of mapping user contributions for:
- GitLab.com
- GitLab Self-Managed 17.6 or later when the `importer_user_mapping` and `gitea_user_mapping` feature flags are enabled.
The Gitea importer uses an [improved method](../import/index.md#user-contribution-and-membership-mapping)
of mapping user contributions for GitLab.com and GitLab Self-Managed.
### Old method of user contribution mapping
You can use the old user contribution mapping method for imports to GitLab Self-Managed and GitLab Dedicated instances. For imports to GitLab.com, you must
use [the improved method](../import/index.md#user-contribution-and-membership-mapping) instead.
You can use the old user contribution mapping method for imports to GitLab Self-Managed and GitLab Dedicated instances.
To use this method, `importer_user_mapping` and `bulk_import_importer_user_mapping` must be disabled.
For imports to GitLab.com, you must
use the [improved method](../import/index.md#user-contribution-and-membership-mapping) instead.
Using the old method, user contributions are assigned to the project creator (usually the user who started the import process) by default.

20
doc/user/project/import/github.md
View File

@ -65,7 +65,7 @@ on the GitLab instance you import to.
> - [Preparation requirement removed on GitLab.com](https://gitlab.com/groups/gitlab-org/-/epics/14667) in GitLab 17.8.
Before using [the old method of user contribution mapping](#old-method-of-user-contribution-mapping) for imports to GitLab Self-Managed and GitLab
Dedicated, you must meet certain requirements. Imports to GitLab.com use [an improved method](../import/index.md#user-contribution-and-membership-mapping)
Dedicated, you must meet certain requirements. Imports to GitLab.com use an [improved method](../import/index.md#user-contribution-and-membership-mapping)
that doesn't require preparation.
These requirements are:
@ -245,20 +245,20 @@ Expand **Details** to see a list of [repository entities](#imported-data) that f
GitLab adds backticks to username mentions in issues, merge requests, and notes.
These backticks prevent linking to an incorrect user with the same username on the GitLab instance.
## User contribution mapping
## User contribution and membership mapping
> - [Changed on GitLab.com](https://gitlab.com/groups/gitlab-org/-/epics/14667) to [User contribution and membership mapping](../import/index.md#user-contribution-and-membership-mapping) in 17.8.
> - [Changed on GitLab.com](https://gitlab.com/groups/gitlab-org/-/epics/14667) to [user contribution and membership mapping](../import/index.md#user-contribution-and-membership-mapping) in GitLab 17.8.
> - [Enabled on GitLab.com and GitLab Self-Managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/176675) in GitLab 17.8.
The GitHub importer uses [an improved method](../import/index.md#user-contribution-and-membership-mapping)
of mapping user contributions for:
- GitLab.com
- GitLab Self-Managed 17.6 or later when the `importer_user_mapping` and `github_user_mapping` feature flags are enabled.
The GitHub importer uses an [improved method](../import/index.md#user-contribution-and-membership-mapping)
of mapping user contributions for GitLab.com and GitLab Self-Managed.
### Old method of user contribution mapping
You can use the old user contribution mapping method for imports to GitLab Self-Managed and GitLab Dedicated instances. For imports to GitLab.com, you must
use [the improved method](../import/index.md#user-contribution-and-membership-mapping) instead.
You can use the old user contribution mapping method for imports to GitLab Self-Managed and GitLab Dedicated instances.
To use this method, `importer_user_mapping` and `bulk_import_importer_user_mapping` must be disabled.
For imports to GitLab.com, you must
use the [improved method](../import/index.md#user-contribution-and-membership-mapping) instead.
Using the old method, when [user accounts are provisioned correctly](#accounts-for-user-contribution-mapping), users are mapped during the import.

12
doc/user/project/import/index.md
View File

@ -85,12 +85,12 @@ difficult, but several tools exist including:
DETAILS:
**Offering:** GitLab.com, GitLab Self-Managed
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/443557) for direct transfer in GitLab 17.4 [with flags](../../../administration/feature_flags.md) named `importer_user_mapping` and `bulk_import_importer_user_mapping`. Disabled by default.
> - Introduced in GitLab 17.6 [for Gitea](https://gitlab.com/gitlab-org/gitlab/-/issues/467084) [with flags](../../../administration/feature_flags.md) named `importer_user_mapping` and `gitea_user_mapping`, and [for GitHub](https://gitlab.com/gitlab-org/gitlab/-/issues/466355) with flags named `importer_user_mapping` and `github_user_mapping`. Disabled by default.
> - Introduced in GitLab 17.7 [for Bitbucket Server](https://gitlab.com/gitlab-org/gitlab/-/issues/466356) [with flags](../../../administration/feature_flags.md) named `importer_user_mapping` and `bitbucket_server_user_mapping`. Disabled by default.
> - [Enabled on GitLab.com and GitLab Self-Managed](https://gitlab.com/gitlab-org/gitlab/-/issues/472735) for direct transfer in GitLab 17.7.
> - Enabled on GitLab.com for [GitHub](https://gitlab.com/gitlab-org/gitlab/-/issues/499993), [Bitbucket Server](https://gitlab.com/gitlab-org/gitlab/-/issues/509897), and [Gitea](https://gitlab.com/gitlab-org/gitlab/-/issues/498390) in GitLab 17.7.
> - Enabled on GitLab Self-Managed for [GitHub](https://gitlab.com/gitlab-org/gitlab/-/issues/499993), [Bitbucket Server](https://gitlab.com/gitlab-org/gitlab/-/issues/509897) and [Gitea](https://gitlab.com/gitlab-org/gitlab/-/issues/498390) in GitLab 17.8.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/443557) in GitLab 17.4 for direct transfer [with flags](../../../administration/feature_flags.md) named `importer_user_mapping` and `bulk_import_importer_user_mapping`. Disabled by default.
> - Introduced in GitLab 17.6 for [Gitea](https://gitlab.com/gitlab-org/gitlab/-/issues/467084) [with flags](../../../administration/feature_flags.md) named `importer_user_mapping` and `gitea_user_mapping`, and for [GitHub](https://gitlab.com/gitlab-org/gitlab/-/issues/466355) with flags named `importer_user_mapping` and `github_user_mapping`. Disabled by default.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/466356) in GitLab 17.7 for Bitbucket Server [with flags](../../../administration/feature_flags.md) named `importer_user_mapping` and `bitbucket_server_user_mapping`. Disabled by default.
> - [Enabled on GitLab.com and GitLab Self-Managed](https://gitlab.com/gitlab-org/gitlab/-/issues/472735) in GitLab 17.7 for direct transfer.
> - Enabled on GitLab.com in GitLab 17.7 for [Bitbucket Server](https://gitlab.com/gitlab-org/gitlab/-/issues/509897), [Gitea](https://gitlab.com/gitlab-org/gitlab/-/issues/498390), and [GitHub](https://gitlab.com/gitlab-org/gitlab/-/issues/499993).
> - Enabled on GitLab Self-Managed in GitLab 17.8 for [Bitbucket Server](https://gitlab.com/gitlab-org/gitlab/-/issues/509897), [Gitea](https://gitlab.com/gitlab-org/gitlab/-/issues/498390), and [GitHub](https://gitlab.com/gitlab-org/gitlab/-/issues/499993).
FLAG:
The availability of this feature is controlled by feature flags.

11
doc/user/project/releases/index.md
View File

@ -386,15 +386,14 @@ For more information, see [Deployment safety](../../../ci/environments/deploymen
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/216485) in GitLab 15.6.
Releases can be made accessible to non-project members while keeping repository-related information such as
[source code](release_fields.md#source-code) and [release evidence](release_evidence.md) private. Use this for
projects that use releases as a way to give access to new versions of software but do not want the source code to
be public.
You can make releases accessible to non-project members while keeping repository-related information, such as [source code](release_fields.md#source-code) and [release evidence](release_evidence.md), available only to project members. These settings are ideal for
projects that use releases to give access to new versions of software, but do not want the source code to be publicly available.
To make releases available publicly, set the following [project settings](../settings/index.md#configure-project-features-and-permissions):
- Repository is enabled and set to **Only Project Members**
- Releases is enabled and set to **Everyone With Access**
- **Project visibility** is set to **Public**
- **Repository** is enabled and set to **Only Project Members**
- **Releases** is enabled and set to **Everyone With Access**
### Create, update, and delete a release and its assets

2
doc/user/project/repository/code_suggestions/troubleshooting.md
View File

@ -67,7 +67,7 @@ For non-Code Suggestions troubleshooting for VS Code, see [Troubleshooting the G
### Suggestions not displayed in VS Code or GitLab Web IDE
If you are a self-managed user, ensure that Code Suggestions for the [GitLab Web IDE](../../../project/web_ide/index.md) is enabled. The same settings apply to VS Code as local IDE.
If you are on GitLab Self-Managed, ensure that Code Suggestions for the [GitLab Web IDE](../../../project/web_ide/index.md) is enabled. The same settings apply to VS Code as local IDE.
1. On the left sidebar, select **Extensions > GitLab Workflow**.
1. Select **Settings** (**{settings}**), and then select **Extension Settings**.

2
doc/user/project/settings/import_export_troubleshooting.md
View File

@ -181,7 +181,7 @@ it is terminated during execution.
GitLab.com users should [contact Support](https://about.gitlab.com/support/#contact-support) to resolve this issue.
Self-managed users can use the Rails console to bypass the Sidekiq process and
GitLab Self-Managed administrators can use the Rails console to bypass the Sidekiq process and
manually trigger the project export:
```ruby

4
doc/user/project/working_with_projects.md
View File

@ -390,6 +390,10 @@ To view the activity of a project:
- **Designs**: Designs added, updated, and removed in the project.
- **Team**: Members who joined and left the project.
### Event time period limit
GitLab removes project activity events older than 3 years from the events table for performance reasons.
## Search in projects
To search through your projects, on the left sidebar, select **Search or go to**.

29
doc/user/todos.md
View File

@ -160,6 +160,35 @@ You can mark all your to-do items as done at the same time.
In the To-Do List, in the upper-right corner, select **Mark all as done**.
## Snooze to-do items
You can snooze to-do items to temporarily hide them from your main To-Do List. This allows you to focus on more urgent tasks and return to snoozed items later.
To snooze a to-do item:
1. In your To-Do List, next to the to-do item you want to snooze, select Snooze (**{clock}**).
1. Choose one of the preset snooze durations:
- For one hour
- Until later today (4 hours later)
- Until tomorrow (tomorrow at 8 AM local time)
Snoozed to-do items are removed from your main To-Do List and appear in a separate **Snoozed** tab.
When the snooze period ends, the to-do item automatically returns to your main To-Do List. It appears with an indicator showing when it was originally created.
## View snoozed to-do items
To view or manage your snoozed to-do items:
1. Go to your To-Do List.
1. At the top of the list, select the Snoozed tab.
From the Snoozed tab, you can:
- View when a snoozed to-do is scheduled to return to your main list.
- Remove the snooze to immediately return an item to your main To-Do List.
- Mark a snoozed to-do as done.
## How a user's To-Do List is affected when their access changes
For security reasons, GitLab deletes to-do items when a user no longer has access to a related resource.

35
lib/api/users.rb
View File

@ -232,10 +232,7 @@ module API
end
get ":user_id/status", requirements: API::USER_REQUIREMENTS, feature_category: :user_profile, urgency: :default do
if Feature.enabled?(:rate_limiting_user_endpoints, ::Feature.current_request)
check_rate_limit!(
:user_status,
scope: request.ip
)
check_rate_limit_by_user_or_ip!(:user_status)
end
user = find_user(params[:user_id])
@ -300,10 +297,7 @@ module API
unless current_user.can_read_all_resources?
if Feature.enabled?(:rate_limiting_user_endpoints, ::Feature.current_request)
check_rate_limit!(
:user_following,
scope: request.ip
)
check_rate_limit_by_user_or_ip!(:user_following)
end
end
@ -325,10 +319,7 @@ module API
unless current_user.can_read_all_resources?
if Feature.enabled?(:rate_limiting_user_endpoints, ::Feature.current_request)
check_rate_limit!(
:user_followers,
scope: request.ip
)
check_rate_limit_by_user_or_ip!(:user_followers)
end
end
@ -542,10 +533,7 @@ module API
end
get ':user_id/keys', requirements: API::USER_REQUIREMENTS, feature_category: :system_access do
if Feature.enabled?(:rate_limiting_user_endpoints, ::Feature.current_request)
check_rate_limit!(
:user_keys,
scope: request.ip
)
check_rate_limit_by_user_or_ip!(:user_keys)
end
user = find_user(params[:user_id])
@ -564,10 +552,7 @@ module API
end
get ':id/keys/:key_id', requirements: API::USER_REQUIREMENTS, feature_category: :system_access do
if Feature.enabled?(:rate_limiting_user_endpoints, ::Feature.current_request)
check_rate_limit!(
:user_specific_key,
scope: request.ip
)
check_rate_limit_by_user_or_ip!(:user_specific_key)
end
user = find_user(params[:id])
@ -639,10 +624,7 @@ module API
# rubocop: disable CodeReuse/ActiveRecord
get ':id/gpg_keys', feature_category: :system_access do
if Feature.enabled?(:rate_limiting_user_endpoints, ::Feature.current_request)
check_rate_limit!(
:user_gpg_keys,
scope: request.ip
)
check_rate_limit_by_user_or_ip!(:user_gpg_keys)
end
user = User.find_by(id: params[:id])
@ -663,10 +645,7 @@ module API
# rubocop: disable CodeReuse/ActiveRecord
get ':id/gpg_keys/:key_id', feature_category: :system_access do
if Feature.enabled?(:rate_limiting_user_endpoints, ::Feature.current_request)
check_rate_limit!(
:user_specific_gpg_key,
scope: request.ip
)
check_rate_limit_by_user_or_ip!(:user_specific_gpg_key)
end
user = User.find_by(id: params[:id])

19
lib/gitlab/ci/lint.rb
View File

@ -81,7 +81,7 @@ module Gitlab
logger.instrument(:yaml_process, once: true) do
Gitlab::Ci::YamlProcessor.new(content, project: project,
user: current_user,
ref: RefFinder.new(project).find_by_sha(sha),
ref: find_ref,
sha: sha,
verify_project_sha: verify_project_sha,
logger: logger).execute
@ -144,6 +144,23 @@ module Gitlab
end
end
end
def find_ref
ref = RefFinder.new(project).find_by_sha(sha)
return unless ref
allowed_to_write_ref?(ref) ? ref : nil
end
def allowed_to_write_ref?(ref)
access = Gitlab::UserAccess.new(current_user, container: project)
# We only check access for protected branches and not for protected tags
# because it's not possible to perform static validation on a protected tag
# as we initialize a new `Ci::Pipeline` in `Ci::Config` and do not pass `tag: true`.
access.can_update_branch?(ref)
end
end
end
end

13
lib/tasks/gitlab/seed/group_seed.rake
View File

@ -11,21 +11,22 @@
#
# @param subgroups_depth - number of subgroup levels
# @param username - user creating subgroups (i.e. GitLab admin)
# @param organization_path - organization where the groups will be created
#
# @example
# bundle exec rake "gitlab:seed:group_seed[5, root]"
# bundle exec rake "gitlab:seed:group_seed[5, root, default]"
#
namespace :gitlab do
namespace :seed do
desc 'Seed groups with sub-groups/projects/epics/milestones for Group Import testing'
task :group_seed, [:subgroups_depth, :username] => :gitlab_environment do |_t, args|
task :group_seed, [:subgroups_depth, :username, :organization_path] => :gitlab_environment do |_t, args|
require 'sidekiq/testing'
require_relative '../../../gitlab/faker/internet'
GroupSeeder.new(
subgroups_depth: args.subgroups_depth,
username: args.username,
organization: Organizations::Organization.default_organization
organization_path: args.organization_path
).seed
end
end
@ -36,17 +37,19 @@ class GroupSeeder
attr_reader :all_group_ids
def initialize(subgroups_depth:, username:, organization:)
def initialize(subgroups_depth:, username:, organization_path:)
@subgroups_depth = subgroups_depth.to_i
@user = User.find_by_username(username)
@group_names = Set.new
@resource_count = 2
@all_groups = {}
@all_group_ids = []
@organization = organization
@organization = Organizations::Organization.find_by_path(organization_path)
end
def seed
raise 'User must belong to the organization' unless @organization.user?(@user)
create_groups
puts 'Done!'

48
spec/controllers/projects/ci/lints_controller_spec.rb
View File

@ -2,7 +2,7 @@
require 'spec_helper'
RSpec.describe Projects::Ci::LintsController do
RSpec.describe Projects::Ci::LintsController, feature_category: :pipeline_composition do
include StubRequests
let_it_be(:project) { create(:project, :repository) }
@ -163,16 +163,54 @@ RSpec.describe Projects::Ci::LintsController do
end
end
context 'without enough privileges' do
context 'when the current user cannot run pipelines at all' do
before do
project.add_guest(user)
post :create, params: { namespace_id: project.namespace, project_id: project, content: content }
end
it 'responds with 404' do
it 'responds with a 404' do
post :create, params: { namespace_id: project.namespace, project_id: project, content: content }
expect(response).to have_gitlab_http_status(:not_found)
end
end
context 'when the current user cannot run pipelines on protected branches' do
# The create action lints the given CI config as if it was on the default branch.
# The default branch is protected by default, which means it can access protected variables.
# Developers don't have permission to access protected variables,
# so we can't allow them to use this endpoint.
let(:content) do
<<~HEREDOC
include:
- #{remote_file_path}
rubocop:
script:
- bundle exec rubocop
HEREDOC
end
let(:remote_file_path) { 'https://test.example.com/${SECRET_TOKEN}.yml' }
before do
project.add_developer(user)
sha = project.repository.commit.sha # this is always the sha used by this endpoint for linting
ref = Gitlab::Ci::RefFinder.new(project).find_by_sha(sha)
create(:protected_branch, name: ref, project: project)
create(:ci_variable, key: 'SECRET_TOKEN', value: 'secret!!!!!', project: project, protected: true)
end
it 'does not expand protected variables' do
post :create, params: { namespace_id: project.namespace, project_id: project, content: content }
expect(parsed_body['errors']).to match_array([
'Included file `https://test.example.com/.yml` does not have YAML extension!'
])
end
end
end
end

4
spec/dot_gitlab_ci/ci_configuration_validation/branch_pipeline_spec.rb
View File

@ -58,8 +58,8 @@ RSpec.describe 'CI configuration validation - branch pipelines', feature_categor
end
end
context 'with gitlab.com gitlab-org/gitlab ruby3_3 branch scheduled pipeline' do
let(:ci_commit_branch) { 'ruby3_3' }
context 'with gitlab.com gitlab-org/gitlab ruby-next branch scheduled pipeline' do
let(:ci_commit_branch) { 'ruby-next' }
let(:ci_pipeline_source) { 'schedule' }
let(:expected_job_name) { 'ruby_syntax: [${RUBY_VERSION_DEFAULT}]' }
let(:variables_attributes) do

15
spec/factories/description_version.rb Normal file
View File

@ -0,0 +1,15 @@
# frozen_string_literal: true
FactoryBot.define do
factory :description_version do
description { generate(:title) }
trait :issue do
association :issue
end
trait :merge_request do
association :merge_request
end
end
end

8
spec/factories/issue_user_mentions.rb Normal file
View File

@ -0,0 +1,8 @@
# frozen_string_literal: true
FactoryBot.define do
factory :issue_user_mention do
association :issue
association :note
end
end

4
spec/features/users/show_spec.rb
View File

@ -187,7 +187,7 @@ RSpec.describe 'User page', feature_category: :user_profile do
context 'with private profile' do
let_it_be(:user) { create(:user, private_profile: true) }
it 'shows no page content container' do
it 'shows no page content container', :aggregate_failures do
subject
expect(page).to have_css("div.profile-header")
@ -198,6 +198,8 @@ RSpec.describe 'User page', feature_category: :user_profile do
subject
expect(page).to have_content("This user has a private profile")
expect(page).not_to have_content("Info")
expect(page).not_to have_content("Member since")
end
end

3
spec/frontend/vue_shared/components/blob_viewers/rich_viewer_spec.js
View File

@ -38,7 +38,8 @@ describe('Blob Rich Viewer component', () => {
generatedContent += `<span>Line: ${i + 1}</span>\n`;
}
generatedContent += '<img src="x" onerror="alert(`XSS`)">'; // for testing against XSS
generatedContent +=
'<img src="x" onerror="alert(`XSS`)" style="position:fixed;" data-lines-path="test/xss.json" data-remote="xss">'; // for testing against XSS
return `<div class="js-markup-content">${generatedContent}</div>`;
};

129
spec/lib/gitlab/ci/lint_spec.rb
View File

@ -3,7 +3,7 @@
require 'spec_helper'
RSpec.describe Gitlab::Ci::Lint, feature_category: :pipeline_composition do
let_it_be(:project) { create(:project, :repository) }
let_it_be_with_refind(:project) { create(:project, :repository) }
let_it_be(:user) { create(:user) }
let(:sha) { nil }
@ -370,6 +370,72 @@ RSpec.describe Gitlab::Ci::Lint, feature_category: :pipeline_composition do
it_behaves_like 'when sha is not provided'
context 'when the content contains protected variables' do
let(:content) do
<<~HEREDOC
include:
- 'https://test.example.com/${SECRET_TOKEN}.yml'
rubocop:
script:
- bundle exec rubocop
HEREDOC
end
before do
create(:ci_variable, key: 'SECRET_TOKEN', value: 'secret!!!!!', project: project, protected: true)
project.add_maintainer(user)
stub_request(:get, "https://test.example.com/secret!!!!!.yml")
end
context 'when the ref is a protected branch' do
before do
create(:protected_branch, project: project, name: 'master')
end
it 'expands the protected variables' do
expect(subject).not_to be_valid
expect(subject.errors).to include(
'Included file `https://test.example.com/secret!!!!!.yml` is empty or does not exist!'
)
end
end
context 'when the ref is a protected tag' do
let(:sha) do
project.repository.create_file(
project.creator,
'test.yml',
'',
message: 'Created test.yml',
branch_name: 'new-branch'
)
end
before do
project.repository.add_tag(project.creator, '6.6.6', sha)
project.repository.rm_branch(project.creator, 'new-branch')
create(:protected_tag, project: project, name: '6.6.6')
end
after do
project.repository.rm_tag(project.creator, '6.6.6')
end
# We don't mark pipelines as `tag` during static validation, so we never expand protected variables for
# tags even if the tag is protected.
it 'does not expand protected variables' do
expect(subject).not_to be_valid
expect(subject.errors).to include(
'Included file `https://test.example.com/.yml` does not have YAML extension!'
)
end
end
end
context 'when sha is provided' do
let(:sha) { project.commit.sha }
@ -477,6 +543,17 @@ RSpec.describe Gitlab::Ci::Lint, feature_category: :pipeline_composition do
end
context 'when user does not have permissions to write the ref' do
let(:content) do
<<~HEREDOC
include:
- 'https://test.example.com/${SECRET_TOKEN}.yml'
rubocop:
script:
- bundle exec rubocop
HEREDOC
end
before do
project.add_reporter(user)
end
@ -484,7 +561,55 @@ RSpec.describe Gitlab::Ci::Lint, feature_category: :pipeline_composition do
context 'when using default static mode' do
let(:dry_run) { false }
it_behaves_like 'content is valid'
before do
create(:ci_variable, key: 'SECRET_TOKEN', value: 'secret!!!!!', project: project, protected: true)
end
context 'when the ref is a protected branch' do
before do
sha = project.repository.commit.sha
ref = Gitlab::Ci::RefFinder.new(project).find_by_sha(sha)
create(:protected_branch, project: project, name: ref)
end
it 'does not expand protected variables' do
expect(subject).not_to be_valid
expect(subject.errors).to include(
'Included file `https://test.example.com/.yml` does not have YAML extension!'
)
end
end
context 'when the ref is a protected tag' do
let(:sha) do
project.repository.create_file(
project.creator,
'test.yml',
'',
message: 'Created test.yml',
branch_name: 'new-branch'
)
end
before do
project.repository.add_tag(project.creator, '6.6.6', sha)
project.repository.rm_branch(project.creator, 'new-branch')
create(:protected_tag, project: project, name: '6.6.6')
end
after do
project.repository.rm_tag(project.creator, '6.6.6')
end
it 'does not expand protected variables' do
expect(subject).not_to be_valid
expect(subject.errors).to include(
'Included file `https://test.example.com/.yml` does not have YAML extension!'
)
end
end
end
context 'when using dry run mode' do

1
spec/lib/gitlab/import_export/all_models.yml
View File

@ -901,6 +901,7 @@ project:
- security_policies
- approval_policy_rule_project_links
- approval_policy_rules
- security_pipeline_execution_config_links
- secrets_manager
- observability_metrics
- observability_traces

7
spec/models/alert_management/alert_user_mention_spec.rb
View File

@ -2,7 +2,7 @@
require 'spec_helper'
RSpec.describe AlertManagement::AlertUserMention do
RSpec.describe AlertManagement::AlertUserMention, feature_category: :incident_management do
describe 'associations' do
it do
is_expected.to belong_to(:alert).class_name('::AlertManagement::Alert')
@ -12,5 +12,8 @@ RSpec.describe AlertManagement::AlertUserMention do
it { is_expected.to belong_to(:note) }
end
it_behaves_like 'has user mentions'
it_behaves_like 'has user mentions' do
let_it_be(:mentionable_key) { 'alert_management_alert_id' }
let_it_be(:mentionable) { create(:alert_management_alert) }
end
end

6
spec/models/anti_abuse/reports/user_mention_spec.rb
View File

@ -8,5 +8,9 @@ RSpec.describe AntiAbuse::Reports::UserMention, feature_category: :insider_threa
it { is_expected.to belong_to(:note).optional(false) }
end
it_behaves_like 'has user mentions'
it_behaves_like 'has user mentions' do
let_it_be(:mentionable_key) { 'abuse_report_id' }
let_it_be(:user) { create(:user, :with_namespace) }
let_it_be(:mentionable) { create(:abuse_report, user: user) }
end
end

13
spec/models/award_emoji_spec.rb
View File

@ -120,8 +120,12 @@ RSpec.describe AwardEmoji, feature_category: :team_planning do
end
describe 'scopes' do
let_it_be(:thumbsup) { create(:award_emoji, name: 'thumbsup') }
let_it_be(:thumbsdown) { create(:award_emoji, name: 'thumbsdown') }
let_it_be(:awardable1) { create(:issue) }
let_it_be(:awardable2) { create(:issue) }
let_it_be(:thumbsup) { create(:award_emoji, name: 'thumbsup', awardable: awardable1) }
let_it_be(:thumbsdown) { create(:award_emoji, name: 'thumbsdown', awardable: awardable2) }
let(:awardables) { [awardable1, awardable2] }
describe '.upvotes' do
it { expect(described_class.upvotes).to contain_exactly(thumbsup) }
@ -140,6 +144,11 @@ RSpec.describe AwardEmoji, feature_category: :team_planning do
it { expect(described_class.awarded_by(thumbsup.user)).to contain_exactly(thumbsup) }
it { expect(described_class.awarded_by([thumbsup.user, thumbsdown.user])).to contain_exactly(thumbsup, thumbsdown) }
end
describe '.by_awardable' do
it { expect(described_class.by_awardable('Issue', awardables)).to match_array([thumbsup, thumbsdown]) }
it { expect(described_class.by_awardable('Issue', awardables.map(&:id))).to match_array([thumbsup, thumbsdown]) }
end
end
describe 'broadcasting updates' do

7
spec/models/design_user_mention_spec.rb
View File

@ -2,11 +2,14 @@
require 'spec_helper'
RSpec.describe DesignUserMention do
RSpec.describe DesignUserMention, feature_category: :team_planning do
describe 'associations' do
it { is_expected.to belong_to(:design) }
it { is_expected.to belong_to(:note) }
end
it_behaves_like 'has user mentions'
it_behaves_like 'has user mentions' do
let_it_be(:mentionable_key) { 'design_id' }
let_it_be(:mentionable) { create(:design) }
end
end

14
spec/models/system_note_metadata_spec.rb
View File

@ -2,7 +2,7 @@
require 'spec_helper'
RSpec.describe SystemNoteMetadata do
RSpec.describe SystemNoteMetadata, feature_category: :team_planning do
describe 'associations' do
it { is_expected.to belong_to(:note) }
it { is_expected.to belong_to(:description_version) }
@ -37,4 +37,16 @@ RSpec.describe SystemNoteMetadata do
it { is_expected.to be_valid }
end
end
describe 'scopes' do
describe '.for_notes' do
let_it_be(:notes) { create_list(:note, 2) }
let_it_be(:metadata1) { create(:system_note_metadata, note: notes[0]) }
let_it_be(:metadata2) { create(:system_note_metadata, note: notes[1]) }
it { expect(described_class.for_notes(notes)).to match_array([metadata1, metadata2]) }
it { expect(described_class.for_notes(notes.map(&:id))).to match_array([metadata1, metadata2]) }
it { expect(described_class.for_notes(::Note.id_in(notes))).to match_array([metadata1, metadata2]) }
end
end
end

7
spec/models/user_mentions/commit_user_mention_spec.rb
View File

@ -2,10 +2,13 @@
require 'spec_helper'
RSpec.describe CommitUserMention do
RSpec.describe CommitUserMention, feature_category: :code_review_workflow do
describe 'associations' do
it { is_expected.to belong_to(:note) }
end
it_behaves_like 'has user mentions'
it_behaves_like 'has user mentions' do
let_it_be(:mentionable_key) { 'commit_id' }
let_it_be(:mentionable) { create(:commit, project: create(:project), commit_message: 'test') }
end
end

7
spec/models/user_mentions/issue_user_mention_spec.rb
View File

@ -2,11 +2,14 @@
require 'spec_helper'
RSpec.describe IssueUserMention do
RSpec.describe IssueUserMention, feature_category: :team_planning do
describe 'associations' do
it { is_expected.to belong_to(:issue) }
it { is_expected.to belong_to(:note) }
end
it_behaves_like 'has user mentions'
it_behaves_like 'has user mentions' do
let_it_be(:mentionable_key) { 'issue_id' }
let_it_be(:mentionable) { create(:issue) }
end
end

7
spec/models/user_mentions/merge_request_user_mention_spec.rb
View File

@ -2,11 +2,14 @@
require 'spec_helper'
RSpec.describe MergeRequestUserMention do
RSpec.describe MergeRequestUserMention, feature_category: :code_review_workflow do
describe 'associations' do
it { is_expected.to belong_to(:merge_request) }
it { is_expected.to belong_to(:note) }
end
it_behaves_like 'has user mentions'
it_behaves_like 'has user mentions' do
let_it_be(:mentionable_key) { 'merge_request_id' }
let_it_be(:mentionable) { create(:merge_request) }
end
end

7
spec/models/user_mentions/snippet_user_mention_spec.rb
View File

@ -2,11 +2,14 @@
require 'spec_helper'
RSpec.describe SnippetUserMention do
RSpec.describe SnippetUserMention, feature_category: :source_code_management do
describe 'associations' do
it { is_expected.to belong_to(:snippet) }
it { is_expected.to belong_to(:note) }
end
it_behaves_like 'has user mentions'
it_behaves_like 'has user mentions' do
let_it_be(:mentionable_key) { 'snippet_id' }
let_it_be(:mentionable) { create(:project_snippet) }
end
end

5
spec/models/wikis/user_mention_spec.rb
View File

@ -8,5 +8,8 @@ RSpec.describe Wikis::UserMention, feature_category: :wiki do
it { is_expected.to belong_to(:note).optional(false) }
end
it_behaves_like 'has user mentions'
it_behaves_like 'has user mentions' do
let_it_be(:mentionable_key) { 'wiki_page_meta_id' }
let_it_be(:mentionable) { create(:wiki_page_meta, container: create(:group)) }
end
end

Some files were not shown because too many files have changed in this diff Show More