Add latest changes from gitlab-org/gitlab@master

6 files changed, 34 insertions, 34 deletions

diff --git a/doc/architecture/blueprints/clickhouse_usage/index.md b/doc/architecture/blueprints/clickhouse_usage/index.md
index 8a5530313e5..0629756c5d9 100644
--- a/doc/architecture/blueprints/clickhouse_usage/index.md
+++ b/doc/architecture/blueprints/clickhouse_usage/index.md
@@ -20,6 +20,12 @@ participating-stages: ["~section::ops", "~section::dev"]
 
 In FY23-Q2, the Monitor:Observability team developed and shipped a [ClickHouse data platform](https://gitlab.com/groups/gitlab-org/-/epics/7772) to store and query data for Error Tracking and other observability features. Other teams have also begun to incorporate ClickHouse into their current or planned architectures. Given the growing interest in ClickHouse across product development teams, it is important to have a cohesive strategy for developing features using ClickHouse. This will allow teams to more efficiently leverage ClickHouse and ensure that we can maintain and support this functionality effectively for SaaS and self-managed customers.
 
+### Use Cases
+
+Many product teams at GitLab are considering ClickHouse when developing new features and to improve performance of existing features.
+
+During the start of the ClickHouse working group, we [documented existing and potential use cases](https://gitlab.com/groups/gitlab-com/-/epics/2075#use-cases) and found that there was interest in ClickHouse from teams across all DevSecOps stage groups.
+
 ### Goals
 
 As ClickHouse has already been selected for use at GitLab, our main goal now is to ensure successful adoption of ClickHouse across GitLab. It is helpful to break down this goal according to the different phases of the product development workflow.
@@ -29,29 +35,18 @@ As ClickHouse has already been selected for use at GitLab, our main goal now is
 1. Launch: Support ClickHouse-backed features for SaaS and self-managed.
 1. Improve: Successfully scale our usage of ClickHouse.
 
-### Non-Goals
-
 ## Proposals
 
 The following are links to proposals in the form of blueprints that address technical challenges to using ClickHouse across a wide variety of features.
 
-1. Scalable data ingestion pipeline.
+1. [Scalable data ingestion pipeline](../clickhouse_ingestion_pipeline/index.md).
     - How do we ingest large volumes of data from GitLab into ClickHouse either directly or by replicating existing data?
-1. Supporting ClickHouse for self-managed installations.
-    - For which use-cases and scales does it make sense to run ClickHouse for self-managed and what are the associated costs?
-    - How can we best support self-managed installation of ClickHouse for different types/sizes of environments?
-    - Consider using the [Opstrace ClickHouse operator](https://gitlab.com/gitlab-org/opstrace/opstrace/-/tree/main/clickhouse-operator) as the basis for a canonical distribution.
-    - Consider exposing Clickhouse backend as [GitLab Plus](https://gitlab.com/groups/gitlab-org/-/epics/308) to combine benefits of using self-managed instance and GitLab-managed database.
-    - Should we develop abstractions for querying and data ingestion to avoid requiring ClickHouse for small-scale installations?
-1. Abstraction layer for features to leverage both ClickHouse or PostreSQL.
+1. [Abstraction layer](../clickhouse_read_abstraction_layer/index.md) for features to leverage both ClickHouse and PostgreSQL.
     - What are the benefits and tradeoffs? For example, how would this impact our automated migration and query testing?
-1. Security recommendations and secure defaults for ClickHouse usage.
-
-Note that we are still formulating proposals and will update the blueprint accordingly.
 
 ## Best Practices
 
-Best practices and guidelines for developing performant and scalable features using ClickHouse are located in the [ClickHouse developer documentation](../../../development/database/clickhouse/index.md).
+Best practices and guidelines for developing performant, secure, and scalable features using ClickHouse are located in the [ClickHouse developer documentation](../../../development/database/clickhouse/index.md).
 
 ## Cost and maintenance analysis
 
diff --git a/doc/ci/runners/saas/gpu_saas_runner.md b/doc/ci/runners/saas/gpu_saas_runner.md
index 7b83f6593a0..041da269e1d 100644
--- a/doc/ci/runners/saas/gpu_saas_runner.md
+++ b/doc/ci/runners/saas/gpu_saas_runner.md
@@ -15,9 +15,9 @@ GitLab provides GPU-enabled runners only on Linux. For more information about ho
 
 The following machine types are available for GPU-enabled runners on Linux x86-64.
 
-| Runner Tag                             | vCPUs | Memory | Storage | GPU                                |
-|----------------------------------------|-------|--------|---------|------------------------------------|
-| `saas-linux-medium-amd64-gpu-standard` | 4     | 16 GB  | 50 GB   | 1 Nvidia Tesla T4 GPU (or similar) |
+| Runner Tag                             | vCPUs | Memory | Storage | GPU                            |
+|----------------------------------------|-------|--------|---------|--------------------------------|
+| `saas-linux-medium-amd64-gpu-standard` | 4     | 16 GB  | 50 GB   | 1 Nvidia Tesla T4 (or similar) |
 
 ## Container images with GPU drivers
 
diff --git a/doc/ci/runners/saas/windows_saas_runner.md b/doc/ci/runners/saas/windows_saas_runner.md
index fa981bddff3..450af236599 100644
--- a/doc/ci/runners/saas/windows_saas_runner.md
+++ b/doc/ci/runners/saas/windows_saas_runner.md
@@ -12,7 +12,7 @@ the Google Cloud Platform. This solution uses an
 developed by GitLab for the [custom executor](https://docs.gitlab.com/runner/executors/custom.html).
 
 These SaaS runners are in [Beta](../../../policy/experiment-beta-support.md#beta)
-and aren't recomended for production workloads.
+and aren't recommended for production workloads.
 
 We want to keep iterating to get Windows runners in a stable state and
 [generally available](../../../policy/experiment-beta-support.md#generally-available-ga).
diff --git a/doc/development/ai_features.md b/doc/development/ai_features.md
index 21d5bb97d56..ff3d97f52b6 100644
--- a/doc/development/ai_features.md
+++ b/doc/development/ai_features.md
@@ -97,7 +97,7 @@ For features that use the embedding database, additional setup is needed.
    Feature.enable(:ai_redis_cache)
    ```
 
-1. Ensure that your current branch is up-to-date with `master`. 
+1. Ensure that your current branch is up-to-date with `master`.
 1. To access the GitLab Chat interface, in the lower-left corner of any page, select **Help** and **Ask GitLab Chat**.
 
 #### Tips for local development
@@ -170,6 +170,22 @@ Feature.enable(:anthropic_experimentation)
 Gitlab::CurrentSettings.update!(anthropic_api_key: <insert API key>)
 ```
 
+### Testing GitLab Chat with predefined questions
+
+Because success of answers to user questions in GitLab Chat heavily depends on toolchain and prompts of each tool, it's common that even a minor change in a prompt or a tool impacts processing of some questions. To make sure that a change in the toolchain doesn't break existing functionality, you can use following commands to validate answers to some predefined questions:
+
+1. Rake task which iterates through questions defined in CSV file and checks tools used for evaluating each question.
+
+```ruby
+rake gitlab:llm:zero_shot:test:questions[<issue_url>]
+```
+
+1. RSpec which iterates through resource-specific questions on predefined resources:
+
+```ruby
+ANTHROPIC_API_KEY='<key>' REAL_AI_REQUEST=1 rspec ee/spec/lib/gitlab/llm/chain/agents/zero_shot/executor_spec.rb
+```
+
 ## Experimental REST API
 
 Use the [experimental REST API endpoints](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/api/ai/experimentation) to quickly experiment and prototype AI features.
diff --git a/doc/security/token_overview.md b/doc/security/token_overview.md
index 5a772106562..80dbe8c03cc 100644
--- a/doc/security/token_overview.md
+++ b/doc/security/token_overview.md
@@ -139,7 +139,10 @@ Each user has a long-lived feed token that does not expire. This token allows au
 - RSS readers to load a personalized RSS feed.
 - Calendar applications to load a personalized calendar.
 
-This token is visible in those feed URLs. You cannot use this token to access any other data.
+You cannot use this token to access any other data.
+
+The user-scoped feed token can be used for all feeds, however feed and calendar URLs are generated
+with a different token that is only valid for one feed.
 
 Anyone who has your token can read activity and issue RSS feeds or your calendar feed as if they were you, including confidential issues. If that happens, [reset the token](../user/profile/contributions_calendar.md#reset-the-user-activity-feed-token).
 
diff --git a/doc/user/group/compliance_frameworks.md b/doc/user/group/compliance_frameworks.md
index 7d81fc11bd0..267cdbbebd3 100644
--- a/doc/user/group/compliance_frameworks.md
+++ b/doc/user/group/compliance_frameworks.md
@@ -364,20 +364,6 @@ This alternative ensures the compliance pipeline does not re-start the parent pi
 
 ## Troubleshooting
 
-### Cannot remove compliance framework from a project
-
-Because of a [known issue](https://gitlab.com/gitlab-org/gitlab/-/issues/390626), if you move a project, its compliance
-framework becomes orphaned and can't be removed. To manually remove a compliance framework from a project, run the
-following GraphQL mutation with your project's ID:
-
-```graphql
-mutation {
-  projectSetComplianceFramework(input: {projectId: "gid://gitlab/Project/1234567", complianceFrameworkId: null}) {
-    errors
-  }
-}
-```
-
 ### Compliance jobs are overwritten by target repository
 
 If you use the `extends` statement in a compliance pipeline configuration, compliance jobs are overwritten by the target repository job. For example,