Merge branch 'selhorn-docs-here-linktext' into 'master'

Removed link references to here

See merge request gitlab-org/gitlab!60858

doc/administration/geo/index.md

@@ -27,7 +27,7 @@ to clone and fetch large repositories, speeding up development.
 
 For a video introduction to Geo, see [Introduction to GitLab Geo - GitLab Features](https://www.youtube.com/watch?v=-HDLxSjEh6w).
 
-To make sure you're using the right version of the documentation, navigate to [this page on GitLab.com](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/administration/geo/index.md) and choose the appropriate release from the **Switch branch/tag** dropdown. For example, [`v11.2.3-ee`](https://gitlab.com/gitlab-org/gitlab/blob/v11.2.3-ee/doc/administration/geo/index.md).
+To make sure you're using the right version of the documentation, navigate to [the Geo page on GitLab.com](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/administration/geo/index.md) and choose the appropriate release from the **Switch branch/tag** dropdown. For example, [`v11.2.3-ee`](https://gitlab.com/gitlab-org/gitlab/blob/v11.2.3-ee/doc/administration/geo/index.md).
 
 ## Use cases
 

doc/administration/packages/container_registry.md

@@ -1304,8 +1304,8 @@ GitLab Rails application, the Docker Registry, or something else. In this
 case, since we know that since the login succeeded, we probably need to look
 at the communication between the client and the Registry.
 
-The REST API between the Docker client and Registry is [described
-here](https://docs.docker.com/registry/spec/api/). Normally, one would just
+The REST API between the Docker client and Registry is described
+[in the Docker documentation](https://docs.docker.com/registry/spec/api/). Normally, one would just
 use Wireshark or tcpdump to capture the traffic and see where things went
 wrong. However, since all communications between Docker clients and servers
 are done over HTTPS, it's a bit difficult to decrypt the traffic quickly even

doc/api/events.md

@@ -71,10 +71,10 @@ Parameters:
 | --------- | ---- | -------- | ----------- |
 | `action` | string | no | Include only events of a particular [action type](#action-types) |
 | `target_type` | string | no | Include only events of a particular [target type](#target-types) |
-| `before` | date | no |  Include only events created before a particular date. Please see [here for the supported format](#date-formatting) |
-| `after` | date | no |  Include only events created after a particular date. Please see [here for the supported format](#date-formatting)  |
+| `before` | date | no |  Include only events created before a particular date. [View how to format dates](#date-formatting). |
+| `after` | date | no |  Include only events created after a particular date. [View how to format dates](#date-formatting).  |
 | `scope` | string | no | Include all events across a user's projects. |
-| `sort` | string | no | Sort events in `asc` or `desc` order by `created_at`. Default is `desc` |
+| `sort` | string | no | Sort events in `asc` or `desc` order by `created_at`. Default is `desc`. |
 
 Example request:
 
@@ -148,9 +148,9 @@ Parameters:
 | `id` | integer | yes | The ID or Username of the user |
 | `action` | string | no | Include only events of a particular [action type](#action-types) |
 | `target_type` | string | no | Include only events of a particular [target type](#target-types) |
-| `before` | date | no |  Include only events created before a particular date. Please see [here for the supported format](#date-formatting) |
-| `after` | date | no |  Include only events created after a particular date. Please see [here for the supported format](#date-formatting)  |
-| `sort` | string | no | Sort events in `asc` or `desc` order by `created_at`. Default is `desc` |
+| `before` | date | no |  Include only events created before a particular date. [View how to format dates](#date-formatting). |
+| `after` | date | no |  Include only events created after a particular date. [View how to format dates](#date-formatting). |
+| `sort` | string | no | Sort events in `asc` or `desc` order by `created_at`. Default is `desc`. |
 | `page` | integer | no | The page of results to return. Defaults to 1. |
 | `per_page` | integer | no | The number of results per page. Defaults to 20. |
 
@@ -286,9 +286,9 @@ Parameters:
 | `project_id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) |
 | `action` | string | no | Include only events of a particular [action type](#action-types) |
 | `target_type` | string | no | Include only events of a particular [target type](#target-types) |
-| `before` | date | no |  Include only events created before a particular date. Please see [here for the supported format](#date-formatting) |
-| `after` | date | no |  Include only events created after a particular date. Please see [here for the supported format](#date-formatting)  |
-| `sort` | string | no | Sort events in `asc` or `desc` order by `created_at`. Default is `desc` |
+| `before` | date | no |  Include only events created before a particular date. [View how to format dates](#date-formatting). |
+| `after` | date | no |  Include only events created after a particular date. [View how to format dates](#date-formatting).  |
+| `sort` | string | no | Sort events in `asc` or `desc` order by `created_at`. Default is `desc`. |
 
 Example request:
 

doc/architecture/blueprints/container_registry_metadata_database/index.md

@@ -26,7 +26,7 @@ graph LR
    R -- Write/read metadata --> B
 ```
 
-Client applications (e.g. GitLab Rails and Docker CLI) interact with the Container Registry through its [HTTP API](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/spec/api.md). The most common operations are pushing and pulling images to/from the registry, which require a series of HTTP requests in a specific order. The request flow for these operations is detailed [here](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs-gitlab/push-pull-request-flow.md).
+Client applications (e.g. GitLab Rails and Docker CLI) interact with the Container Registry through its [HTTP API](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/spec/api.md). The most common operations are pushing and pulling images to/from the registry, which require a series of HTTP requests in a specific order. The request flow for these operations is detailed in the [Request flow](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs-gitlab/push-pull-request-flow.md).
 
 The registry supports multiple [storage backends](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#storage), including Google Cloud Storage (GCS) which is used for the GitLab.com registry. In the storage backend, images are stored as blobs, deduplicated, and shared across repositories. These are then linked (like a symlink) to each repository that relies on them, giving them access to the central storage location.
 
@@ -156,7 +156,7 @@ Running *online* and [*post deployment*](../../../development/post_deployment_mi
 
 The registry database will be partitioned from start to achieve greater performance (by limiting the amount of data to act upon and enable parallel execution), easier maintenance (by splitting tables and indexes into smaller units), and high availability (with partition independence). By partitioning the database from start we can also facilitate a sharding implementation later on if necessary.
 
-Although blobs are shared across repositories, manifest and tag metadata are scoped by repository. This is also visible at the API level, where all write and read requests (except [listing repositories](https://gitlab.com/gitlab-org/container-registry/-/blob/a113d0f0ab29b49cf88e173ee871893a9fc56a90/docs/spec/api.md#listing-repositories)) are scoped by repository, with its namespace being part of the request URI. For this reason, after [identifying access patterns](https://gitlab.com/gitlab-org/gitlab/-/issues/234255), we decided to partition manifests and tags by repository and blobs by digest, ensuring that lookups are always performed by partition key for optimal performance. The initial version of the partitioned schema was documented [here](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/60918).
+Although blobs are shared across repositories, manifest and tag metadata are scoped by repository. This is also visible at the API level, where all write and read requests (except [listing repositories](https://gitlab.com/gitlab-org/container-registry/-/blob/a113d0f0ab29b49cf88e173ee871893a9fc56a90/docs/spec/api.md#listing-repositories)) are scoped by repository, with its namespace being part of the request URI. For this reason, after [identifying access patterns](https://gitlab.com/gitlab-org/gitlab/-/issues/234255), we decided to partition manifests and tags by repository and blobs by digest, ensuring that lookups are always performed by partition key for optimal performance. The initial version of the partitioned schema was documented [in a merge request](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/60918).
 
 #### GitLab.com
 

doc/architecture/blueprints/image_resizing/index.md

@@ -35,10 +35,10 @@ sequenceDiagram
 
 Content image resizing is a more complex problem to tackle. There are no set size restrictions and there are additional features or requirements to consider.
 
-- Dynamic WebP support - the WebP format typically achieves an average of 30% more compression than JPEG without the loss of image quality. More details [here](https://developers.google.com/speed/webp/docs/c_study)
+- Dynamic WebP support - the WebP format typically achieves an average of 30% more compression than JPEG without the loss of image quality. More details are in [this Google Comparative Study](https://developers.google.com/speed/webp/docs/c_study)
 - Extract first image of GIF's so we can prevent from loading 10MB pixels
 - Check Device Pixel Ratio to deliver nice images on High DPI screens
-- Progressive image loading, similar to what is described [here](https://www.sitepoint.com/how-to-build-your-own-progressive-image-loader/)
+- Progressive image loading, similar to what is described in [this article about how to build a progressive image loader](https://www.sitepoint.com/how-to-build-your-own-progressive-image-loader/)
 - Resizing recommendations (size, clarity, etc.)
 - Storage
 

doc/development/feature_flags/controls.md

@@ -266,7 +266,7 @@ Changes to the issue format can be submitted in the
 Any feature flag change that affects any GitLab instance is automatically logged in
 [features_json.log](../../administration/logs.md#features_jsonlog).
 You can search the change history in [Kibana](https://about.gitlab.com/handbook/support/workflows/kibana.html).
-You can access the feature flag change history for GitLab.com [here](https://log.gprd.gitlab.net/goto/d060337c017723084c6d97e09e591fc6).
+You can also access the feature flag change history for GitLab.com [in Kibana](https://log.gprd.gitlab.net/goto/d060337c017723084c6d97e09e591fc6).
 
 ## Cleaning up
 

doc/development/multi_version_compatibility.md

@@ -65,7 +65,7 @@ Let's see how we can handle them safely.
 ### Route changes
 
 When changing routing we should pay attention to make sure a route generated from the new version can be served by the old one and vice versa.
-As you can see in [this page](#some-links-to-issues-and-mrs-were-broken), not doing it can lead to an outage.
+[As you can see](#some-links-to-issues-and-mrs-were-broken), not doing it can lead to an outage.
 This type of change may look like an immediate switch between the two implementations. However,
 especially with the canary stage, there is an extended period of time where both version of the code
 coexists in production.

doc/development/packages.md

@@ -219,8 +219,8 @@ demonstrates adding an instance-level endpoint for Conan to workhorse. You can a
 implemented in the same file.
 
 Once the route has been added, you must add an additional `/authorize` version of the upload endpoint to your API file.
-[Here is an example](https://gitlab.com/gitlab-org/gitlab/blob/398fef1ca26ae2b2c3dc89750f6b20455a1e5507/ee/lib/api/maven_packages.rb#L164)
-of the additional endpoint added for Maven. The `/authorize` endpoint verifies and authorizes the request from workhorse,
+[This example](https://gitlab.com/gitlab-org/gitlab/blob/398fef1ca26ae2b2c3dc89750f6b20455a1e5507/ee/lib/api/maven_packages.rb#L164)
+shows the additional endpoint added for Maven. The `/authorize` endpoint verifies and authorizes the request from workhorse,
 then the normal upload endpoint is implemented below, consuming the metadata that workhorse provides in order to
 create the package record. Workhorse provides a variety of file metadata such as type, size, and different checksum formats.
 

doc/user/project/integrations/prometheus_library/cloudwatch.md

@@ -31,7 +31,7 @@ Cloudwatch exporter retrieves and parses the specified Cloudwatch metrics, and
 translates them into a Prometheus monitoring endpoint.
 
 The only supported AWS resource is the Elastic Load Balancer, whose Cloudwatch
-metrics are [documented here](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-cloudwatch-metrics.html).
+metrics are listed in [this AWS documentation](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-cloudwatch-metrics.html).
 
 You can [download a sample Cloudwatch Exporter configuration file](../samples/cloudwatch.yml)
 that's configured for basic AWS ELB monitoring.