Commit 00aa3f40 authored by Achilleas Pipinellis's avatar Achilleas Pipinellis Committed by Alejandro Rodríguez

Merge branch 'docs/refactor-environments' into 'master'

Refactor environments documentation

## What does this MR do?

Refactor environments docs.

## What are the relevant issue numbers?

https://gitlab.com/gitlab-org/gitlab-ce/issues/23484

See merge request !7107
parent 5cf15595
This diff is collapsed.
...@@ -552,28 +552,14 @@ An example usage of manual actions is deployment to production. ...@@ -552,28 +552,14 @@ An example usage of manual actions is deployment to production.
If `environment` is specified and no environment under that name exists, a new If `environment` is specified and no environment under that name exists, a new
one will be created automatically. one will be created automatically.
The `environment` name can contain:
- letters
- digits
- spaces
- `-`
- `_`
- `/`
- `$`
- `{`
- `}`
Common names are `qa`, `staging`, and `production`, but you can use whatever
name works with your workflow.
In its simplest form, the `environment` keyword can be defined like: In its simplest form, the `environment` keyword can be defined like:
``` ```
deploy to production: deploy to production:
stage: deploy stage: deploy
script: git push production HEAD:master script: git push production HEAD:master
environment: production environment:
name: production
``` ```
In the above example, the `deploy to production` job will be marked as doing a In the above example, the `deploy to production` job will be marked as doing a
...@@ -588,6 +574,21 @@ Before GitLab 8.11, the name of an environment could be defined as a string like ...@@ -588,6 +574,21 @@ Before GitLab 8.11, the name of an environment could be defined as a string like
`environment: production`. The recommended way now is to define it under the `environment: production`. The recommended way now is to define it under the
`name` keyword. `name` keyword.
The `environment` name can contain:
- letters
- digits
- spaces
- `-`
- `_`
- `/`
- `$`
- `{`
- `}`
Common names are `qa`, `staging`, and `production`, but you can use whatever
name works with your workflow.
Instead of defining the name of the environment right after the `environment` Instead of defining the name of the environment right after the `environment`
keyword, it is also possible to define it as a separate value. For that, use keyword, it is also possible to define it as a separate value. For that, use
the `name` keyword under `environment`: the `name` keyword under `environment`:
...@@ -626,7 +627,12 @@ deploy to production: ...@@ -626,7 +627,12 @@ deploy to production:
#### environment:on_stop #### environment:on_stop
> [Introduced][ce-6669] in GitLab 8.13. >
**Notes:**
- [Introduced][ce-6669] in GitLab 8.13.
- Starting with GitLab 8.14, when you have an environment that has a stop action
defined, GitLab will automatically trigger a stop action when the associated
branch is deleted.
Closing (stoping) environments can be achieved with the `on_stop` keyword defined under Closing (stoping) environments can be achieved with the `on_stop` keyword defined under
`environment`. It declares a different job that runs in order to close `environment`. It declares a different job that runs in order to close
......
...@@ -32,6 +32,8 @@ The following table depicts the various user permission levels in a project. ...@@ -32,6 +32,8 @@ The following table depicts the various user permission levels in a project.
| See a commit status | | ✓ | ✓ | ✓ | ✓ | | See a commit status | | ✓ | ✓ | ✓ | ✓ |
| See a container registry | | ✓ | ✓ | ✓ | ✓ | | See a container registry | | ✓ | ✓ | ✓ | ✓ |
| See environments | | ✓ | ✓ | ✓ | ✓ | | See environments | | ✓ | ✓ | ✓ | ✓ |
| Create new environments | | | ✓ | ✓ | ✓ |
| Stop environments | | | ✓ | ✓ | ✓ |
| See a list of merge requests | | ✓ | ✓ | ✓ | ✓ | | See a list of merge requests | | ✓ | ✓ | ✓ | ✓ |
| Manage/Accept merge requests | | | ✓ | ✓ | ✓ | | Manage/Accept merge requests | | | ✓ | ✓ | ✓ |
| Create new merge request | | | ✓ | ✓ | ✓ | | Create new merge request | | | ✓ | ✓ | ✓ |
...@@ -45,7 +47,6 @@ The following table depicts the various user permission levels in a project. ...@@ -45,7 +47,6 @@ The following table depicts the various user permission levels in a project.
| Create or update commit status | | | ✓ | ✓ | ✓ | | Create or update commit status | | | ✓ | ✓ | ✓ |
| Update a container registry | | | ✓ | ✓ | ✓ | | Update a container registry | | | ✓ | ✓ | ✓ |
| Remove a container registry image | | | ✓ | ✓ | ✓ | | Remove a container registry image | | | ✓ | ✓ | ✓ |
| Create new environments | | | ✓ | ✓ | ✓ |
| Create new milestones | | | | ✓ | ✓ | | Create new milestones | | | | ✓ | ✓ |
| Add new team members | | | | ✓ | ✓ | | Add new team members | | | | ✓ | ✓ |
| Push to protected branches | | | | ✓ | ✓ | | Push to protected branches | | | | ✓ | ✓ |
...@@ -58,7 +59,6 @@ The following table depicts the various user permission levels in a project. ...@@ -58,7 +59,6 @@ The following table depicts the various user permission levels in a project.
| Manage runners | | | | ✓ | ✓ | | Manage runners | | | | ✓ | ✓ |
| Manage build triggers | | | | ✓ | ✓ | | Manage build triggers | | | | ✓ | ✓ |
| Manage variables | | | | ✓ | ✓ | | Manage variables | | | | ✓ | ✓ |
| Delete environments | | | | ✓ | ✓ |
| Switch visibility level | | | | | ✓ | | Switch visibility level | | | | | ✓ |
| Transfer project to another namespace | | | | | ✓ | | Transfer project to another namespace | | | | | ✓ |
| Remove project | | | | | ✓ | | Remove project | | | | | ✓ |
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment