docker - gitlab 中基本 ci 实现错误致命 : couldn't find remote ref

Question

我设置了新的 gitlab docker ，然后基于 microsoft/dotnet:latest 设置了一个带有 docer 执行器的 runner docker
然后我向 gitlab 添加了一个简单的项目，只是一个 dotnet core hello world
然后我创建一个 ci 文件如下:

image:  microsoft/dotnet:latest

stages:
  - build


variables:
  project: "ConsoleApp"

before_script:
  - "dotnet restore"

build:
  stage: build
  variables:
    build_path: "$ConsoleApp"
  script:
    - "cd $build_path"
    - "dotnet build"

然后在管道中我得到这个输出:

Preparing environment
 Running on runner-vtysysr-project-2-concurrent-0 via e189cc9d1c60...
Getting source from Git repository
00:07
 Fetching changes with git depth set to 50...
 Reinitialized existing Git repository in /builds/root/gitlabcitest/.git/
 fatal: couldn't find remote ref refs/pipelines/18
Uploading artifacts for failed job
00:06
 ERROR: Job failed: exit code 1

我搜索了错误，但所有答案都是关于有分支的项目，但我没有任何分支，只是一个简单的 hello world 项目。

Answer 1

OP ali-kamrani加入 the comments :

my issue was in ssh config in runner docker: after adding the ssh key to docker, the issue is solved.

其他途径(针对其他用户)，如果这类似于 gitlab-org/gitlab issue 36123

We were using git push --mirror to mirror some projects from a different repository regularly.
As it turns out, it also deletes unknown branches, i.e. pipelines/XXXX and merge/XXXX.

We are now pushing & deleting every branch explicitly and ignoring all pipelines/XXXX and merge/XXXX ones.
Afterwards the error didn't occur again.

我知道你没有很多分支机构，但这里的问题不在于你本地的分支机构。
它带有一个推送操作，在本地启动，修剪本地不存在的远程分支。

Basically, pipelines are depending on a pipeline specific ref refs/pipelines/* and it has to exist when the pipeline is running.
So if git push --mirror deletes these refs, you might encounter the job failure.

同样的问题说明了一个类似的场景:

In our setup, we are using a system hook to mirror our GitLab repositories into another location closer to where our GitLab Runner instances are.
This has worked fine for a long time.

However, now that GitLab is dependent on the refs/pipelines/<pipeline ID> ref existing, all of our runners fail.

The problem is that the refs/pipelines/<pipeline ID> ref gets created behind the scenes and there is no system hook that gets invoked (so we don't know about the new ref that needs to be mirrored).
The built-in Repository Mirroring feature isn't very suitable for us because it must be configured for each repository; with System Hooks, we can automatically mirror all of our repositories.