diff --git a/doc/administration/appearance.md b/doc/administration/appearance.md
index a0c6ed82644ab918e51a150882818d165f030c34..29d68310c75b44dcef28345014dbc731d37569c8 100644
--- a/doc/administration/appearance.md
+++ b/doc/administration/appearance.md
@@ -204,7 +204,7 @@ To [change the default color theme](../user/profile/preferences.md#change-the-co
1. [Reconfigure and restart GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation).
-As of GitLab 17.8, `gitlab_default_theme` can specify [a value from 1 to 10](https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/17.8.0+ee.0/files/gitlab-config-template/gitlab.rb.template?ref_type=tags#L137) to set the default theme.
+As of GitLab 17.8, `gitlab_default_theme` can specify [a value from 1 to 10](https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/17.8.0+ee.0/files/gitlab-config-template/gitlab.rb.template?ref_type=tags#L137) to set the default theme.
| Value | Color |
| ------ | ------ |
diff --git a/doc/administration/auth/oidc.md b/doc/administration/auth/oidc.md
index 6e24292fbd2ec63d7635c2070081b2667b67fd56..6e3b412e986c916873c740ad9fee3804d2e28e48 100644
--- a/doc/administration/auth/oidc.md
+++ b/doc/administration/auth/oidc.md
@@ -156,7 +156,7 @@ The OpenID Connect provider provides you with a client's details and secret for
but you can override these icons by specifying this parameter. GitLab accepts both
local paths and absolute URLs.
GitLab includes icons for most major social login platforms,
- but you can override these icons by specifying an external URL or
+ but you can override these icons by specifying an external URL or
an absolute or relative path to your own icon file.
- For local absolute paths, configure the provider settings as `icon: <path>/<to>/<your-icon>`.
- Store the icon file in `/opt/gitlab/embedded/service/gitlab-rails/public/<path>/<to>/<your-icon>`.
diff --git a/doc/administration/geo/replication/troubleshooting/common.md b/doc/administration/geo/replication/troubleshooting/common.md
index f7b20eaf489845f3109377e0ce1483d8c3bc0ba2..d148a98948155b1acffd65bd18250d0eecdc765c 100644
--- a/doc/administration/geo/replication/troubleshooting/common.md
+++ b/doc/administration/geo/replication/troubleshooting/common.md
@@ -429,7 +429,7 @@ This situation can occur:
```
1. Reconfigure GitLab:
-
+
```shell
sudo gitlab-ctl reconfigure
```
diff --git a/doc/administration/packages/container_registry_metadata_database.md b/doc/administration/packages/container_registry_metadata_database.md
index 0a48fe3c6585c59c32d42a109907789e5c5d4e55..4feb9dc570cc7e1178ae76c4083880ef511b0ec2 100644
--- a/doc/administration/packages/container_registry_metadata_database.md
+++ b/doc/administration/packages/container_registry_metadata_database.md
@@ -394,7 +394,7 @@ to see how to monitor the progress and health of the online garbage collector.
The container registry supports two types of migrations:
- **Regular schema migrations**: Changes to the database structure that must run before deploying new application code. These should be fast (no more than a few minutes) to avoid deployment delays.
-
+
- **Post-deployment migrations**: Changes to the database structure that can run while the application is running. Used for longer operations like creating indexes on large tables, avoiding startup delays and extended upgrade downtimes.
By default, the registry applies both regular schema and post-deployment migrations simultaneously. To reduce downtime during upgrades, you can skip post-deployment migrations and apply them manually after the application starts.
diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md
index 06653d1eb6df34d837eaee6be5792ecd2b12ddc6..baf14d8c004edaf335cc5e1e6333f3f74af74f20 100644
--- a/doc/ci/docker/using_docker_build.md
+++ b/doc/ci/docker/using_docker_build.md
@@ -971,14 +971,14 @@ environment where custom or private certificates are used (for example, Zscaler
error pulling image configuration: download failed after attempts=6: tls: failed to verify certificate: x509: certificate signed by unknown authority
```
-This error occurs because Docker commands in a Docker-in-Docker environment
+This error occurs because Docker commands in a Docker-in-Docker environment
use two separate containers:
- The **build container** runs the Docker client (`/usr/bin/docker`) and executes your job's script commands.
- The **service container** (often named `svc`) runs the Docker daemon that processes most Docker commands.
-When your organization uses custom certificates, both containers need these certificates.
-Without proper certificate configuration in both containers, Docker operations that connect to external
+When your organization uses custom certificates, both containers need these certificates.
+Without proper certificate configuration in both containers, Docker operations that connect to external
registries or services will fail with certificate errors.
To resolve this issue:
diff --git a/doc/ci/environments/_index.md b/doc/ci/environments/_index.md
index bee9be7d2ef27b2a897a05c772ffeba67e637a6c..93429d7e50f5147132a29722b80a11203ac4fa5f 100644
--- a/doc/ci/environments/_index.md
+++ b/doc/ci/environments/_index.md
@@ -479,9 +479,9 @@ the `stop` trigger is automatically enabled.
In the following example, the `deploy_review` job calls a `stop_review` job to clean up and stop
the environment.
-- When the [**Pipelines must succeed**](../../user/project/merge_requests/auto_merge.md#require-a-successful-pipeline-for-merge) setting is turned on,
- you can configure the [`allow_failure: true`](../yaml/_index.md#allow_failure)
-keyword on the `stop_review` job to prevent it from
+- When the [**Pipelines must succeed**](../../user/project/merge_requests/auto_merge.md#require-a-successful-pipeline-for-merge) setting is turned on,
+ you can configure the [`allow_failure: true`](../yaml/_index.md#allow_failure)
+keyword on the `stop_review` job to prevent it from
blocking your pipelines and merge requests.
```yaml
diff --git a/doc/development/api_styleguide.md b/doc/development/api_styleguide.md
index a356991bd17b8105bbd283e30fbb1626f029d821..626fe94f416adfc899391144c33db2feefca54f5 100644
--- a/doc/development/api_styleguide.md
+++ b/doc/development/api_styleguide.md
@@ -77,7 +77,7 @@ end
We must not make breaking changes to our REST API v4, even in major GitLab releases. See [what is a breaking change](#what-is-a-breaking-change) and [what is not a breaking change](#what-is-not-a-breaking-change).
Our REST API maintains its own versioning independent of GitLab versioning.
-The current REST API version is `4`. Because [we commit to follow semantic versioning for our REST API](../api/rest/_index.md), we cannot make breaking changes to it. A major version change for our REST API (most likely, `5`) is currently not planned, or scheduled.
+The current REST API version is `4`. Because [we commit to follow semantic versioning for our REST API](../api/rest/_index.md), we cannot make breaking changes to it. A major version change for our REST API (most likely, `5`) is currently not planned, or scheduled.
The exception is API features that are [marked as experimental or beta](#experimental-beta-and-generally-available-features). These features can be removed or changed at any time.
diff --git a/doc/development/deleting_data.md b/doc/development/deleting_data.md
index 672689c2955d0b7af5ba7129ea4d66405fc21801..dc36f359aabd2eee065952ee8c4275ae369ece70 100644
--- a/doc/development/deleting_data.md
+++ b/doc/development/deleting_data.md
@@ -26,7 +26,7 @@ Specifically, avoid invoking the following classes:
### For projects
-Instead of using `Projects::DestroyService`, use `Projects::MarkForDeletionService`.
+Instead of using `Projects::DestroyService`, use `Projects::MarkForDeletionService`.
```ruby
Projects::MarkForDeletionService.new(project, current_user).execute
@@ -34,7 +34,7 @@ Projects::MarkForDeletionService.new(project, current_user).execute
### For groups
-Instead of using `Groups::DestroyService`, use `Groups::MarkForDeletionService`.
+Instead of using `Groups::DestroyService`, use `Groups::MarkForDeletionService`.
```ruby
Groups::MarkForDeletionService.new(group, current_user).execute
diff --git a/doc/development/graphql_guide/monitoring.md b/doc/development/graphql_guide/monitoring.md
index 12830cbaaf7a7baef9696d5ae4f8c5663b4c1531..d8b05abd3579b90b8d08feda062b339b3aa635aa 100644
--- a/doc/development/graphql_guide/monitoring.md
+++ b/doc/development/graphql_guide/monitoring.md
@@ -74,7 +74,7 @@ Below are some examples of common Kibana filters.
[See example filter](https://log.gprd.gitlab.net/app/r/s/cWkK1).
-As mentioned [above](#logs-of-each-graphql-query), `json.meta.caller_id` appears as `graphql:<operation_name>` for queries that
+As mentioned [above](#logs-of-each-graphql-query), `json.meta.caller_id` appears as `graphql:<operation_name>` for queries that
came from the GitLab frontend, otherwise as `graphql:unknown`. This filter be used to identify internal versus external queries.
1. Combine the [subcomponent filter](#logs-of-each-graphql-query) with the following Kibana filter:
diff --git a/doc/development/npmjs.md b/doc/development/npmjs.md
index 1cbc7e1e577dfac92c62990bceb8e97a361c6b8d..ebac8b321a99922e4abaa81cf0d8f21e36fe34b0 100644
--- a/doc/development/npmjs.md
+++ b/doc/development/npmjs.md
@@ -76,7 +76,7 @@ To set up publishing through GitLab CI/CD:
### Example CI/CD configuration
-Below is an example `.gitlab-ci.yml` configuration for publishing an NPM package. This codeblock isn't meant to be used as-is and will require changes depending on your configuration. This means that you will need to modify the example below to include the location of your npmjs publishing token.
+Below is an example `.gitlab-ci.yml` configuration for publishing an NPM package. This codeblock isn't meant to be used as-is and will require changes depending on your configuration. This means that you will need to modify the example below to include the location of your npmjs publishing token.
```yaml
stages:
diff --git a/doc/development/python_guide/deployment.md b/doc/development/python_guide/deployment.md
index faec13aec5468065781285d48811e29a0323709c..f95258d9a3b32a4e93532f55e581ff0cfcf8867c 100644
--- a/doc/development/python_guide/deployment.md
+++ b/doc/development/python_guide/deployment.md
@@ -90,7 +90,7 @@ version `19.5`, this would need three deployments of the service:
- One for service version `18.11`, which provides support for all GitLab `18.x` versions
- One for service version `19.5`, which provides support for GitLab versions `19.0`-`19.5`.
-Once version 18.0 is released, unused code from versions 17.x can be safely removed, since a legacy deployment will be present.
+Once version 18.0 is released, unused code from versions 17.x can be safely removed, since a legacy deployment will be present.
Then, once version 20.0 is released, and GitLab version 17.x is not supported anymore, the legacy deployment can also be removed.
#### Publishing images
diff --git a/doc/development/testing_guide/end_to_end/_index.md b/doc/development/testing_guide/end_to_end/_index.md
index 0258ae174ff388ca5ce86904011abffb678caa5a..18514b26d071da6f7505fb5d2df03359f0fcc8a0 100644
--- a/doc/development/testing_guide/end_to_end/_index.md
+++ b/doc/development/testing_guide/end_to_end/_index.md
@@ -119,7 +119,7 @@ There is a risk in skipping end-to-end tests. Use caution and discretion when ap
#### Dynamic parallel job scaling
-To maintain consistent pipeline run times, the CI/CD job count for each particular E2E test suite is scaled dynamically based on total run time of tests in the suite.
+To maintain consistent pipeline run times, the CI/CD job count for each particular E2E test suite is scaled dynamically based on total run time of tests in the suite.
The [`generate_e2e_pipelines`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/qa/tasks/ci.rake?ref_type=heads) Rake task creates CI/CD YAML files that:
- Create the correct number of parallel jobs.
diff --git a/doc/integration/jira/configure.md b/doc/integration/jira/configure.md
index 45d6f25f1f3858754b9e2375304c0d298903d619..3c6220e134e73dc7f36f0da224895942e0f48555 100644
--- a/doc/integration/jira/configure.md
+++ b/doc/integration/jira/configure.md
@@ -246,7 +246,7 @@ To copy the API token, select **Copy**.
To migrate from one Jira site to another in GitLab and maintain your Jira issues integration:
1. Follow the steps in [configure the integration](#configure-the-integration).
-1. Enter the new Jira site URL (for example, `https://myjirasite.atlassian.net`).
+1. Enter the new Jira site URL (for example, `https://myjirasite.atlassian.net`).
To update existing Jira issue references in GitLab to use the new Jira site URL, you must
[invalidate the Markdown cache](../../administration/invalidate_markdown_cache.md#invalidate-the-cache).
diff --git a/doc/solutions/components/_index.md b/doc/solutions/components/_index.md
index 70b4562ed585dd9ba2d67db550226e22d3d4c11a..767c0de943c8dfe185628fd4c2336b00c171f63f 100644
--- a/doc/solutions/components/_index.md
+++ b/doc/solutions/components/_index.md
@@ -6,9 +6,9 @@ title: Solution Components
---
This documentation section covers a variety of Solution components developed and provided by GitLab.
-To download and run these solution components, request your account team for invitation code.
+To download and run these solution components, request your account team for invitation code.
-The use of any Solution component is subject to the [GitLab Subscription Agreement](https://handbook.gitlab.com/handbook/legal/subscription-agreement/) (the "Agreement") and constitutes Free Software as defined within the Agreement.
+The use of any Solution component is subject to the [GitLab Subscription Agreement](https://handbook.gitlab.com/handbook/legal/subscription-agreement/) (the "Agreement") and constitutes Free Software as defined within the Agreement.
## DevSecOps Workflow
diff --git a/doc/solutions/components/duo_workflow/_index.md b/doc/solutions/components/duo_workflow/_index.md
index 6309ac927db38a461772c1e2fbb565966bcb8649..46b97cfe811638d3a26bdc7adb3fa3eac28d3325 100644
--- a/doc/solutions/components/duo_workflow/_index.md
+++ b/doc/solutions/components/duo_workflow/_index.md
@@ -6,9 +6,9 @@ title: GitLab AI Solution Components
---
This documentation section covers a variety of Solution components developed and provided by GitLab.
-To download and run these solution components, request your account team for invitation code.
+To download and run these solution components, request your account team for invitation code.
-The use of any Solution component is subject to the [GitLab Subscription Agreement](https://handbook.gitlab.com/handbook/legal/subscription-agreement/) (the "Agreement") and constitutes Free Software as defined within the Agreement.
+The use of any Solution component is subject to the [GitLab Subscription Agreement](https://handbook.gitlab.com/handbook/legal/subscription-agreement/) (the "Agreement") and constitutes Free Software as defined within the Agreement.
## GitLab Duo Workflow
diff --git a/doc/solutions/components/duo_workflow/duo_workflow_codestyle.md b/doc/solutions/components/duo_workflow/duo_workflow_codestyle.md
index 54dafed7ff5022c0e00128928ed75956315f5251..41afa24a371dee40359b69d193a53b4b8dc12771 100644
--- a/doc/solutions/components/duo_workflow/duo_workflow_codestyle.md
+++ b/doc/solutions/components/duo_workflow/duo_workflow_codestyle.md
@@ -20,14 +20,14 @@ title: Duo Workflow Use Case for Applying Coding Style
1. Obtain the invitation code from your account team.
1. Download the solution component from [the solution component webstore](https://cloud.gitlab-accelerator-marketplace.com) by using your invitation code.
-## Duo Workflow Use Case: Improve Java Application with Style Guide
+## Duo Workflow Use Case: Improve Java Application with Style Guide
-The document describes GitLab Duo Workflow Solution with prompt and context library. The purpose of the solution is to improve appliction coding based on defined style.
+The document describes GitLab Duo Workflow Solution with prompt and context library. The purpose of the solution is to improve appliction coding based on defined style.
-This solution provides a GitLab issue as the prompt and the style guide as the context, designed to automate Java style guidelines to codebases using GitLab Duo Workflow. The prompt and context library enables Duo Workflow to:
+This solution provides a GitLab issue as the prompt and the style guide as the context, designed to automate Java style guidelines to codebases using GitLab Duo Workflow. The prompt and context library enables Duo Workflow to:
-1. Access centralized style guide content stored in GitLab repository,
-1. Understand domain-specific coding standards, and
+1. Access centralized style guide content stored in GitLab repository,
+1. Understand domain-specific coding standards, and
1. Apply consistent formatting to Java code while preserving functionality.
For detailed information about GitLab Duo Workflow, review [the document here](../../../user/duo_workflow/_index.md).
@@ -57,7 +57,7 @@ To run the agentic workflow to review and apply style to your application, you n
1. **Set up the prompt and contet library** by cloning `Enterprise Code Quality Standards` project
1. **Create a GitLab issue** `Review and Apply Style` with the prompt content from the library file `.gitlab/workflows/java-style-workflow.md`
-1. **In the issue** `Review and Apply Style` configure the workflow variables as detailed in the [Configuration section](#configuration-guide)
+1. **In the issue** `Review and Apply Style` configure the workflow variables as detailed in the [Configuration section](#configuration-guide)
1. **In your VS code** with the project `Enterprise Code Quality Standards`, start the Duo Workflow with a simple [workflow prompt](#example-duo-workflow-prompt)
1. **Work with the Duo Workflow** by reviewing the proposed plan and automated tasks, if needed add further input to the workflow
1. **Review and commit** the styled code changes to your repository
@@ -77,7 +77,7 @@ This simple prompt is powerful because it instructs Duo Workflow to:
## Configuration Guide
-The prompt is defined in the `.gitlab/workflows/java-style-workflow.md` file in the solution package. This file serves as your template for creating GitLab issues that instruct the workflow agent to build out the plan to automate the style guide review on your application and apply the changes.
+The prompt is defined in the `.gitlab/workflows/java-style-workflow.md` file in the solution package. This file serves as your template for creating GitLab issues that instruct the workflow agent to build out the plan to automate the style guide review on your application and apply the changes.
In the first section of `.gitlab/workflows/java-style-workflow.md`, it defines variables you need to configure for the prompt.
@@ -121,7 +121,7 @@ TARGET_FILES=asset-management-api/src/main/java/com/royal/reserve/bank/asset/man
### Important Notes About AI-Generated Code
-**âš ï¸ Important Disclaimer**:
+**âš ï¸ Important Disclaimer**:
GitLab Workflow uses Agentic AI which is non-deterministic, meaning:
@@ -195,12 +195,12 @@ The AI assistant first creates an execution plan with specific tools:
1. Access the Java style guidelines by retrieving content from Enterprise Java Standards project using `run_read_only_git_command` on `https://gitlab.com/gl-demo-ultimate-zhenderson/sandbox/enterprise-java-standards.git` for file `coding-style/java/guidelines/java-coding-standards.md`, supported by: `run_read_only_git_command`
1. Read and analyze the current content of `AssetManagementService.java` using the `read_file` tool to understand its structure and identify areas that need style updates, supported by `read_file`
1. Search for any similar files in the project using find_files to ensure consistent style application across related service classes, supported by `find_files`
-1. Edit AssetManagementService.java using the edit_file tool to apply the style guidelines, focusing on:
+1. Edit AssetManagementService.java using the edit_file tool to apply the style guidelines, focusing on:
- - Package and import organization
- - Class and method documentation
- - Code indentation and spacing
- - Annotation placement
+ - Package and import organization
+ - Class and method documentation
+ - Code indentation and spacing
+ - Annotation placement
- Method parameter formatting, supported by `edit_file`
1. Verify all Lombok annotations (@Service, @RequiredArgsConstructor, @Slf4j) are properly formatted according to the style guide using grep_files to check annotation patterns across the codebase, supported by `grep_files`
diff --git a/doc/solutions/components/duo_workflow_codestyle.md b/doc/solutions/components/duo_workflow_codestyle.md
index d983b7631d47243ed4c5e5c75d37bfff6a59a637..1810babc4fa7436db9a23732b529385cd74a35e4 100644
--- a/doc/solutions/components/duo_workflow_codestyle.md
+++ b/doc/solutions/components/duo_workflow_codestyle.md
@@ -20,14 +20,14 @@ title: Duo Workflow Use Case for Applying Coding Style
1. Obtain the invitation code from your account team.
1. Download the solution component from [the solution component webstore](https://cloud.gitlab-accelerator-marketplace.com) by using your invitation code.
-## Duo Workflow Use Case: Improve Java Application with Style Guide
+## Duo Workflow Use Case: Improve Java Application with Style Guide
-The document describes GitLab Duo Workflow Solution with prompt and context library. The purpose of the solution is to improve appliction coding based on defined style.
+The document describes GitLab Duo Workflow Solution with prompt and context library. The purpose of the solution is to improve appliction coding based on defined style.
-This solution provides a GitLab issue as the prompt and the style guide as the context, designed to automate Java style guidelines to codebases using GitLab Duo Workflow. The prompt and context library enables Duo Workflow to:
+This solution provides a GitLab issue as the prompt and the style guide as the context, designed to automate Java style guidelines to codebases using GitLab Duo Workflow. The prompt and context library enables Duo Workflow to:
-1. Access centralized style guide content stored in GitLab repository,
-1. Understand domain-specific coding standards, and
+1. Access centralized style guide content stored in GitLab repository,
+1. Understand domain-specific coding standards, and
1. Apply consistent formatting to Java code while preserving functionality.
For detailed information about GitLab Duo Workflow, review [the document here](../../user/duo_workflow/_index.md).
@@ -57,7 +57,7 @@ To run the agentic workflow to review and apply style to your application, you n
1. **Set up the prompt and contet library** by cloning `Enterprise Code Quality Standards` project
1. **Create a GitLab issue** `Review and Apply Style` with the prompt content from the library file `.gitlab/workflows/java-style-workflow.md`
-1. **In the issue** `Review and Apply Style` configure the workflow variables as detailed in the [Configuration section](#configuration-guide)
+1. **In the issue** `Review and Apply Style` configure the workflow variables as detailed in the [Configuration section](#configuration-guide)
1. **In your VS code** with the project `Enterprise Code Quality Standards`, start the Duo Workflow with a simple [workflow prompt](#example-duo-workflow-prompt)
1. **Work with the Duo Workflow** by reviewing the proposed plan and automated tasks, if needed add further input to the workflow
1. **Review and commit** the styled code changes to your repository
@@ -77,7 +77,7 @@ This simple prompt is powerful because it instructs Duo Workflow to:
## Configuration Guide
-The prompt is defined in the `.gitlab/workflows/java-style-workflow.md` file in the solution package. This file serves as your template for creating GitLab issues that instruct the workflow agent to build out the plan to automate the style guide review on your application and apply the changes.
+The prompt is defined in the `.gitlab/workflows/java-style-workflow.md` file in the solution package. This file serves as your template for creating GitLab issues that instruct the workflow agent to build out the plan to automate the style guide review on your application and apply the changes.
In the first section of `.gitlab/workflows/java-style-workflow.md`, it defines variables you need to configure for the prompt.
@@ -121,7 +121,7 @@ TARGET_FILES=asset-management-api/src/main/java/com/royal/reserve/bank/asset/man
### Important Notes About AI-Generated Code
-**âš ï¸ Important Disclaimer**:
+**âš ï¸ Important Disclaimer**:
GitLab Workflow uses Agentic AI which is non-deterministic, meaning:
@@ -195,12 +195,12 @@ The AI assistant first creates an execution plan with specific tools:
1. Access the Java style guidelines by retrieving content from Enterprise Java Standards project using `run_read_only_git_command` on `https://gitlab.com/gl-demo-ultimate-zhenderson/sandbox/enterprise-java-standards.git` for file `coding-style/java/guidelines/java-coding-standards.md`, supported by: `run_read_only_git_command`
1. Read and analyze the current content of `AssetManagementService.java` using the `read_file` tool to understand its structure and identify areas that need style updates, supported by `read_file`
1. Search for any similar files in the project using find_files to ensure consistent style application across related service classes, supported by `find_files`
-1. Edit AssetManagementService.java using the edit_file tool to apply the style guidelines, focusing on:
+1. Edit AssetManagementService.java using the edit_file tool to apply the style guidelines, focusing on:
- - Package and import organization
- - Class and method documentation
- - Code indentation and spacing
- - Annotation placement
+ - Package and import organization
+ - Class and method documentation
+ - Code indentation and spacing
+ - Annotation placement
- Method parameter formatting, supported by `edit_file`
1. Verify all Lombok annotations (@Service, @RequiredArgsConstructor, @Slf4j) are properly formatted according to the style guide using grep_files to check annotation patterns across the codebase, supported by `grep_files`
diff --git a/doc/solutions/components/integrated_servicenow.md b/doc/solutions/components/integrated_servicenow.md
index 486ca810ba4b1fd360ccb3f33db8e56652a948d7..590f2fcb7df7b562e56879df4e35e685405974e5 100644
--- a/doc/solutions/components/integrated_servicenow.md
+++ b/doc/solutions/components/integrated_servicenow.md
@@ -19,9 +19,9 @@ With the ServiceNow DevOps Change Velocity integration, it's able to track infor
It automates the creation of change requests and automatically approve the change requests based on the policy critieria when it's integrated with GitLab CI/CD pipelines.
-This document shows you how to
+This document shows you how to
-1. Integrate ServiceNow with GitLab with Change Velocity for change management,
+1. Integrate ServiceNow with GitLab with Change Velocity for change management,
1. Create in the GitLab CI/CD pipeline automatically the change request in ServiceNow,
1. Approve the change request in ServiceNow if it requires CAB review and approval,
1. Start the production deployment based on the change request approval.
@@ -43,7 +43,7 @@ There are multiple ways to integrate GitLab with ServiceNow. The followings opti
## ServiceNow DevOps Change Velocity
-Upon installing and configuring DevOps Change Velocity from ServiceNow store, enable change control through automated change creation in the DevOps Change Workspace Directly.
+Upon installing and configuring DevOps Change Velocity from ServiceNow store, enable change control through automated change creation in the DevOps Change Workspace Directly.
### Built-in Change Request Process
@@ -53,8 +53,8 @@ The normal change process requires the change request to be approved before the
#### Setup the Pipeline and Change Request Jobs
-Use the `gitlab-ci-workflow1.yml` sample pipeline in the solution repository as a starting point.
-Check below for the steps to enable the automatic change creation and pass the change attributes through the pipeline.
+Use the `gitlab-ci-workflow1.yml` sample pipeline in the solution repository as a starting point.
+Check below for the steps to enable the automatic change creation and pass the change attributes through the pipeline.
Note: for more detailed instructions, please see [the ServiceNow documentation](https://www.servicenow.com/docs/bundle/yokohama-it-service-management/page/product/enterprise-dev-ops/task/automate-devops-change-request.html)
@@ -76,19 +76,19 @@ Below are the high-level steps:
#### Run Pipeline with Change Management
-Once the above steps are completed, the project CD pipeline can incorporate the jobs illustrated in the `gitlab-ci-workflow1.yml` sample pipeline. Below are the Change Management steps:
+Once the above steps are completed, the project CD pipeline can incorporate the jobs illustrated in the `gitlab-ci-workflow1.yml` sample pipeline. Below are the Change Management steps:
1. In ServiceNow, Change control is enabled for one of the stages in the pipeline. 
1. In GitLab, the pipeline job with the change control function runs. 
1. In ServiceNow, a change request is automatically created in ServiceNow. 
-1. In ServiceNow, approve the change request
+1. In ServiceNow, approve the change request
-1. Pipeline resumes and begins the next job for deploying to the production environment upon the approval of the change request.
+1. Pipeline resumes and begins the next job for deploying to the production environment upon the approval of the change request.
### Custom Actions with Velocity Container Image
-Use the ServiceNow custom actions via the DevOps Change Velocity Docker image to set Change Request title, description, change plan, rollback plan, and data related to artifacts to be deployed, and package registration. This allows you to customize the change request descriptions instead of passing the pipeline metadata as the change request description.
+Use the ServiceNow custom actions via the DevOps Change Velocity Docker image to set Change Request title, description, change plan, rollback plan, and data related to artifacts to be deployed, and package registration. This allows you to customize the change request descriptions instead of passing the pipeline metadata as the change request description.
#### Setup the Pipeline and Change Request Jobs
@@ -126,7 +126,7 @@ Use the `gitlab-ci-workflow2.yml` sample pipeline in this repository as an examp
#### Run Pipeline with Custom Change Management
Use the `gitlab-ci-workflow2.yml` sample pipeline as a starting point.
-Once the above steps are completed, the project CD pipeline can incorporate the jobs illustrated in the `gitlab-ci-workflow2.yml` sample pipeline. Below are the Change Management steps:
+Once the above steps are completed, the project CD pipeline can incorporate the jobs illustrated in the `gitlab-ci-workflow2.yml` sample pipeline. Below are the Change Management steps:
1. In ServiceNow, change control is enabled for one of the stages in the pipeline. 
1. In GitLab, the pipeline job with the change control function runs. 
@@ -134,5 +134,5 @@ Once the above steps are completed, the project CD pipeline can incorporate the
1. In GitLab, change request number and other information can be found in the pipeline details. The pipeline job will remain running until the change request is approved, then it will proceed to the next job. 
1. In ServiceNow, approve the change request.
-1. In GitLab, the Pipeline job resumes and begins the next job which is the deployment to the production environment upon the approval of the change request.
+1. In GitLab, the Pipeline job resumes and begins the next job which is the deployment to the production environment upon the approval of the change request.
diff --git a/doc/solutions/components/oss_license_check.md b/doc/solutions/components/oss_license_check.md
index d7aa5849521be1c8a9a3496e832d22ac2bf872b8..802267e3e8afccf774f0c7c9bd31b58728c30c2a 100644
--- a/doc/solutions/components/oss_license_check.md
+++ b/doc/solutions/components/oss_license_check.md
@@ -109,7 +109,7 @@ If you already have a security policy project but don't have dependency and/or l
1. Make sure to:
- Maintain the existing YAML structure
- Place these sections at the same level as other top-level sections
- - Set `user_approvers_ids` and/or `group_approvers_ids` and/or `role_approvers` (only one is needed)
+ - Set `user_approvers_ids` and/or `group_approvers_ids` and/or `role_approvers` (only one is needed)
- Replace `YOUR_USER_ID_HERE` or `YOUR_GROUP_ID_HERE` with appropriate user/group IDs (ensure you paste the user/group IDs e.g. 1234567 and NOT the usernames)
- Replace `YOUR_PROJECT_ID_HERE` if you'd like to exclude any projects from the policy (ensure you paste the project IDs e.g. 1234 and NOT the project names/paths)
- Set `approvals_required: 1` to the number of approvals you want to require
diff --git a/doc/solutions/components/secret_detection.md b/doc/solutions/components/secret_detection.md
index d1635e3912e4f4ffb76e6ee4defcf928751f6e41..fd8502c03a7ff6361c6666f6c76ad68bc3f89290 100644
--- a/doc/solutions/components/secret_detection.md
+++ b/doc/solutions/components/secret_detection.md
@@ -23,7 +23,7 @@ title: Secret Detection
- GitLab Ultimate tier
- Administrator access to your GitLab instance or group
-- [Secret Detection](../../user/application_security/secret_detection/_index.md) enabled for your projects
+- [Secret Detection](../../user/application_security/secret_detection/_index.md) enabled for your projects
## Configure Secret Detection Custom Rules
@@ -91,7 +91,7 @@ To set the access and authentication, follow these steps:
This guide covers the steps to configure the policy to run secret detection for all projects using centralized custom ruleset.
-### Configure Secret Detection Policy
+### Configure Secret Detection Policy
To run secret detection automatically in the pipeline as the enforced global policy, set up the policy at the highest level, in this case the top group level. Follow the steps outlined below to create the new secret detection policy.
@@ -102,11 +102,11 @@ To run secret detection automatically in the pipeline as the enforced global pol
1. Set the **Policy scope** by selecting either "All projects in this group" (and optionally set exceptions) or "Specific projects" (and select the projects from the dropdown).
1. Under the **Actions** section, select "Dependency scanning" instead of "Secret Detection" (default).
1. Under the **Conditions** section, you can optionally change "Triggers:" to "Schedules:" if you want to run the scan on a schedule instead of at every commit.
-1. Setup access to the custom ruleset: add CI variables with the value of the bot user, group variable and the URL of the custom ruleset project.
+1. Setup access to the custom ruleset: add CI variables with the value of the bot user, group variable and the URL of the custom ruleset project.
- Since the custom ruleset is hosted in a different project and considered as the remote ruleset, the `SECRET_DETECTION_RULESET_GIT_REFERENCE` must be used.
+ Since the custom ruleset is hosted in a different project and considered as the remote ruleset, the `SECRET_DETECTION_RULESET_GIT_REFERENCE` must be used.
- ```yaml
+ ```yaml
variables:
SECRET_DETECTION_RULESET_GIT_REFERENCE: "group_[group_id]_bot_[random_number]:$SECRET_DETECTION_GROUP_TOKEN@[custom ruleset project URL]"
SECRET_DETECTION_HISTORIC_SCAN: "true"
@@ -121,7 +121,7 @@ For detailed information about this CI variable, see [this document for details]
Upon creating the policy, for reference, here is the complete policy configuration:
-```yaml
+```yaml
---
scan_execution_policy:
- name: Scan Execution for Secret Detection with Custom Rules
diff --git a/doc/solutions/components/securitykpi.md b/doc/solutions/components/securitykpi.md
index 40d578c787904ff76963befa643bd7e4d5ed3266..5889d964a631f4754a2460cc8bc6566223730bd6 100644
--- a/doc/solutions/components/securitykpi.md
+++ b/doc/solutions/components/securitykpi.md
@@ -12,7 +12,7 @@ title: Security Metrics and KPIs
{{< /details >}}
-The document describes the installation, configuration and user guide of GitLab Security Metrics and KPIs Solution Component. This security solution component provides metrics and KPIs that can be viewed by business units, time range, vulnerability severity and security types. It can provide snapshot of the seucrity posture on the monthly and quarterly basis with pdf documents. The dashboard and visualization of data are displayed as Dashboard in Splunk.
+The document describes the installation, configuration and user guide of GitLab Security Metrics and KPIs Solution Component. This security solution component provides metrics and KPIs that can be viewed by business units, time range, vulnerability severity and security types. It can provide snapshot of the seucrity posture on the monthly and quarterly basis with pdf documents. The dashboard and visualization of data are displayed as Dashboard in Splunk.
diff --git a/doc/topics/autodevops/_index.md b/doc/topics/autodevops/_index.md
index e132b8b11cf208910d0b1fd48de8cd86d0c4cfe7..0922a60fd82c1c39f946970249ed8411863e59b1 100644
--- a/doc/topics/autodevops/_index.md
+++ b/doc/topics/autodevops/_index.md
@@ -12,9 +12,9 @@ title: Auto DevOps
{{< /details >}}
-Auto DevOps turns your code into production-ready applications without the usual configuration overhead.
-The entire DevOps lifecycle is pre-configured using industry best practices. Start with the defaults
-to ship quickly, then customize when you need more control. No complex configuration files or deep
+Auto DevOps turns your code into production-ready applications without the usual configuration overhead.
+The entire DevOps lifecycle is pre-configured using industry best practices. Start with the defaults
+to ship quickly, then customize when you need more control. No complex configuration files or deep
DevOps expertise is required.
With Auto DevOps you get:
diff --git a/doc/tutorials/build_application.md b/doc/tutorials/build_application.md
index 8d552fe6464a733bf2bc07fe1e0daf14c1a08521..7392107c10672ea468707b2902f1a3b586b1db44 100644
--- a/doc/tutorials/build_application.md
+++ b/doc/tutorials/build_application.md
@@ -24,7 +24,7 @@ Use CI/CD pipelines to automatically build, test, and deploy your code.
| [Use Auto DevOps to deploy an application](../topics/autodevops/cloud_deployments/auto_devops_with_gke.md) | Deploy an application to Google Kubernetes Engine (GKE). | |
| [Using Buildah in a rootless container with GitLab Runner Operator on OpenShift](../ci/docker/buildah_rootless_tutorial.md) | Learn how to set up GitLab Runner Operator on OpenShift to build Docker images with Buildah in a rootless container | |
| [Automatically build and publish packages with CI/CD](../user/packages/pypi_repository/auto_publish_tutorial.md) | Learn how to automatically build, test, and publish a PyPI package to the package registry. | |
-| [Structure the package registry for enterprise scale](../user/packages/package_registry/enterprise_structure_tutorial.md) | Set up your organization to upload, manage, and consume packages at scale. | |
+| [Structure the package registry for enterprise scale](../user/packages/package_registry/enterprise_structure_tutorial.md) | Set up your organization to upload, manage, and consume packages at scale. | |
| [Set up CI/CD steps](setup_steps/_index.md) | Learn how to set up the steps component and configure a CI/CD pipeline to use the step in a job. | |
| [Build and sign Python packages with GitLab CI/CD](../user/packages/package_registry/pypi_cosign_tutorial.md) | Learn how to build a secure pipeline for Python packages using GitLab CI/CD and Sigstore Cosign. | |
diff --git a/doc/user/clusters/agent/enterprise_considerations.md b/doc/user/clusters/agent/enterprise_considerations.md
index 42cbebd79debe18bc1c430a3e47cafce42b7683c..95959de9fa63e0b670c27e9a717ff88b304c3cee 100644
--- a/doc/user/clusters/agent/enterprise_considerations.md
+++ b/doc/user/clusters/agent/enterprise_considerations.md
@@ -21,7 +21,7 @@ For a description of the advantages of GitOps, see [the OpenGitOps initiative](h
- For scaling, Flux supports [vertical](https://fluxcd.io/flux/installation/configuration/vertical-scaling/) and [horizontal sharding](https://fluxcd.io/flux/installation/configuration/sharding/).
- For Flux-specific guidance, see the [Flux guides](https://fluxcd.io/flux/guides/) in the Flux documentation.
- To simplify maintenance, you should run a single GitLab agent for Kubernetes installation per cluster. You can share the agent connection with impersonation features across the GitLab domain.
-- Consider using the Flux `OCIRepository` for storing and retrieving manifests.
+- Consider using the Flux `OCIRepository` for storing and retrieving manifests.
You can use GitLab pipelines to build and push the OCI images to the container registry.
- To shorten the feedback loop, trigger an immediate GitOps reconciliation from the related GitLab pipeline.
- You should sign generated OCI images, and deploy only images signed and verified by Flux.
@@ -29,7 +29,7 @@ For a description of the advantages of GitOps, see [the OpenGitOps initiative](h
### OCI containers
-When you use OCI containers instead of Git repositories, the source of truth for the manifests is still the Git repository.
+When you use OCI containers instead of Git repositories, the source of truth for the manifests is still the Git repository.
You can think of the OCI container as a caching layer between the Git repository and the cluster.
There are several benefits to using OCI containers:
@@ -37,7 +37,7 @@ There are several benefits to using OCI containers:
- OCI was designed for scalability. Although the GitLab Git repositories scale well, they were not designed for this use case.
- A single Git repository can be the source of several OCI containers, each packaging a small set of manifests.
This way, if you need to retrieve a set of manifests, you don't need to download the whole Git repository.
-- OCI repositories can follow a well-known versioning scheme, and Flux can be configured to auto-update following that scheme.
+- OCI repositories can follow a well-known versioning scheme, and Flux can be configured to auto-update following that scheme.
For example, if you use semantic versioning, Flux can deploy all the minor and patch changes automatically, while major versions require a manual update.
- OCI images can be signed, and the signature can be verified by Flux.
- OCI repositories can be scanned by the container registry, even after the image is built.
diff --git a/doc/user/enterprise_user/_index.md b/doc/user/enterprise_user/_index.md
index 317a1284064a5026c89a0c873ddf07517047be31..5db71e6643d6a8021f1a6047a57ef5fd3a023c8a 100644
--- a/doc/user/enterprise_user/_index.md
+++ b/doc/user/enterprise_user/_index.md
@@ -51,7 +51,7 @@ If the organization moves its verified domains to another paid group, its enterp
### Identifying unclaimed users
-If a user is not automatically claimed as an Enterprise User, their existing access will not be revoked.
+If a user is not automatically claimed as an Enterprise User, their existing access will not be revoked.
A group with domain verification enabled can have both claimed and unclaimed users as members.
The only difference between a member claimed as an Enterprise User and one that isn't is that a Group Owner cannot [manage unclaimed users](#manage-enterprise-users-in-a-namespace).
diff --git a/doc/user/infrastructure/iac/terraform_state.md b/doc/user/infrastructure/iac/terraform_state.md
index 2cf1aa1050f7f26be623acf5be9ab2b1c5ac9486..5f174426e862efd105ab90e110727e9158eb19d0 100644
--- a/doc/user/infrastructure/iac/terraform_state.md
+++ b/doc/user/infrastructure/iac/terraform_state.md
@@ -19,9 +19,9 @@ title: GitLab-managed Terraform/OpenTofu state
{{< /history >}}
-Managing infrastructure state files across teams requires both security and reliability. GitLab-managed
+Managing infrastructure state files across teams requires both security and reliability. GitLab-managed
OpenTofu state eliminates the typical challenges of state management.
-With minimal configuration, your OpenTofu states become a natural extension of your GitLab project.
+With minimal configuration, your OpenTofu states become a natural extension of your GitLab project.
This integration keeps your infrastructure definitions, code, and state all in one secure location.
With GitLab-managed OpenTofu state, you:
diff --git a/doc/user/packages/maven_repository/_index.md b/doc/user/packages/maven_repository/_index.md
index 9579a4a2b03125ecae981d5d17cb12d7ffdc7f07..6c13ac35def69515f9ef156109f8f36eac7f5176 100644
--- a/doc/user/packages/maven_repository/_index.md
+++ b/doc/user/packages/maven_repository/_index.md
@@ -523,8 +523,8 @@ correct location:
{{< alert type="note" >}}
-If you protect a Maven package before publishing it, the package will be rejected with a `403 Forbidden` error and an `Authorization failed` error message.
-Ensure the Maven package is not protected when publishing.
+If you protect a Maven package before publishing it, the package will be rejected with a `403 Forbidden` error and an `Authorization failed` error message.
+Ensure the Maven package is not protected when publishing.
For more information about package protection rules, see [how to protect a package](../../../user/packages/package_registry/package_protection_rules.md#protect-a-package).
{{< /alert >}}
diff --git a/doc/user/packages/yarn_repository/_index.md b/doc/user/packages/yarn_repository/_index.md
index aae5862809752b36ce46c333d4a27cbe0736cf2b..11a3e59644769f5d529f91beef2fe059fe1acfb5 100644
--- a/doc/user/packages/yarn_repository/_index.md
+++ b/doc/user/packages/yarn_repository/_index.md
@@ -129,7 +129,7 @@ in your package project root directory where `package.json` is found:
For example, to trigger only on any tag push:
In Yarn 1:
-
+
```yaml
image: node:lts
diff --git a/doc/user/profile/user_passwords.md b/doc/user/profile/user_passwords.md
index acfc747773f8bdb37b49d2a91830cfd43b57a392..af02279ac8aba48087a114c746cc3f35646d28ec 100644
--- a/doc/user/profile/user_passwords.md
+++ b/doc/user/profile/user_passwords.md
@@ -62,7 +62,7 @@ In both situations, you are redirected to the sign-in page and see the following
{{< alert type="note" >}}
Your account can have more than one verified email address, and any email address
-associated with your account can be verified. However, only the primary email address
+associated with your account can be verified. However, only the primary email address
can be used to sign in once the password is reset.
{{< /alert >}}
diff --git a/doc/user/project/deploy_tokens/_index.md b/doc/user/project/deploy_tokens/_index.md
index b2a48fbaf10c2bd52c0ef6a7666f195464407a36..ea037deb8e83b45676b467068f09152b54ef2e38 100644
--- a/doc/user/project/deploy_tokens/_index.md
+++ b/doc/user/project/deploy_tokens/_index.md
@@ -12,7 +12,7 @@ title: Deploy tokens
{{< /details >}}
-Deploy tokens provide secure access to GitLab resources without tying permissions to individual user accounts. Use them with Git operations, container registries, and package registries, giving your deployment
+Deploy tokens provide secure access to GitLab resources without tying permissions to individual user accounts. Use them with Git operations, container registries, and package registries, giving your deployment
automation access to exactly what it needs.
With deploy tokens, you have:
diff --git a/doc/user/project/releases/_index.md b/doc/user/project/releases/_index.md
index 287f646d8f1a5320931d5b1527c76b61a2a694ed..85e4585c1a6f14b48a3fd398cda1dee30b36ee94 100644
--- a/doc/user/project/releases/_index.md
+++ b/doc/user/project/releases/_index.md
@@ -12,7 +12,7 @@ title: Releases
{{< /details >}}
-Create a release to package your project at critical milestones. Releases combine code, binaries, documentation,
+Create a release to package your project at critical milestones. Releases combine code, binaries, documentation,
and release notes into a complete snapshot of your project.
When a release is created, GitLab automatically tags your code, archives a snapshot, and generates
audit-ready evidence. This creates a permanent record that's perfect for compliance requirements and
diff --git a/doc/user/project/settings/migrate_projects.md b/doc/user/project/settings/migrate_projects.md
index a4746b40bebfa83a675ae94db3e9688da6f44c2c..3f36076aba47a1a530d69fea05b700f587b045aa 100644
--- a/doc/user/project/settings/migrate_projects.md
+++ b/doc/user/project/settings/migrate_projects.md
@@ -34,8 +34,8 @@ A project transfer includes:
- Membership invitations
{{< alert type="note" >}}
-
- Members with [inherited membership](../members/_index.md#membership-types)
+
+ Members with [inherited membership](../members/_index.md#membership-types)
in the project lose access unless they are also members of the target group.
The project inherits new member permissions from the group you transfer it to.