Small fixes in CI build permissions docs

- Add link to external user
- Move build triggers up

doc/ci/README.md

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

doc/user/project/new_ci_build_permissions_model.md

@@ -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
+- **External users**: CI builds created by [external users][ext] will have
-  to projects to which user has at least reporter access. This rules out
+  access only to projects to which user has at least reporter access. This
-  accessing all internal projects by default,
+  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
+2. You invite a new [external user][ext]. CI builds created by that user do not
-   that user do not have access to internal repositories, because the user also
+   have access to internal repositories, because the user also doesn't have the
-   doesn't have the access from within GitLab. You as an employee have to grant
+   access from within GitLab. You as an employee have to grant explicit access
-   explicit access for this user. This allows us to prevent from accidental data
+   for this user. This allows us to prevent from accidental data leakage.
-   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