Add latest changes from gitlab-org/gitlab@master

4 files changed, 78 insertions, 66 deletions

diff --git a/doc/development/ai_features.md b/doc/development/ai_features.md
index 11442755df3..8e2746276a1 100644
--- a/doc/development/ai_features.md
+++ b/doc/development/ai_features.md
@@ -192,7 +192,7 @@ The CircuitBreaker concern is a reusable module that you can include in any clas
 
 ### Use CircuitBreaker
 
-To use the CircuitBreaker concern, you need to include it in a class and define the `service_name` method, which should return the name of the service that the circuit breaker is protecting. For example:
+To use the CircuitBreaker concern, you need to include it in a class. For example:
 
 ```ruby
 class MyService
@@ -202,22 +202,16 @@ class MyService
     run_with_circuit do
       # Code that interacts with external service goes here
 
-      raise MyCustomError
+      raise InternalServerError
     end
   end
-
-  private
-
-  def service_name
-    my_service
-  end
 end
 ```
 
 The `call_external_service` method is an example method that interacts with an external service.
 By wrapping the code that interacts with the external service with `run_with_circuit`, the method is executed within the circuit breaker.
 The circuit breaker is created and configured by the `circuit` method, which is called automatically when the `CircuitBreaker` module is included.
-The method should raise a custom error, that matches the `exceptions` from the concern.
+The method should raise `InternalServerError` error which will be counted towards the error threshold if raised during the execution of the code block.
 
 The circuit breaker tracks the number of errors and the rate of requests,
 and opens the circuit if it reaches the configured error threshold or volume threshold.
@@ -231,12 +225,11 @@ The circuit breaker is configured with two constants which control the number of
 - `VOLUME_THRESHOLD`
 
 You can adjust these values as needed for the specific service and usage pattern.
-The concern also raises an `InternalServerError` exception, which is counted towards the error threshold if raised during the execution of the code block.
+The `InternalServerError` is the exception class counted towards the error threshold if raised during the execution of the code block.
 This is the exception class that triggers the circuit breaker when raised by the code that interacts with the external service.
-By default, the `CircuitBreaker` concern uses `StandardError`.
 
 NOTE:
-The service_name method must be implemented by the including class to provide a unique identifier for the service being protected. The `CircuitBreaker` module depends on the `Circuitbox` gem to provide the circuit breaker implementation.
+The `CircuitBreaker` module depends on the `Circuitbox` gem to provide the circuit breaker implementation. By default, the service name is inferred from the class name where the concern module is included. Override the `service_name` method if the name needs to be different.
 
 ### Testing
 
@@ -413,58 +406,6 @@ end
 
 TODO
 
-## Circuit Breaker concern
-
-The `CircuitBreaker` concern is a reusable module that can be included in any class that needs to run code with circuit breaker protection. The concern provides a `run_with_circuit` method that wraps a code block with circuit breaker functionality, which can help prevent cascading failures and improve the resilience of the system. Resources about the circuit breaker pattern:
-
-- [What is Circuit breaker](https://martinfowler.com/bliki/CircuitBreaker.html)
-- [How it works](https://github.com/Netflix/Hystrix/wiki/How-it-Works#circuit-breaker)
-
-The CircuitBreaker module depends on the [Circuitbox](https://github.com/yammer/circuitbox) gem to provide the circuit breaker implementation.
-
-### Usage
-
-To use the `CircuitBreaker` concern, include it in a class and define the `service_name` method, which should return the name of the service that the circuit breaker is protecting. For example:
-
-```ruby
-class MyService
-  include Gitlab::Llm::Concerns::CircuitBreaker
-
-  def call_external_service
-    run_with_circuit do
-      # Code that interacts with external service goes here
-
-      raise InternalServerError
-    end
-  end
-
-  private
-
-  def service_name
-    :my_service
-  end
-end
-```
-
-The `call_external_service` method is an example method that interacts with an external service. By wrapping the code that interacts with the external service with `run_with_circuit`, the method will be executed within the circuit breaker. The circuit breaker is created and configured by the `circuit` method, which is called automatically when the `CircuitBreaker` module is included. The method should raise `InternalServerError` error which will be counted towards the error threshold if raised during the execution of the code block.
-
-The circuit breaker will track the number of errors and the rate of requests, and open the circuit if it reaches the configured error threshold or volume threshold. If the circuit is open, subsequent requests will fail fast without executing the code block, and the circuit breaker will periodically allow a small number of requests through to test the service's availability before closing the circuit again.
-
-### Configuration
-
-The circuit breaker is configured with two constants: `ERROR_THRESHOLD` and `VOLUME_THRESHOLD`, which control the number of errors and requests at which the circuit will open. These values can be adjusted as needed for the specific service and usage pattern. The `InternalServerError` is the exception class that will trigger the circuit breaker when raised by the code that interacts with the external service.
-
-### Testing
-
-To test code that uses the `CircuitBreaker` concern, use RSpec shared examples and pass the `service` and `subject` variables:
-
-```ruby
-it_behaves_like 'has circuit breaker' do
-  let(:service) { dummy_class.new }
-  let(:subject) { service.dummy_method }
-end
-```
-
 ## Security
 
 Refer to the [secure coding guidelines for Artificial Intelligence (AI) features](secure_coding_guidelines.md#artificial-intelligence-ai-features).
diff --git a/doc/development/features_inside_dot_gitlab.md b/doc/development/features_inside_dot_gitlab.md
index f35b37db84e..3c988ec6b21 100644
--- a/doc/development/features_inside_dot_gitlab.md
+++ b/doc/development/features_inside_dot_gitlab.md
@@ -9,7 +9,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 We have implemented standard features that depend on configuration files in the `.gitlab/` directory. You can find `.gitlab/` in various GitLab repositories.
 When implementing new features, please refer to these existing features to avoid conflicts:
 
-- [Custom Dashboards](../operations/metrics/dashboards/index.md#add-a-new-dashboard-to-your-project): `.gitlab/dashboards/`.
 - [Issue Templates](../user/project/description_templates.md#create-an-issue-template): `.gitlab/issue_templates/`.
 - [Merge request Templates](../user/project/description_templates.md#create-a-merge-request-template): `.gitlab/merge_request_templates/`.
 - [GitLab agent](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/configuration_repository.md#layout): `.gitlab/agents/`.
diff --git a/doc/development/internal_users.md b/doc/development/internal_users.md
index 541a7117c6a..ce13324507d 100644
--- a/doc/development/internal_users.md
+++ b/doc/development/internal_users.md
@@ -40,7 +40,7 @@ For this bot:
 
 Other examples of internal users:
 
-- [Alert Bot](../operations/metrics/alerts.md#trigger-actions-from-alerts)
+- [Alert Bot](../operations/incident_management/alerts.md#trigger-actions-from-alerts)
 - [Ghost User](../user/profile/account/delete_account.md#associated-records)
 - [Support Bot](../user/project/service_desk.md#support-bot-user)
 - Visual Review Bot
diff --git a/doc/development/sec/CycloneDX_property_taxonomy.md b/doc/development/sec/CycloneDX_property_taxonomy.md
new file mode 100644
index 00000000000..6d09529a194
--- /dev/null
+++ b/doc/development/sec/CycloneDX_property_taxonomy.md
@@ -0,0 +1,72 @@
+---
+stage: Govern
+group: Threat Insights
+info: BEFORE MAKING CHANGES TO THIS FILE, PLEASE REACH OUT TO THE THREAT INSIGHTS ENGINEERING TEAM, @gitlab-org/govern/threat-insights.  To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# GitLab CycloneDX property taxonomy
+
+This document defines the namespaces and properties used by the `gitlab` namespace
+in the [CycloneDX Property Taxonomy](https://github.com/CycloneDX/cyclonedx-property-taxonomy).
+
+## Where properties should be located
+
+The `Property of` column describes what object a property may be attached to.
+
+- Properties attached to the `metadata` apply to all objects in the document.
+- Properties attached to an individual object apply to that object and any others nested underneath it.
+- Objects which may nest themselves (such as `components`) may only have properties applied to the top-level object.
+
+## `gitlab` namespace taxonomy
+
+| Namespace             | Description |
+| --------------------- | ----------- |
+| `meta`                | Namespace for data about the property schema. |
+| `dependency_scanning` | Namespace for data related to dependency scanning. |
+
+## `gitlab:meta` namespace taxonomy
+
+| Property                     | Description | Property of |
+| ---------------------------- | ----------- | ----------- |
+| `gitlab:meta:schema_version` | Used by GitLab to determine how to parse the properties in a report. Must be `1`. | `metadata` |
+
+## `gitlab:dependency_scanning` namespace taxonomy
+
+### Properties
+
+| Property                                 | Description | Example values | Property of |
+| ---------------------------------------- | ----------- | -------------- | ----------- |
+| `gitlab:dependency_scanning:category`    | The name of the category or dependency group that the dependency belongs to. If no category is specified, `production` is used by default. | `production`, `development`, `test` | `components` |
+
+### Namespaces
+
+| Namespace                                    | Description |
+| -------------------------------------------- | ----------- |
+| `gitlab:dependency_scanning:input_file`      | Namespace for information about the input file analyzed to produce the dependency. |
+| `gitlab:dependency_scanning:source_file`     | Namespace for information about the file you can edit to manage the dependency. |
+| `gitlab:dependency_scanning:package_manager` | Namespace for information about the package manager associated with the dependency. |
+| `gitlab:dependency_scanning:language`        | Namespace for information about the programming language associated with the dependency. |
+
+## `gitlab:dependency_scanning:input_file` namespace taxonomy
+
+| Property                                      | Description | Example values | Property of |
+| --------------------------------------------- | ----------- | -------------- | ----------- |
+| `gitlab:dependency_scanning:input_file:path` | The path, relative to the root of the repository, to the file analyzed to produce the dependency. Usually, the lock file. | `package-lock.json`, `Gemfile.lock`, `go.sum` | `metadata`, `component` |
+
+## `gitlab:dependency_scanning:source_file` namespace taxonomy
+
+| Property                                     | Description | Example values | Property of |
+| -------------------------------------------- | ----------- | -------------- | ----------- |
+| `gitlab:dependency_scanning:source_file:path` | The path, relative to the root of the repository, to the file you can edit to manage the dependency. | `package.json`, `Gemfile`, `go.mod` | `metadata`, `component` |
+
+## `gitlab:dependency_scanning:package_manager` namespace taxonomy
+
+| Property                                          | Description | Example values | Property of |
+| ------------------------------------------------- | ----------- | -------------- | ----------- |
+| `gitlab:dependency_scanning:package_manager:name` | The name of the package manager associated with the dependency | `npm`, `bundler`, `go` | `metadata`, `component` |
+
+## `gitlab:dependency_scanning:language` namespace taxonomy
+
+| Property                                   | Description | Example values | Property of |
+| ------------------------------------------ | ----------- | -------------- | ----------- |
+| `gitlab:dependency_scanning:language:name` | The name of the programming language associated with the dependency | `JavaScript`, `Ruby`, `Go` | `metadata`, `component` |