I setup fresh gitlab docker , then set up a runner docker with docer executer based on microsoft/dotnet:latest then I added simple project to gitlab just a dotnet core hello world then I create a ci file as below:
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"
then in pipleline I get this output:
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
I searched error but all asnwers are about projects which have branches, but I dont have any branch, just a simple hello world project.
The OP ali-kamrani adds in the comments:
my issue was in ssh
configin runner docker: after adding the ssh key to docker, the issue is solved.
Other avenues (for other users) if this is similar to gitlab-org/gitlab issue 36123
We were using
git push --mirrorto mirror some projects from a different repository regularly.
As it turns out, it also deletes unknown branches, i.e.pipelines/XXXXandmerge/XXXX.We are now pushing & deleting every branch explicitly and ignoring all
pipelines/XXXXandmerge/XXXXones.
Afterwards the error didn't occur again.
I understand you don't have many branches, but the issue here is not with your local branches.
It is with a push operation, initiated locally, pruning remote branches which does not exist locally.
Basically, pipelines are depending on a pipeline specific ref
refs/pipelines/*and it has to exist when the pipeline is running.
So ifgit push --mirrordeletes these refs, you might encounter the job failure.
The same issue illustrates a similar scenario:
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With