diff options
-rw-r--r-- | doc/ci/yaml/README.md | 36 | ||||
-rw-r--r-- | doc/development/fe_guide/style_guide_scss.md | 2 | ||||
-rw-r--r-- | doc/install/requirements.md | 2 | ||||
-rw-r--r-- | doc/user/group/clusters/index.md | 13 | ||||
-rw-r--r-- | doc/user/operations_dashboard/img/index_operations_dashboard_top_bar_icon.png | bin | 3922 -> 0 bytes | |||
-rw-r--r-- | doc/user/operations_dashboard/index.md | 5 | ||||
-rw-r--r-- | doc/user/project/clusters/index.md | 12 |
7 files changed, 37 insertions, 33 deletions
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index eb78ceacf26..9ebc0569127 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -259,34 +259,26 @@ For more information, see see [Available settings for `services`](../docker/usin > Introduced in GitLab 8.7 and requires GitLab Runner v1.2. -`before_script` is used to define the command that should be run before all -jobs, including deploy jobs, but after the restoration of [artifacts](#artifacts). +`before_script` is used to define a command that should be run before each +job, including deploy jobs, but after the restoration of any [artifacts](#artifacts). This must be an an array. -`after_script` is used to define the command that will be run after all -jobs, including failed ones. This must be an an array. +Scripts specified in `before_script` are concatenated with any scripts specified +in the main [`script`](#script), and executed together in a single shell. -Scripts specified in `before_script` are: +`after_script` is used to define the command that will be run after each +job, including failed ones. This must be an an array. -- Concatenated with scripts specified in the main `script`. Job-level - `before_script` definition override global-level `before_script` definition - when concatenated with `script` definition. -- Executed together with main `script` script as one script in a single shell - context. - -Scripts specified in `after_script`: +Scripts specified in `after_script` are executed in a new shell, separate from any +`before_script` or `script` scripts. As a result, they: - Have a current working directory set back to the default. -- Are executed in a shell context separated from `before_script` and `script` - scripts. -- Because of separated context, cannot see changes done by scripts defined - in `before_script` or `script` scripts, either: - - In shell. For example, command aliases and variables exported in `script` - scripts. - - Outside of the working tree (depending on the Runner executor). For example, - software installed by a `before_script` or `script` scripts. - -It's possible to overwrite the globally defined `before_script` and `after_script` +- Have no access to changes done by scripts defined in `before_script` or `script`, including: + - Command aliases and variables exported in `script` scripts. + - Changes outside of the working tree (depending on the Runner executor), like + software installed by a `before_script` or `script` script. + +It's possible to overwrite a globally defined `before_script` or `after_script` if you set it per-job: ```yaml diff --git a/doc/development/fe_guide/style_guide_scss.md b/doc/development/fe_guide/style_guide_scss.md index 07c87920dab..54d41b42c77 100644 --- a/doc/development/fe_guide/style_guide_scss.md +++ b/doc/development/fe_guide/style_guide_scss.md @@ -27,7 +27,7 @@ New utility classes should be added to [`utilities.scss`](https://gitlab.com/git | Font size | `.text-{size}` | `.text-2` | - `{variant}` is one of 'primary', 'secondary', 'success', 'warning', 'error' -- `{shade}` is on of the shades listed on [colors](https://design.gitlab.com/product-foundations/colors/) +- `{shade}` is one of the shades listed on [colors](https://design.gitlab.com/product-foundations/colors/) - `{size}` is a number from 1-6 from our [Type scale](https://design.gitlab.com/product-foundations/typography) #### When should I create component classes? diff --git a/doc/install/requirements.md b/doc/install/requirements.md index 8b53ee7c3e1..ecd6516bd2e 100644 --- a/doc/install/requirements.md +++ b/doc/install/requirements.md @@ -35,7 +35,7 @@ Please see the [installation from source guide](installation.md) and the [instal ### Microsoft Windows GitLab is developed for Linux-based operating systems. -It does **not** run on Microsoft Windows, and we have no plans to support it in the near future. For the latest development status view this [issue](https://gitlab.com/gitlab-org/gitlab-foss/issues/46567). +It does **not** run on Microsoft Windows, and we have no plans to support it in the near future. For the latest development status view this [issue](https://gitlab.com/gitlab-org/gitlab/issues/22337). Please consider using a virtual machine to run GitLab. ## Ruby versions diff --git a/doc/user/group/clusters/index.md b/doc/user/group/clusters/index.md index d3a3a1ea283..1fe456902a2 100644 --- a/doc/user/group/clusters/index.md +++ b/doc/user/group/clusters/index.md @@ -61,10 +61,15 @@ managed by GitLab, resources for your projects will be automatically created. Se [Access controls](../../project/clusters/add_remove_clusters.md#access-controls) section for details on which resources will be created. -If you choose to manage your own cluster, project-specific resources will not be created -automatically. If you are using [Auto DevOps](../../../topics/autodevops/index.md), you will -need to explicitly provide the `KUBE_NAMESPACE` [deployment variable](../../project/clusters/index.md#deployment-variables) -that will be used by your deployment jobs. +For clusters not managed by GitLab, project-specific resources will not be created +automatically. If you are using [Auto DevOps](../../../topics/autodevops/index.md) +for deployments with a cluster not managed by GitLab, you must ensure: + +- The project's deployment service account has permissions to deploy to + [`KUBE_NAMESPACE`](../../project/clusters/index.md#deployment-variables). +- `KUBECONFIG` correctly reflects any changes to `KUBE_NAMESPACE` + (this is [not automatic](https://gitlab.com/gitlab-org/gitlab/issues/31519)). Editing + `KUBE_NAMESPACE` directly is discouraged. NOTE: **Note:** If you [install applications](#installing-applications) on your cluster, GitLab will create diff --git a/doc/user/operations_dashboard/img/index_operations_dashboard_top_bar_icon.png b/doc/user/operations_dashboard/img/index_operations_dashboard_top_bar_icon.png Binary files differdeleted file mode 100644 index d4db5e88672..00000000000 --- a/doc/user/operations_dashboard/img/index_operations_dashboard_top_bar_icon.png +++ /dev/null diff --git a/doc/user/operations_dashboard/index.md b/doc/user/operations_dashboard/index.md index 649a95a5f3a..8faf6cda1a8 100644 --- a/doc/user/operations_dashboard/index.md +++ b/doc/user/operations_dashboard/index.md @@ -5,10 +5,7 @@ The Operations Dashboard provides a summary of each project's operational health, including pipeline and alert status. -The dashboard can be accessed via the top bar, by clicking on the new -dashboard icon: - -![Operations Dashboard icon in top bar](img/index_operations_dashboard_top_bar_icon.png) +The dashboard can be accessed via the top bar, by clicking **More > Operations**. ## Adding a project to the dashboard diff --git a/doc/user/project/clusters/index.md b/doc/user/project/clusters/index.md index 1867b9c0198..c5c2c2c07e7 100644 --- a/doc/user/project/clusters/index.md +++ b/doc/user/project/clusters/index.md @@ -247,7 +247,7 @@ GitLab CI/CD build environment. | -------- | ----------- | | `KUBE_URL` | Equal to the API URL. | | `KUBE_TOKEN` | The Kubernetes token of the [environment service account](add_remove_clusters.md#access-controls). | -| `KUBE_NAMESPACE` | The Kubernetes namespace is auto-generated if not specified. The default value is `<project_name>-<project_id>-<environment>`. You can overwrite it to use different one if needed, otherwise the `KUBE_NAMESPACE` variable will receive the default value. | +| `KUBE_NAMESPACE` | The namespace associated with the project's deployment service account. In the format `<project_name>-<project_id>-<environment>`. For GitLab-managed clusters, a matching namespace is automatically created by GitLab in the cluster. | | `KUBE_CA_PEM_FILE` | Path to a file containing PEM data. Only present if a custom CA bundle was specified. | | `KUBE_CA_PEM` | (**deprecated**) Raw PEM data. Only if a custom CA bundle was specified. | | `KUBECONFIG` | Path to a file containing `kubeconfig` for this deployment. CA bundle would be embedded if specified. This config also embeds the same token defined in `KUBE_TOKEN` so you likely will only need this variable. This variable name is also automatically picked up by `kubectl` so you won't actually need to reference it explicitly if using `kubectl`. | @@ -260,6 +260,16 @@ service account of the cluster integration. NOTE: **Note:** If your cluster was created before GitLab 12.2, default `KUBE_NAMESPACE` will be set to `<project_name>-<project_id>`. +When deploying a custom namespace: + +- The custom namespace must exist in your cluster. +- The project's deployment service account must have permission to deploy to the namespace. +- `KUBECONFIG` must be updated to use the custom namespace instead of the GitLab-provided default (this is [not automatic](https://gitlab.com/gitlab-org/gitlab/issues/31519)). +- If deploying with Auto DevOps, you must *also* override `KUBE_NAMESPACE` with the custom namespace. + +CAUTION: **Caution:** +GitLab does not save custom namespaces in the database. So while deployments work with custom namespaces, GitLab's integration for already-deployed environments will not pick up the customized values. For example, [Deploy Boards](../deploy_boards.md) will not work as intended for those deployments. For more information, see the [related issue](https://gitlab.com/gitlab-org/gitlab/issues/27630). + ### Troubleshooting Before the deployment jobs starts, GitLab creates the following specifically for |