Deleting project with deploy key makes deploy key unusable for new projects

Summary

When adding a deploy key to a project (Project -> Settings -> Repository) and then deleting that project (including the deploy key), I am no longer able to use the same deploy key for new/other projects.

Steps to reproduce

  1. Create a new project and assign a newly generated deploy key
  2. (Verify that git clone is working)
  3. Delete the project
  4. Create a new project and add the same deploy key used previously
  5. Attempt to clone the repo

What is the current bug behavior?

I am not able to access the repo using the deploy key that is added to the project. When doing a git clone I get this error:

$ git clone git@<url>
Cloning into 'myproj'...
GitLab: The project you were looking for could not be found.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I am, however, able to authenticate against the git server using plain SSH:

$ ssh -T git@<url>
Welcome to GitLab, Anonymous!

Also, if I first remove the deploy key before deleting the project the bug does not occur.

What is the expected correct behavior?

When I delete a project I expect any associated deploy keys to be deleted as well (if only in use by that project). I expect to be able to re-use the same deploy key for another project.

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.0
Revision:       8f82e53
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/252 ... ok
202/318 ... repository is empty
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/252 ... yes
202/318 ... 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

It seems that not all references to the deploy key are deleted/cleaned up when deleting the project as Gitlab is refusing new projects from using it.

Edited by Sindre Paulsrud Moe