Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2019-11-05 03:06:09 +00:00
parent 8258d478ba
commit 39a48637e5
7 changed files with 36 additions and 32 deletions

View file

@ -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. > 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 `before_script` is used to define a command that should be run before each
jobs, including deploy jobs, but after the restoration of [artifacts](#artifacts). job, including deploy jobs, but after the restoration of any [artifacts](#artifacts).
This must be an an array. This must be an an array.
`after_script` is used to define the command that will be run after all Scripts specified in `before_script` are concatenated with any scripts specified
jobs, including failed ones. This must be an an array. 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 Scripts specified in `after_script` are executed in a new shell, separate from any
`before_script` definition override global-level `before_script` definition `before_script` or `script` scripts. As a result, they:
when concatenated with `script` definition.
- Executed together with main `script` script as one script in a single shell
context.
Scripts specified in `after_script`:
- Have a current working directory set back to the default. - Have a current working directory set back to the default.
- Are executed in a shell context separated from `before_script` and `script` - Have no access to changes done by scripts defined in `before_script` or `script`, including:
scripts. - Command aliases and variables exported in `script` scripts.
- Because of separated context, cannot see changes done by scripts defined - Changes outside of the working tree (depending on the Runner executor), like
in `before_script` or `script` scripts, either: software installed by a `before_script` or `script` script.
- 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` It's possible to overwrite a globally defined `before_script` or `after_script`
if you set it per-job: if you set it per-job:
```yaml ```yaml

View file

@ -27,7 +27,7 @@ New utility classes should be added to [`utilities.scss`](https://gitlab.com/git
| Font size | `.text-{size}` | `.text-2` | | Font size | `.text-{size}` | `.text-2` |
- `{variant}` is one of 'primary', 'secondary', 'success', 'warning', 'error' - `{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) - `{size}` is a number from 1-6 from our [Type scale](https://design.gitlab.com/product-foundations/typography)
#### When should I create component classes? #### When should I create component classes?

View file

@ -35,7 +35,7 @@ Please see the [installation from source guide](installation.md) and the [instal
### Microsoft Windows ### Microsoft Windows
GitLab is developed for Linux-based operating systems. 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. Please consider using a virtual machine to run GitLab.
## Ruby versions ## Ruby versions

View file

@ -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 [Access controls](../../project/clusters/add_remove_clusters.md#access-controls) section for details on which resources will
be created. be created.
If you choose to manage your own cluster, project-specific resources will not be created For clusters not managed by GitLab, project-specific resources will not be created
automatically. If you are using [Auto DevOps](../../../topics/autodevops/index.md), you will automatically. If you are using [Auto DevOps](../../../topics/autodevops/index.md)
need to explicitly provide the `KUBE_NAMESPACE` [deployment variable](../../project/clusters/index.md#deployment-variables) for deployments with a cluster not managed by GitLab, you must ensure:
that will be used by your deployment jobs.
- 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:** NOTE: **Note:**
If you [install applications](#installing-applications) on your cluster, GitLab will create If you [install applications](#installing-applications) on your cluster, GitLab will create

Binary file not shown.

Before

Width:  |  Height:  |  Size: 3.8 KiB

View file

@ -5,10 +5,7 @@
The Operations Dashboard provides a summary of each project's operational health, The Operations Dashboard provides a summary of each project's operational health,
including pipeline and alert status. including pipeline and alert status.
The dashboard can be accessed via the top bar, by clicking on the new The dashboard can be accessed via the top bar, by clicking **More > Operations**.
dashboard icon:
![Operations Dashboard icon in top bar](img/index_operations_dashboard_top_bar_icon.png)
## Adding a project to the dashboard ## Adding a project to the dashboard

View file

@ -247,7 +247,7 @@ GitLab CI/CD build environment.
| -------- | ----------- | | -------- | ----------- |
| `KUBE_URL` | Equal to the API URL. | | `KUBE_URL` | Equal to the API URL. |
| `KUBE_TOKEN` | The Kubernetes token of the [environment service account](add_remove_clusters.md#access-controls). | | `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_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. | | `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`. | | `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:** NOTE: **Note:**
If your cluster was created before GitLab 12.2, default `KUBE_NAMESPACE` will be set to `<project_name>-<project_id>`. 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 ### Troubleshooting
Before the deployment jobs starts, GitLab creates the following specifically for Before the deployment jobs starts, GitLab creates the following specifically for