Skip to content

Deploy keys added via API do not trigger CI

Summary

Deploy keys added via the API have no user associated with them and consequently do not trigger CI pipelines.

Steps to reproduce

  1. Create a project with a working GitLab CI configuration. Verify that regular pushes creates a new pipeline.
  2. Add a deploy key via the deploy keys API.
  3. Push to the repository using the previously added deploy key.
  4. Note that no pipeline is created as a result of the push.

What is the current bug behavior?

No pipeline is created as a result of the push with the deploy key.

What is the expected correct behavior?

A pipeline is create when a push is performed using a deploy key.

Relevant logs and/or screenshots

Example output from gitlab-rails/githost.log indicating that no user is associated with the push by the deploy key,

September 01, 2017 16:10 -> ERROR -> POST-RECEIVE: Triggered hook for non-existing user "key-380"

Results of GitLab environment info

System information
System:         CentOS 6.9
Proxy:          no
Current User:   git
Using RVM:      no
Ruby Version:   2.3.3p222
Gem Version:    2.6.6
Bundler Version:1.13.7
Rake Version:   10.5.0
Redis Version:  3.2.5
Git Version:    2.13.4
Sidekiq Version:5.0.0
Go Version:     unknown

GitLab information
Version:        9.4.4-ee
Revision:       c7bc62c
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     postgresql
DB Version:     9.6.3
URL:            ~REMOVED~
HTTP Clone URL: ~REMOVED~
SSH Clone URL:  ~REMOVED~
Elasticsearch:  no
Geo:            no
Using LDAP:     yes
Using Omniauth: no

GitLab Shell
Version:        5.3.1
Repository storage paths:
- default:      /var/opt/gitlab/git-data/repositories
Hooks:          /opt/gitlab/embedded/service/gitlab-shell/hooks
Git:            /opt/gitlab/embedded/bin/git

Results of GitLab application Check

We're running a in a corporate environment and I don't feel comfortable including this information without first seeking approval. Please let me know if it will be required.

It seems to have passed based on the output.

Possible fixes

I believe including current_user in the parameters given to DeployKeys.new would address this (see https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/api/deploy_keys.rb#L71).

If this is undesirable there would also be the option of allowing GitTagPushService to be triggered for deploy keys not associated with a user.