diff --git a/doc/development/documentation/styleguide/word_list.md b/doc/development/documentation/styleguide/word_list.md index 3dea0537668f7475bed8547317ee7167e412836f..407bf0c09f96c2a106e0f9e9704c290752f5aafe 100644 --- a/doc/development/documentation/styleguide/word_list.md +++ b/doc/development/documentation/styleguide/word_list.md @@ -201,10 +201,6 @@ CI/CD is always uppercase. No need to spell it out on first use. Use **CI/CD minutes** instead of **CI minutes**, **pipeline minutes**, **pipeline minutes quota**, or **CI pipeline minutes**. This decision was made in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/342813). -## CI/CD tunnel - -Use lowercase for **tunnel** in **CI/CD tunnel**. - ## click Do not use **click**. Instead, use **select** with buttons, links, menu items, and lists. diff --git a/doc/topics/autodevops/customize.md b/doc/topics/autodevops/customize.md index 089f9f8e7cc83a60425e1e9757df8e61f889ea6b..ceb745138ee9f4f828a29c97e3353ff4c42066ee 100644 --- a/doc/topics/autodevops/customize.md +++ b/doc/topics/autodevops/customize.md @@ -431,7 +431,7 @@ applications. | `HELM_UPGRADE_EXTRA_ARGS` | Allows extra options in `helm upgrade` commands when deploying the application. Note that using quotes doesn't prevent word splitting. | | `INCREMENTAL_ROLLOUT_MODE` | If present, can be used to enable an [incremental rollout](#incremental-rollout-to-production) of your application for the production environment. Set to `manual` for manual deployment jobs or `timed` for automatic rollout deployments with a 5 minute delay each one. | | `K8S_SECRET_*` | Any variable prefixed with [`K8S_SECRET_`](#application-secret-variables) is made available by Auto DevOps as environment variables to the deployed application. | -| `KUBE_CONTEXT` | From GitLab 14.5, can be used to select which context to use from `KUBECONFIG`. When `KUBE_CONTEXT` is blank, the default context in `KUBECONFIG` (if any) will be used. A context must be selected when using the [CI/CD tunnel](../../user/clusters/agent/ci_cd_tunnel.md). | +| `KUBE_CONTEXT` | From GitLab 14.5, can be used to select a context to use from `KUBECONFIG`. When `KUBE_CONTEXT` is blank, the default context in `KUBECONFIG` (if any) is used. A context must be selected when used [with the agent for Kubernetes](../../user/clusters/agent/ci_cd_tunnel.md). | | `KUBE_INGRESS_BASE_DOMAIN` | Can be used to set a domain per cluster. See [cluster domains](../../user/project/clusters/gitlab_managed_clusters.md#base-domain) for more information. | | `KUBE_NAMESPACE` | The namespace used for deployments. When using certificate-based clusters, [this value should not be overwritten directly](../../user/project/clusters/deploy_to_cluster.md#custom-namespace). | | `KUBECONFIG` | The kubeconfig to use for deployments. User-provided values take priority over GitLab-provided values. | diff --git a/doc/topics/release_your_application.md b/doc/topics/release_your_application.md index c0fb3652d814e3b1d175482f2ffba680be0752ef..7ed227adcac84d7bea051bbd264486ff60fd948b 100644 --- a/doc/topics/release_your_application.md +++ b/doc/topics/release_your_application.md @@ -30,14 +30,14 @@ to Kubernetes clusters using the [GitLab agent](../user/clusters/agent/install/i #### GitOps deployments **(PREMIUM)** -With the [GitLab agent](../user/clusters/agent/install/index.md), you can perform [pull-based +With the [GitLab agent for Kubernetes](../user/clusters/agent/install/index.md), you can perform [pull-based deployments of Kubernetes manifests](../user/clusters/agent/gitops.md). This provides a scalable, secure, and cloud-native approach to manage Kubernetes deployments. -#### Deploy to Kubernetes with the CI/CD Tunnel +#### Deploy to Kubernetes from GitLab CI/CD -With the [GitLab agent](../user/clusters/agent/install/index.md), you can perform push-based -deployments with the [CI/CD Tunnel](../user/clusters/agent/ci_cd_tunnel.md). It provides +With the [GitLab agent for Kubernetes](../user/clusters/agent/install/index.md), you can perform [push-based +deployments](../user/clusters/agent/ci_cd_tunnel.md) from GitLab CI/CD. The agent provides a secure and reliable connection between GitLab and your Kubernetes cluster. ### Deploy to AWS with GitLab CI/CD diff --git a/doc/user/clusters/management_project_template.md b/doc/user/clusters/management_project_template.md index 93af5849fcbfc535fb9055126e528e324d822608..47c743e1c601b93b0325fa4ab4754d5573abba57 100644 --- a/doc/user/clusters/management_project_template.md +++ b/doc/user/clusters/management_project_template.md @@ -25,7 +25,7 @@ For instance, you can: The template contains the following [components](#configure-the-available-components): -- A pre-configured GitLab CI/CD file so that you can configure CI/CD pipelines using the [CI/CD Tunnel](agent/ci_cd_tunnel.md). +- A pre-configured `.gitlab-ci.yml`file so that you can configure CI/CD pipelines using [the agent for Kubernetes](agent/ci_cd_tunnel.md). - A pre-configured [Helmfile](https://github.com/roboll/helmfile) so that you can manage cluster applications with [Helm v3](https://helm.sh/). - An `applications` directory with a `helmfile.yaml` configured for each @@ -69,7 +69,7 @@ We assume that you already have a cluster connected through the agent and 1. [Create a new project from the Cluster Management Project Template](#create-a-new-project-based-on-the-cluster-management-template). This new project is "project B". -1. In your "project A", [grant the agent access to the new project (B) through the CI/CD Tunnel](agent/ci_cd_tunnel.md#authorize-the-agent). +1. In your "project A", [grant the agent access to the new project (B)](agent/ci_cd_tunnel.md#authorize-the-agent). 1. From the "project's B" settings, add a [new environment variable](../../ci/variables/index.md#add-a-cicd-variable-to-a-project) `$KUBE_CONTEXT` and set it to `path/to/agent-configuration-project:your-agent-name`. 1. In "project B", [configure the components](#configure-the-available-components) inherited from the template. diff --git a/doc/user/infrastructure/clusters/index.md b/doc/user/infrastructure/clusters/index.md index 5f9cc2e2f5fee987e462d1b66fc68cac1faeb73d..cd7c5feb284eb35debaed3bed6fb450a870accdd 100644 --- a/doc/user/infrastructure/clusters/index.md +++ b/doc/user/infrastructure/clusters/index.md @@ -67,6 +67,5 @@ The concept of [project-level](../../project/clusters/index.md), [instance-level](../../instance/clusters/index.md) clusters becomes extinct in the new model, although the functionality remains to some extent. -The agent is always configured in a single GitLab project, but you can use the CI/CD Tunnel to -authorize other projects and groups to use the same agent. +The agent is always configured in a single GitLab project and you can expose the cluster connection to other projects and groups to [access it from GitLab CI/CD](../../clusters/agent/ci_cd_tunnel.md). By doing so, you are granting these projects and groups access to the same cluster, which is similar to group-level clusters' use case.