Add latest changes from gitlab-org/gitlab@master

Author: GitLab Bot

.gitlab/ci/docs.gitlab-ci.yml

@@ -76,7 +76,7 @@ review-docs-hugo-cleanup:
 
 .docs-markdown-lint-image:
   # When updating the image version here, update it in /scripts/lint-doc.sh too.
-  image: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-docs/lint-markdown:alpine-3.20-vale-3.9.3-markdownlint2-0.17.1-lychee-0.18.0
+  image: ${REGISTRY_HOST}/${REGISTRY_GROUP}/technical-writing/docs-gitlab-com/lint-markdown:alpine-3.21-vale-3.9.3-markdownlint2-0.17.1-lychee-0.18.0
 
 docs-lint markdown:
   extends:
@@ -111,6 +111,28 @@ docs code_quality:
     expire_in: 2 weeks
     when: always
 
+docs hugo_build:
+  image: hugomods/hugo:exts-0.142.0
+  extends:
+    - .default-retry
+    - .docs:rules:docs-lint
+  stage: lint
+  needs: []
+  dependencies: []
+  before_script:
+    - apk add --no-cache git make nodejs npm bash
+    - git clone --depth 1 --filter=tree:0 https://gitlab.com/gitlab-org/technical-writing/docs-gitlab-com.git
+    - cd docs-gitlab-com
+    - make add-latest-icons
+    # Copy the current project's docs to the appropriate location in the docs website
+    - cp -r ../doc/* content/
+  script:
+    # Test that Hugo will build
+    - hugo --gc --printPathWarnings --panicOnWarning
+    # Test for invalid index pages
+    # See https://gitlab.com/gitlab-org/technical-writing/docs-gitlab-com/-/blob/main/scripts/check-index-filenames.sh
+    - make check-index-pages SEARCH_DIR="../doc"
+
 docs-lint links:
   extends:
     - .docs:rules:docs-lint

.gitlab/issue_templates/AI Project Proposal.md

@@ -10,7 +10,7 @@ TITLE FORMAT
 The title should be something that is easily understood that quickly communicates the intent of the project allowing team members to easily understand and recognize the expected work that will be done. A proposal title should combine the beneficiary of the feature/UI, the job it will allow them to accomplish (see https://about.gitlab.com/handbook/product/ux/jobs-to-be-done/#how-to-write-a-jtbd), and their expected outcome when the work is delivered. Well-defined statements are concise without sacrificing the substance of the proposal so that anyone can understand it at a glance. (e.g. {Reduce the effort} {for security teams} {when prioritizing business-critical risks in their assets}).
 -->
 
-# [Experiment](https://docs.gitlab.com/ee/policy/alpha-beta-support.html#experiment)
+# [Experiment](https://docs.gitlab.com/policy/development_stages_support/#experiment)
 _This section should be completed prior to beginning work on the Experiment._
 
 ## Problem to be solved
@@ -38,9 +38,9 @@ _How will you measure whether this experiment is a success?_
 | [Problem validation](https://about.gitlab.com/handbook/product/ai/ux-maturity/#validation-problem-validation)<br>How well do we understand the problem? | [Mix of evidence and assumptions](https://about.gitlab.com/handbook/product/ai/ux-maturity/#questions-to-ask) | <!-- Acceptable answers: Yes, Somewhat or Somewhat, Somewhat --> |
 | [Solution validation](https://about.gitlab.com/handbook/product/ai/ux-maturity/#validation-solution-validation)<br>How usable is the solution? | [Usability testing](https://about.gitlab.com/handbook/product/ux/ux-scorecards/#option-b-perform-a-formative-evaluation), Grade C | <!-- Acceptable: >80% and grade C --> |
 | [Improve](https://about.gitlab.com/handbook/product/ai/ux-maturity/#build-improve)<br>How successful is the solution? | Quality goals set by the team are reached. | <!-- Acceptable answers: :white_check_mark: Reached all quality goals for this phase. --> |
-| [Design standards](https://about.gitlab.com/handbook/product/ai/ux-maturity/#design-standards) adherence<br>How compliant is the solution with our design standards? |  Should adhere to ([Pajamas](https://design.gitlab.com/), [checklist](https://docs.gitlab.com/ee/development/contributing/design.html#checklist)) | <!-- Acceptable: Mostly adheres to design standards --> |
+| [Design standards](https://about.gitlab.com/handbook/product/ai/ux-maturity/#design-standards) adherence<br>How compliant is the solution with our design standards? |  Should adhere to ([Pajamas](https://design.gitlab.com/), [checklist](https://docs.gitlab.com/development/contributing/design/#checklist)) | <!-- Acceptable: Mostly adheres to design standards --> |
 
-# [Beta](https://docs.gitlab.com/ee/policy/alpha-beta-support.html#beta)
+# [Beta](https://docs.gitlab.com/policy/development_stages_support/#beta)
 _This section should be completed prior to beginning work on the Beta experience._
 <!-- DO NOT REMOVE THIS SECTION
 Although the initial focus is on the “Experiment” section, do not remove this “Beta” section. It's important that we link Experiment to Beta release. Fill this section in as you progress.
@@ -86,9 +86,9 @@ _How will you measure whether this Beta is a success?_
 | [Problem validation](https://about.gitlab.com/handbook/product/ai/ux-maturity/#validation-problem-validation)<br>How well do we understand the problem? | [Mix of evidence and assumptions](https://about.gitlab.com/handbook/product/ai/ux-maturity/#questions-to-ask) | <!-- Acceptable answers: Yes, Yes --> |
 | [Solution validation](https://about.gitlab.com/handbook/product/ai/ux-maturity/#validation-solution-validation)<br>How usable is the solution? | [Usability testing](https://about.gitlab.com/handbook/product/ux/ux-scorecards/#option-b-perform-a-formative-evaluation) and [Heuristic evaluation](https://about.gitlab.com/handbook/product/ux/ux-scorecards/#option-a-conduct-a-heuristic-evaluation), Avg. task pass rate >80%, Grade B | <!-- Acceptable: >80% and grade B --> |
 | [Improve](https://about.gitlab.com/handbook/product/ai/ux-maturity/#build-improve)<br>How successful is the solution? | Quality goals set by the team are reached. | <!-- Acceptable answers: :white_check_mark: Reached all quality goals for this phase. -->  |
-| [Design standards](https://about.gitlab.com/handbook/product/ai/ux-maturity/#design-standards) adherence<br>How compliant is the solution with our design standards? |  Should adhere to ([Pajamas](https://design.gitlab.com/), [checklist](https://docs.gitlab.com/ee/development/contributing/design.html#checklist)) | <!-- Acceptable: Completely adheres to design standards --> |
+| [Design standards](https://about.gitlab.com/handbook/product/ai/ux-maturity/#design-standards) adherence<br>How compliant is the solution with our design standards? |  Should adhere to ([Pajamas](https://design.gitlab.com/), [checklist](https://docs.gitlab.com/development/contributing/design/#checklist)) | <!-- Acceptable: Completely adheres to design standards --> |
 
-# [Generally Available](https://docs.gitlab.com/ee/policy/alpha-beta-support.html#generally-available-ga)
+# [Generally Available](https://docs.gitlab.com/policy/development_stages_support/#generally-available)
 <!-- DO NOT REMOVE THIS SECTION
 Although the initial focus is on the “Experiment” section, do not remove this “Generally Available” section. It's important that we link Beta to GA release. Fill this section in as you progress.
 -->
@@ -150,7 +150,7 @@ _What tasks or actions should the user be capable of performing with this featur
 - [ ] Add all related feature issues to the Linked items section
 - [ ] Add all relevant solution validation issues to the Linked items section that shows this proposal will solve the customer problem, or details explaining why it's not possible to provide that validation.
 - [ ] Add relevant designs to the Design Management area of the issue.
-- [ ] You have adhered to our [Definition of Done](https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html#definition-of-done) standards
+- [ ] You have adhered to our [Definition of Done](https://docs.gitlab.com/development/contributing/merge_request_workflow/#definition-of-done) standards
 - [ ] Completed the necessary steps to move from Beta to GA
 
 </details>
@@ -167,15 +167,15 @@ _What tasks or actions should the user be capable of performing with this featur
     - [ ] Requirements have been defined
 - [ ] Add all relevant solution validation issues to the Linked items section that shows this proposal will solve the customer problem, or details explaining why it's not possible to provide that validation.
 - [ ] Add relevant designs to the Design Management area of the issue.
-- [ ] You have adhered to our [Definition of Done](https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html#definition-of-done) standards
+- [ ] You have adhered to our [Definition of Done](https://docs.gitlab.com/development/contributing/merge_request_workflow/#definition-of-done) standards
 - [ ] Ensure this issue has the ~wg-ai-integration label to ensure visibility to various teams working on this
 
 </details>
 
 <details> <summary> Technical needs </summary>
 
 - [ ] Please consider the operational aspects of the feature you are creating. A list of things to think about is in: https://gitlab.com/gitlab-org/gitlab/-/issues/403859. We will be improving this process in the future: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117637#note_1353253349. 
-- [ ] @ mention your [AppSec Stable Counterpart](https://about.gitlab.com/handbook/product/categories/) and read the [AI secure coding guidelines](https://docs.gitlab.com/ee/development/secure_coding_guidelines.html#artificial-intelligence-ai-features)
+- [ ] @ mention your [AppSec Stable Counterpart](https://about.gitlab.com/handbook/product/categories/) and read the [AI secure coding guidelines](https://docs.gitlab.com/development/secure_coding_guidelines/#artificial-intelligence-ai-features)
 
 1. Work estimate and skills needs to build an ML viable feature: To build any ML feature depending on the work, there are many personas that contribute including Data Scientist, NLP engineer, ML Engineer, MLOps Engineer, ML Infra engineers, Fullstack engineer to integrate the ML Services with Gitlab. Post-prototype we would assess the skills needed to build a production-grade ML feature for the prototype.
 2. Data Limitation: We would like to upfront validate if we have viable data for the feature including whether we can use the DataOps pipeline of ModelOps or create a custom one. We would want to understand the training data, test data, and feedback data to dial up the accuracy and the limitations of the data.

.gitlab/issue_templates/Audit Event Proposal.md

@@ -1,5 +1,5 @@
-<!-- Audit event documentation: See https://docs.gitlab.com/ee/administration/audit_events.html -->
-<!-- Streaming audit event documentation: See https://docs.gitlab.com/ee/administration/audit_event_streaming.html -->
+<!-- Audit event documentation: See https://docs.gitlab.com/administration/audit_events/ -->
+<!-- Streaming audit event documentation: See https://docs.gitlab.com/administration/audit_event_streaming/ -->
 
 ## Audit need
 

.gitlab/issue_templates/Broken Master - Flaky.md

@@ -16,7 +16,7 @@ Please read the below documentations for a workflow of triaging and resolving br
 
 <!-- If the pipeline failure is reproducible, provide steps to recreate the issue locally. Please use an ordered list. -->
 
-Please refer to [Flaky tests documentation](https://docs.gitlab.com/ee/development/testing_guide/flaky_tests.html) to
+Please refer to [Flaky tests documentation](https://docs.gitlab.com/development/testing_guide/flaky_tests/) to
 learn more about how to reproduce them.
 
 ### Proposed Resolution

.gitlab/issue_templates/Deprecations.md

@@ -149,10 +149,10 @@ External Communication Plan
 - [ ] Ensure you have approvals from legal and corp comms for any communication being sent directly to customers.
 - [ ] As soon as possible, but no later than the third milestone preceding the major release, ensure that the following are complete (for example, given the following release schedule: `17.8, 17.9, 17.10, 17.11, 18.0` – `17.9` is the third milestone preceding the major release). 
     - [ ] A [deprecation announcement entry](https://about.gitlab.com/handbook/marketing/blog/release-posts/#creating-the-announcement) has been created so the deprecation will appear in release posts and on the [general deprecation page](https://docs.gitlab.com/ee/update/deprecations). _Add link to the relevant merge request._
-    - [ ] Documentation has been updated to mark the feature as [deprecated](https://docs.gitlab.com/ee/development/documentation/versions.html#deprecations-and-removals).  _Add link to the relevant merge request._
+    - [ ] Documentation has been updated to mark the feature as [deprecated](https://docs.gitlab.com/development/documentation/versions/#deprecations-and-removals).  _Add link to the relevant merge request._
 - [ ] On the major milestone:
     - [ ] The deprecated item has been removed.  _Add link to the relevant merge request._
-    - [ ] If the removal of the deprecated item is a [breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change), the merge request is labeled ~"breaking change".
+    - [ ] If the removal of the deprecated item is a [breaking change](https://docs.gitlab.com/update/terminology/#breaking-change), the merge request is labeled ~"breaking change".
     - [ ] Document the migration plan for users, clearly outlining the actions they need to take to mitigate the impact of the breaking change.
        - [ ] [Add link](here)
 
@@ -209,7 +209,7 @@ Keep in mind that approval check boxes and deprecations notices alone are not su
 /label ~"awaiting-pm-approval" ~"awaiting-em-approval" ~"awaiting-senior-eng-approval" ~"awaiting-senior-product-approval"
 
 - [ ] This issue is labeled ~deprecation, and with the relevant `~devops::`, `~group::`, and `~Category:` labels.
-- [ ] This issue is labeled  ~"breaking change" if the removal of the deprecated item will be a [breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change).
+- [ ] This issue is labeled  ~"breaking change" if the removal of the deprecated item will be a [breaking change](https://docs.gitlab.com/update/terminology/#breaking-change).
 
 
 <!-- Label reminders - you should have one of each of the following labels.
@@ -226,9 +226,9 @@ Use the following resources to find the appropriate labels:
 - [Deprecations, removals, and breaking changes](https://handbook.gitlab.com/handbook/marketing/blog/release-posts/#deprecations-removals-and-breaking-changes)
 - [Deprecation guidelines](https://docs.gitlab.com/ee/development/deprecation_guidelines/)
 - [Deprecations and removals doc styleguide](https://docs.gitlab.com/ee/development/documentation/styleguide/deprecations_and_removals)
-- [REST API Deprecations](https://docs.gitlab.com/ee/development/documentation/restful_api_styleguide.html#deprecations) and [REST API breaking changes](https://docs.gitlab.com/ee/development/api_styleguide.html#breaking-changes).
-- [GraphQL Deprecations](https://docs.gitlab.com/ee/development/api_graphql_styleguide.html#deprecating-schema-items) and [GraphQL API breaking changes](https://docs.gitlab.com/ee/development/api_graphql_styleguide.html#breaking-changes).
-- [GitLab release and maintenance policy](https://docs.gitlab.com/ee/policy/maintenance.html)
+- [REST API Deprecations](https://docs.gitlab.com/development/documentation/restful_api_styleguide/#deprecations) and [REST API breaking changes](https://docs.gitlab.com/development/api_styleguide/#breaking-changes).
+- [GraphQL Deprecations](https://docs.gitlab.com/development/api_graphql_styleguide/#deprecating-schema-items) and [GraphQL API breaking changes](https://docs.gitlab.com/development/api_graphql_styleguide/#breaking-changes).
+- [GitLab release and maintenance policy](https://docs.gitlab.com/policy/maintenance/)
 - Videos 📺
    - [How to deprecate and remove features in GitLab releases](https://youtu.be/9gy7tg94j7s)
    - [Review of GitLab deprecations and removals policy & Runner team deprecations and removals process](https://youtu.be/ehT1xBajCRI)

.gitlab/issue_templates/Doc_cleanup.md

@@ -1,7 +1,7 @@
 <!--
 * Use this template for documentation issues identified
-* by [Vale](https://docs.gitlab.com/ee/development/documentation/testing/vale.html)
-* or [markdownlint](https://docs.gitlab.com/ee/development/documentation/testing/markdownlint.html).
+* by [Vale](https://docs.gitlab.com/development/documentation/testing/vale/)
+* or [markdownlint](https://docs.gitlab.com/development/documentation/testing/markdownlint/).
 * This template is meant to describe work for first-time contributors or
 * for work during Hackathons.
 *
@@ -20,14 +20,14 @@ Do you want to work on this issue?
 
 ## To resolve the issue
 
-[Follow these instructions to create a merge request](https://docs.gitlab.com/ee/development/documentation/workflow.html#how-to-update-the-docs).
+[Follow these instructions to create a merge request](https://docs.gitlab.com/development/documentation/workflow/#how-to-update-the-docs).
 
 - Don't submit your merge request until after the Hackathon has started.
 - Try to address the issue in a single merge request.
 - Try to stick to the scope of the issue. If you see other improvements that can be made in the file, open a separate merge request.
 - When you create the merge request, select the **Documentation** merge request description template.
 - In the merge request's description, add a link to this issue.
-- Follow the [commit message guidelines](https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html#commit-messages-guidelines).
+- Follow the [commit message guidelines](https://docs.gitlab.com/development/contributing/merge_request_workflow/#commit-messages-guidelines).
   Use three to five words for your commit message, start with message with a capital letter, and do **not** end it in a period.
   Other commit messages can cause the pipeline to fail.