GitLab Next

Currently the CI has no good possibility to push changes back to the repository (see gitlab-org/gitlab-ci#105). Developers have to create separate accounts or SSH keys and make them available to the CI. Those credentials are available to everyone with read access to the repository (guests) or are shared to other projects using the same runner.

Probably not every build process and user should be allowed to push, so I have two proposals:

Proposal A:

In project settings, allow masters to define, whether or not a build process in this project may push. If allowed, the generated token gets write access ONLY to the branch, which triggered the build originally.

Example:

Bob can push to his feature branch and triggers a build, which will push changes back to his feature branch. The build process cannot push to master, as it is marked as protected.

Proposal B:

Impersonate/copy the developers rights to the temporary CI token. This way a build with access to a protected branch will fail if the user does not have access to it. When run by eligible user the push/build will succeed.

Example:

Bob pushes to the master branch and triggers a build, which in the final step wants to push to several feature branches to keep them in sync. Bob has developer access and the feature branches are marked as protected. This build will fail.

Alice has master access to this project. She restarts the failed build and the protected feature branches will be pushed.

Possible problems:

1. Pushes can trigger new CI builds and thus lead to infinite loops. Triggering new builds may be or may be not desired in every use-case.
2. ...?