Commit 50585cdd authored by Achilleas Pipinellis's avatar Achilleas Pipinellis

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
parents 964872eb e5aebccb
This diff is collapsed.
......@@ -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
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:
```
deploy to production:
stage: deploy
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
......@@ -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
`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`
keyword, it is also possible to define it as a separate value. For that, use
the `name` keyword under `environment`:
......@@ -626,7 +627,12 @@ deploy to production:
#### 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
`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.
| See a commit status | | ✓ | ✓ | ✓ | ✓ |
| See a container registry | | ✓ | ✓ | ✓ | ✓ |
| See environments | | ✓ | ✓ | ✓ | ✓ |
| Create new environments | | | ✓ | ✓ | ✓ |
| Stop environments | | | ✓ | ✓ | ✓ |
| See a list of merge requests | | ✓ | ✓ | ✓ | ✓ |
| Manage/Accept merge requests | | | ✓ | ✓ | ✓ |
| Create new merge request | | | ✓ | ✓ | ✓ |
......@@ -45,7 +47,6 @@ The following table depicts the various user permission levels in a project.
| Create or update commit status | | | ✓ | ✓ | ✓ |
| Update a container registry | | | ✓ | ✓ | ✓ |
| Remove a container registry image | | | ✓ | ✓ | ✓ |
| Create new environments | | | ✓ | ✓ | ✓ |
| Create new milestones | | | | ✓ | ✓ |
| Add new team members | | | | ✓ | ✓ |
| Push to protected branches | | | | ✓ | ✓ |
......@@ -58,7 +59,6 @@ The following table depicts the various user permission levels in a project.
| Manage runners | | | | ✓ | ✓ |
| Manage build triggers | | | | ✓ | ✓ |
| Manage variables | | | | ✓ | ✓ |
| Delete environments | | | | ✓ | ✓ |
| Switch visibility level | | | | | ✓ |
| Transfer project to another namespace | | | | | ✓ |
| 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