BitBucket Server迁移GitLab失败：execution expired错误求助

可能的遗漏配置及排查点 #

• 超时时间限制
  GitLab导入过程默认有超时阈值，若BitBucket仓库包含大量历史提交、大文件，会触发超时。检查并调整GitLab相关配置：
  • 修改gitlab.rb中的gitlab_rails['import_export_timeout']（默认600秒），调大后执行gitlab-ctl reconfigure生效。
  • 若导入任务由Sidekiq处理，同步调整sidekiq['timeout']参数，确保时长覆盖完整导入流程。
• 网络连通性细节
  即便BitBucket API可访问，仍需确认GitLab服务器到BitBucket Server的双向网络延迟、防火墙/代理的超时拦截：
  • 在GitLab服务器上执行git clone http://13.37.65.138:7990/scm/test/test-repo.git，测试仓库克隆速度，若克隆缓慢则优化网络或拆分仓库。
  • 检查防火墙规则，确保GitLab与BitBucket之间的7990端口（BitBucket Server）及9418端口（Git协议）无超时限制。
• BitBucket Server API速率限制
  BitBucket Server默认有API请求速率限制，导入过程中频繁调用API可能触发限制导致超时。登录BitBucket后台，在「Settings > API Rate Limiting」中临时调高限制或禁用限制后重试。
• GitLab命名空间权限
  确保GitLab管理员账号拥有目标命名空间TEST的所有者权限，部分场景下管理员全局权限无法覆盖命名空间的细粒度权限限制。

解决方案步骤 #

1. 先验证仓库克隆可行性：在GitLab服务器上手动克隆BitBucket仓库，确认能成功完成，排除仓库本身或基础网络问题。
2. 调整GitLab超时配置：

   # /etc/gitlab/gitlab.rb
   gitlab_rails['import_export_timeout'] = 1800 # 调整为30分钟
   sidekiq['timeout'] = 1800
   

   执行gitlab-ctl reconfigure和gitlab-ctl restart sidekiq使配置生效。
3. 临时放宽BitBucket Server的API速率限制，重试导入操作。
4. 分阶段迁移（适用于大仓库）：
   • 手动克隆BitBucket仓库到本地，再推送到GitLab目标命名空间：

     git clone --mirror http://user1:<personalaccesstokenvalue>@13.37.65.138:7990/scm/test/test-repo.git
     cd test-repo.git
     git push --mirror http://<gitlab-admin-account>:<gitlab-token>@<gitlab-domain>/TEST/test-repo.git
     

   • 代码迁移完成后，再单独导入Issue、合并请求等非代码数据（若有需求）。

替代迁移方法 #

若上述方案无效，可采用git bundle打包迁移：

1. 在BitBucket Server所在环境打包仓库：

   git bundle create test-repo.bundle --all
   

2. 将bundle文件传输到GitLab服务器，执行导入：

   git clone test-repo.bundle
   cd test-repo
   git remote add gitlab http://<gitlab-admin-account>:<gitlab-token>@<gitlab-domain>/TEST/test-repo.git
   git push --mirror gitlab
   

内容的提问来源于stack exchange，提问作者Vishal Kharde