Skip to content

GitLab Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
gitlab-runner
gitlab-runner
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 2,042
    • Issues 2,042
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 204
    • Merge Requests 204
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • gitlab-runnergitlab-runner
  • Issues
  • #4421

Closed (moved)
Open
Opened Nov 27, 2015 by Laurens Stötzel@l.stoetzel

Feature Request: Allow runners to push via their CI token

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. ...?
Assignee
Assign to
Backlog
Milestone
Backlog
Assign milestone
Time tracking
None
Due date
None
Reference: gitlab-org/gitlab-runner#4421