Bitbucket importer should remove failed repositories
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Update
#23905 (closed) fixed the problem for BitBucket Cloud as the user can re-import the project by providing a non-existing path to the new project.
However, the retry mechanism doesn't work for BitBucket Server as differently from the other importers, BitBucket Server doesn't override the project source path, and because of that, it tries to create the new project using the same path used in the first import.
To fix the problem and to keep the behavior consistent with the other importers, we should use the provided new path (input field highlighted in the image below) as the new project path and name. So, the user can provide a distinct new project name/path.
We should also apply the same fix for the Bitbucket Server Import API
Summary
When importing Bitbucket projects and they fail, the repository created in Gitlab is not removed, and the import status page reports "failed" without giving an option to retry. One has to first remove the failed repository and then try again.
The issue is, when you have several failed repositories, you need to go and delete them one by one, which is extremely cumbersome, because there is no bulk-delete and deleting each repository requires several clicks:
- Go to the repository
- Settings / General
- Advanced
- Delete Project
- <enter project name>
All this would be avoided if the failed imports were cleaned up. Why would one want to keep them anyway?
Steps to reproduce
- select 20+ repositories from Bitbucket import
- start their imports concurrently
- normally, the Bitbucket server will refuse some of them, stating that the server is too busy
- be left with several failed gitlab repositories, that you need to delete one by one as described above:
What is the current bug behavior?
Failed imports are left behind, one needs to delete them one by one
What is the expected correct behavior?
Either remove all the failed imports, or allow the interface to "retry" (which under the hood removes the failed repository and then tries again)
Results of GitLab environment info
Gitlab 13.11.1-ee, docker container
Expand for output related to GitLab environment info
System information System: Proxy: no Current User: git Using RVM: no Ruby Version: 2.7.2p137 Gem Version: 3.1.4 Bundler Version:2.1.4 Rake Version: 13.0.3 Redis Version: 6.0.10 Git Version: 2.31.1 Sidekiq Version:5.2.9 Go Version: unknown GitLab information Version: 13.11.1-ee Revision: 557bbaae5b1 Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 12.6 URL: https://gitlab.spinque.com HTTP Clone URL: https://gitlab.spinque.com/some-group/some-project.git SSH Clone URL: git@gitlab.spinque.com:some-group/some-project.git Elasticsearch: no Geo: no Using LDAP: yes Using Omniauth: yes Omniauth Providers: GitLab Shell Version: 13.17.0 Repository storage paths: - default: /var/opt/gitlab/git-data/repositories GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell Git: /opt/gitlab/embedded/bin/git