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

Small fixes in CI build permissions docs

Browse source 
- Add link to external user
- Move build triggers up
This commit is contained in:
Achilleas Pipinellis 2016-09-22 16:48:56 +03:00
parent 76c8233b30
commit 04d7814897
2 changed files with 17 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
doc/ci/README.md
View file

@ -19,4 +19,4 @@
- [Build permissions](../user/permissions.md#build-permissions)
- [API](../api/ci/README.md)
- [CI services (linked docker containers)](services/README.md)
- [**New CI build permissions model**](../user/project/new_ci_build_permissions_model.md) Read about what changed in GitLab 8.12 and how that affects your builds. There's a new way to access your submodules and LFS objects in builds.
- [**New CI build permissions model**](../user/project/new_ci_build_permissions_model.md) Read about what changed in GitLab 8.12 and how that affects your builds. There's a new way to access your Git submodules and LFS objects in builds.

32
doc/user/project/new_ci_build_permissions_model.md
View file

@ -49,9 +49,9 @@ It is important to note that we have a few types of users:
Administrator will have to be a member of it in order to have access to it
via another project's build.
- **External users**: CI builds created by external users will have access only
to projects to which user has at least reporter access. This rules out
accessing all internal projects by default,
- **External users**: CI builds created by [external users][ext] will have
access only to projects to which user has at least reporter access. This
rules out accessing all internal projects by default,
This allows us to make the CI and permission system more trustworthy.
Let's consider the following scenario:
@ -60,11 +60,10 @@ Let's consider the following scenario:
hosted in private repositories and you have multiple CI builds that make use
of these repositories.
2. You invite a new user, a visitor, the external user. CI builds created by
that user do not have access to internal repositories, because the user also
doesn't have the access from within GitLab. You as an employee have to grant
explicit access for this user. This allows us to prevent from accidental data
leakage.
2. You invite a new [external user][ext]. CI builds created by that user do not
have access to internal repositories, because the user also doesn't have the
access from within GitLab. You as an employee have to grant explicit access
for this user. This allows us to prevent from accidental data leakage.
## Build token
@ -99,6 +98,13 @@ As an Administrator, you can verify that the user is a member of the group or
project they're trying to have access to, and you can impersonate the user to
retry the failing build in order to verify that everything is correct.
## Build triggers
[Build triggers][triggers] do not support the new permission model.
They continue to use the old authentication mechanism where the CI build
can access only its own sources. We plan to remove that limitation in one of
the upcoming releases.
## Before GitLab 8.12
In versions before GitLab 8.12, all CI builds would use the CI Runner's token
@ -277,13 +283,7 @@ test:
- docker run $CI_REGISTRY/group/other-project:latest
```
### Build triggers
> **Note:**
Currently Build triggers do not support the new permission model.
They continue to use the old authentication mechanism where the CI build
can access only own sources. We plan to remove that limitation in one of the upcoming releases.
[git-scm]: https://git-scm.com/book/en/v2/Git-Tools-Submodules
[build permissions]: ../permissions.md#builds-permissions
[ext]: ../permissions.md#external-users
[triggers]: ../../ci/triggers/README.md