Skip to content

[Critical] Deploy keys added through the API does not trigger CI (no user associated)

Note: this bug report has changed after the initial submission. Please see the comment below for the latest status.

Summary

When you create a new project via the API it is not 100% initialized, affecting git push and CI/CD does not work. This must be classified as a critical bug because it is affecting core functionality. I mainly use the API to interact with Gitlab in an automated fashion and I rely on this functionality to work.

Steps to reproduce

  1. Create a new project via the API: https://docs.gitlab.com/ce/api/projects.html#create-project-for-user

  2. Push a .gitlab-ci.yml file to the repo using SSH url (I am adding a deploy key via the API, but probably same behavior if using a SSH key that is associated with a user with access to the project).

  3. Check the project in the web interface. Gitlab CI/CD should have kicked in and launched a new Job, but nothing happens.

  4. Add a new commit and push just to check if it applies to the first commit only. Same problem. Nothing happens.

IMPORTANT: bug can only be seen when pushing with SSH key - not username/password (HTTPS). Neither does it apply if the project is created via the web UI.

What is the current bug behavior?

Files are added to the repo, but .gitlab-ci.yml is not recognized so CI/CD does not run. Also, nothing shows up under Overview -> Activity for the project (expected to see the pushes as usual).

No matter how many times I commit/push, it doesn't seem to help. For some reason the commit is not fully processed it seems. Only if I make a commit via the web UI or push via HTTPS, the CI/CD kicks in.

What is the expected correct behavior?

Projects created via the API should be 100% initialized and functional, meaning I should be able to git push via SSH and expect CI/CD to work as normal.

Results of GitLab environment info

Expand for output related to GitLab environment info 
System information
System:         Ubuntu 16.04
Current User:   git
Using RVM:      no
Ruby Version:   2.3.6p384
Gem Version:    2.6.13
Bundler Version:1.13.7
Rake Version:   12.3.0
Redis Version:  3.2.11
Git Version:    2.14.3
Sidekiq Version:5.0.5
Go Version:     unknown

GitLab information
Version:        10.6.4
Revision:       dee2c87
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     postgresql
URL:            https://git.appstrada.net
HTTP Clone URL: https://git.appstrada.net/some-group/some-project.git
SSH Clone URL:  git@git.appstrada.net:some-group/some-project.git
Using LDAP:     no
Using Omniauth: no


GitLab Shell
Version:        6.0.4
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

Expand for output related to the GitLab application check 
Checking GitLab Shell ...

GitLab Shell version >= 6.0.4 ? ... OK (6.0.4)
Repo base directory exists?
default... yes
Repo storage directories are symlinks?
default... no
Repo paths owned by git:root, or git:git?
default... yes
Repo paths access is drwxrws---?
default... yes
hooks directories in repos are links: ...
4/4 ... ok
4/5 ... repository is empty
5/9 ... ok
3/11 ... ok
4/77 ... ok
5/349 ... ok
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Redis available via internal API: OK


Access to /var/opt/gitlab/.ssh/authorized_keys: OK
gitlab-shell self-check successful


Checking GitLab Shell ... Finished


Checking Sidekiq ...


Running? ... yes
Number of Sidekiq processes ... 1


Checking Sidekiq ... Finished


Reply by email is disabled in config/gitlab.yml
Checking LDAP ...


LDAP is disabled in config/gitlab.yml


Checking LDAP ... Finished


Checking GitLab ...


Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...
4/4 ... yes
4/5 ... yes
5/9 ... yes
3/11 ... yes
4/77 ... yes
5/349 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.3.5 ? ... yes (2.3.6)
Git version >= 2.9.5 ? ... yes (2.14.3)
Git user has default SSH configuration? ... yes
Active users: ... 3


Checking GitLab ... Finished

Possible fixes

Have no idea, but it seems that some "hooks" are running only when the project is created via the web UI or the git push is done over HTTPS. When the project is created via the API and push is done via SSH it is not working correctly.

Edited by Sindre Paulsrud Moe