Merge branch 'lealasmith-hugo-migration-update-links-runner' into 'main'

Docs: Hugo migration - Updating gitlab-runner doc links

See merge request https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/5448

Merged-by: Marcel Amirault <[email protected]>
Approved-by: Georgi N. Georgiev <[email protected]>
Approved-by: Marcel Amirault <[email protected]>
Reviewed-by: Marcel Amirault <[email protected]>
Co-authored-by: Leala Smith <[email protected]>

Author: Ravlen

.gitlab/CODEOWNERS

@@ -1,6 +1,6 @@
 # When adding a group as a code owner, make sure to invite the group to the
 # project here: https://gitlab.com/gitlab-org/gitlab-runner/-/project_members
-# As described in https://docs.gitlab.com/ee/user/project/code_owners.html
+# As described in https://docs.gitlab.com/user/project/codeowners/
 
 * @gitlab-com/runner-maintainers
 .editorconfig   @gitlab-com/runner-group @gitlab-com/runner-maintainers

.gitlab/ci/coverage.gitlab-ci.yml

@@ -35,7 +35,7 @@ test coverage report:
 # Disable this for now since
 # https://gitlab.com/gitlab-org/gitlab/-/issues/365885 block us from upgrading
 # to go 1.18.x. Re-enable this when the above ticket is fixed.
-#code navigation: # See https://docs.gitlab.com/ee/user/project/code_intelligence.html#configuration
+#code navigation: # See https://docs.gitlab.com/user/project/code_intelligence/#configuration
   #extends:
   #- .coverage_job
   #allow_failure: true # recommended

.gitlab/issue_templates/Documentation.md

@@ -6,7 +6,7 @@
      https://gitlab.com/gitlab-org/gitlab-docs/issues/
 
 * For information about documentation content and process, see
-     https://docs.gitlab.com/ee/development/documentation/ -->
+     https://docs.gitlab.com/development/documentation/ -->
 
 ### Problem to solve
 

.gitlab/issue_templates/Security developer workflow.md

@@ -59,8 +59,8 @@ After your merge request has been approved according to our [approval guidelines
 
 [security process for developers]: https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md
 [security Release merge request template]: https://gitlab.com/gitlab-org/security/gitlab-runner/blob/main/.gitlab/merge_request_templates/Security%20Release.md
-[approval guidelines]: https://docs.gitlab.com/ee/development/code_review.html#approval-guidelines
-[issue as related]: https://docs.gitlab.com/ee/user/project/issues/related_issues.html#adding-a-related-issue
+[approval guidelines]: https://docs.gitlab.com/development/code_review/#approval-guidelines
+[issue as related]: https://docs.gitlab.com/user/project/issues/related_issues/#add-a-linked-issue
 
 /label ~security ~"Category:Runner" ~"devops::verify" ~"group::runner"
 

.gitlab/issue_templates/trainee-backend-maintainer.md

@@ -5,7 +5,7 @@
 ## Basic setup
 
 1. [ ] Read the [Becoming a maintainer for one of Runner team projects](https://about.gitlab.com/handbook/engineering/development/ci-cd/verify/runner/#becoming-a-maintainer-for-one-of-our-projects).
-1. [ ] Read the [code review page in the handbook](https://about.gitlab.com/handbook/engineering/workflow/code-review/) and the [code review guidelines](https://docs.gitlab.com/ee/development/code_review.html).
+1. [ ] Read the [code review page in the handbook](https://about.gitlab.com/handbook/engineering/workflow/code-review/) and the [code review guidelines](https://docs.gitlab.com/development/code_review/).
 1. [ ] Understand [how to become a maintainer](https://about.gitlab.com/handbook/engineering/workflow/code-review/#how-to-become-a-maintainer).
 1. [ ] Add yourself as a [trainee maintainer](https://about.gitlab.com/handbook/engineering/workflow/code-review/#trainee-maintainer) on the [team page](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/team.yml).
 1. [ ] Ask your manager to set up a check in on this issue every six weeks or so.

.gitlab/merge_request_templates/Documentation.md

@@ -10,12 +10,12 @@
 
 - [ ] Optional. Consider taking [the GitLab Technical Writing Fundamentals course](https://university.gitlab.com/courses/gitlab-technical-writing-fundamentals).
 - [ ] Follow the:
-  - [Documentation process](https://docs.gitlab.com/ee/development/documentation/workflow.html).
-  - [Documentation guidelines](https://docs.gitlab.com/ee/development/documentation/).
-  - [Style Guide](https://docs.gitlab.com/ee/development/documentation/styleguide/).
-- [ ] If you're adding or changing the main heading of the page (H1), ensure that the [product tier badge](https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#product-tier-badges) is added.
-- [ ] If you are a GitLab team member, [request a review](https://docs.gitlab.com/ee/development/code_review.html#dogfooding-the-reviewers-feature) based on:
-  - The documentation page's [metadata](https://docs.gitlab.com/ee/development/documentation/#metadata).
+  - [Documentation process](https://docs.gitlab.com/development/documentation/workflow/).
+  - [Documentation guidelines](https://docs.gitlab.com/development/documentation/).
+  - [Style Guide](https://docs.gitlab.com/development/documentation/styleguide/).
+- [ ] If you're adding or changing the main heading of the page (H1), ensure that the [product availability details](https://docs.gitlab.com/development/documentation/styleguide/availability_details/) are added.
+- [ ] If you are a GitLab team member, [request a review](https://docs.gitlab.com/development/code_review/#dogfooding-the-reviewers-feature) based on:
+  - The documentation page's [metadata](https://docs.gitlab.com/development/documentation/metadata/).
   - The [associated Technical Writer](https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments).
 
 If you are a GitLab team member and only adding documentation, do not add any of the following labels:
@@ -29,7 +29,7 @@ These labels cause the MR to be added to code verification QA issues.
 
 ## Reviewer's checklist
 
-Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on [Documentation Guidelines](https://docs.gitlab.com/ee/development/documentation/) and the [Style Guide](https://docs.gitlab.com/ee/development/documentation/styleguide/).
+Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on [Documentation Guidelines](https://docs.gitlab.com/development/documentation/) and the [Style Guide](https://docs.gitlab.com/development/documentation/styleguide/).
 
 If you aren't sure which tech writer to ask, use [roulette](https://gitlab-org.gitlab.io/gitlab-roulette/?sortKey=stats.avg30&order=-1&hourFormat24=true&visible=maintainer%7Cdocs) or ask in the [#docs](https://gitlab.slack.com/archives/C16HYA2P5) Slack channel.
 
@@ -38,7 +38,7 @@ If you aren't sure which tech writer to ask, use [roulette](https://gitlab-org.g
   - [ ] Ensure docs metadata is present and up-to-date.
   - [ ] Ensure the appropriate [labels](https://about.gitlab.com/handbook/product/ux/technical-writing/workflow/#labels) are added to this MR.
   - [ ] Ensure a release milestone is set.
-  - If relevant to this MR, ensure [content topic type](https://docs.gitlab.com/ee/development/documentation/structure.html) principles are in use, including:
+  - If relevant to this MR, ensure [content topic type](https://docs.gitlab.com/development/documentation/topic_types/) principles are in use, including:
     - [ ] The headings should be something you'd do a Google search for. Instead of `Default behavior`, say something like `Default behavior when you close an issue`.
     - [ ] The headings (other than the page title) should be active. Instead of `Configuring GDK`, say something like `Configure GDK`.
     - [ ] Any task steps should be written as a numbered list.

.gitlab/merge_request_templates/Security Release.md

@@ -41,9 +41,9 @@ See [the general developer security release guidelines](https://gitlab.com/gitla
 /label ~security ~"Category:Runner" ~"devops::verify" ~"group::runner"
 
 [GitLab Runner Security]: https://gitlab.com/gitlab-org/security/gitlab-runner
-[quick actions]: https://docs.gitlab.com/ee/user/project/quick_actions.html#quick-actions-for-issues-merge-requests-and-epics
-[Code Review process]: https://docs.gitlab.com/ee/development/code_review.html
-[Approval Guidelines]: https://docs.gitlab.com/ee/development/code_review.html#approval-guidelines
+[quick actions]: https://docs.gitlab.com/user/project/quick_actions/#quick-actions-for-issues-merge-requests-and-epics
+[Code Review process]: https://docs.gitlab.com/development/code_review/
+[Approval Guidelines]: https://docs.gitlab.com/development/code_review/#approval-guidelines
 [Canonical repository]: https://gitlab.com/gitlab-org/gitlab-runner
 [security release tracking issue]: https://gitlab.com/gitlab-org/gitlab/-/issues/?scope=all&utf8=%E2%9C%93&state=opened&label_name%5B%5D=upcoming%20security%20release
 

CHANGELOG.md

@@ -4502,7 +4502,7 @@ All deprecations, with a detailed description, are listed at
 <https://about.gitlab.com/2019/04/22/gitlab-11-10-released/#release-deprecations>
 
 1. With version 11.10 we're deprecating the feature flag
-   [FF_USE_LEGACY_GIT_CLEAN_STRATEGY](https://docs.gitlab.com/runner/configuration/feature-flags.html#available-feature-flags).
+   [FF_USE_LEGACY_GIT_CLEAN_STRATEGY](https://docs.gitlab.com/runner/configuration/feature-flags/#available-feature-flags).
 
 **Release changes:**
 
@@ -4581,7 +4581,7 @@ All deprecations, with a detailed description, are listed at
    configuration structure will be removed.
 
 5. With version 11.4 we've fixed the way how `entrypoint:` and `command:` options of
-   Extended Docker configuration (<https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#extended-docker-configuration-options>)
+   Extended Docker configuration (<https://docs.gitlab.com/ci/docker/using_docker_images/#extended-docker-configuration-options>)
    are being handled by Kubernetes Executor. The previous implementation was wrong and
    was making the configuration unusable in most cases. However some users could relay
    on this wrong behavior. Because of that we've added a feature flag `FF_K8S_USE_ENTRYPOINT_OVER_COMMAND`
@@ -5719,7 +5719,7 @@ that even in edge cases you can always rely on them.
 - Add internal command for uploading artifacts without the system dependencies
 - Use umask in Docker build containers to fix running jobs as specific user
 - Fix problem with `cache` paths never being archived
-- Add support for [`cache:key`](http://doc.gitlab.com/ce/ci/yaml/index.html#cachekey)
+- Add support for [`cache:key`](https://docs.gitlab.com/ci/yaml/#cachekey)
 - Add warnings about using runner in `user-mode`
 - Push packages to all upcoming distributions (Debian/Ubuntu/Fedora)
 - Rewrite the shell support adding all features to all shells (makes possible to use artifacts and caching on Windows)

CONTRIBUTING.md

@@ -19,19 +19,19 @@ _This notice should stay as the first item in the CONTRIBUTING.md file._
 
 ## Contribute to GitLab Runner
 
-The following content is an extension of the [GitLab contribution guidelines](https://docs.gitlab.com/ce/development/contributing/index.html).
+The following content is an extension of the [GitLab contribution guidelines](https://docs.gitlab.com/development/contributing/).
 
 ### How we prioritize MRs from the wider community
 
-Currently we use a system of [scoped labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels-premium) to help us prioritize which MRs our team will review.
+Currently we use a system of [scoped labels](https://docs.gitlab.com/user/project/labels/#scoped-labels) to help us prioritize which MRs our team will review.
 
 | Label | Meaning | Use Cases |
 | ---- | ----- | ----- |
 | ~"Review::P1" | Highest priority to review. | Indicates a merge request that might solve an urgent pain point for users, contributes to the strategic direction of Runner development as laid out by the Product team, or fixes a critical issue. A hard cap on the number of contributions labelled ~"Review::P1" is set at 3. |
 | ~"Review::P2" | Important merge requests. | When a merge request is important, but has lower impact to customers when compared to merge requests labelled ~"Review::P1". |
 | ~"Review::P3" | Default priority to review. | All incoming merge requests should default to this. |
 
-### Contributing new features that need new or updated `.gitlab-ci.yml` [keywords](https://docs.gitlab.com/ee/ci/yaml/)
+### Contributing new features that need new or updated `.gitlab-ci.yml` [keywords](https://docs.gitlab.com/ci/yaml/)
 
 To execute a job, the GitLab instance processes the `gitlab-ci.yml` configuration
 and creates a data transfer object, containing only data relevant to a job's
@@ -101,12 +101,12 @@ acceptable, while `Fix timestamp in docker executor job output` would be accepta
 
 ### Workflow labels
 
-We have some additional labels plus those defined in [gitlab-ce workflow labels](https://docs.gitlab.com/ce/development/contributing/issue_workflow.html)
+We have some additional labels plus those defined in [gitlab-ce workflow labels](https://docs.gitlab.com/development/contributing/issue_workflow/)
 
 - Additional subjects: ~cache, ~executors, ~"git operations"
 - OS: ~"os::Linux" ~"os::macOS" ~"os::FreeBSD" ~"os::Windows"
 - executor: ~"executor::docker" ~"executor::kubernetes" ~"executor::docker\-machine" ~"executor::shell" ~"executor::parallels" ~"executor::virtualbox"
 - For any [follow-up
-  issues](https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#technical-debt-in-follow-up-issues)
+  issues](https://docs.gitlab.com/development/contributing/issue_workflow/#technical-debt-in-follow-up-issues)
   created during code review the ~"follow-up" label should be added to
   keep track of it.