kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

Browse source
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
Show stats Download patch file Download diff file Expand all files Collapse all files

34
doc/ci/yaml/README.md
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.
`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.
- 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 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:
```yaml

2
doc/development/fe_guide/style_guide_scss.md
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` |
- `{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?

2
doc/install/requirements.md
View file

@ -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

13
doc/user/group/clusters/index.md
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
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

BIN
doc/user/operations_dashboard/img/index_operations_dashboard_top_bar_icon.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 3.8 KiB

5
doc/user/operations_dashboard/index.md
View file

@ -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

12
doc/user/project/clusters/index.md
View file

@ -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