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
config
in 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 --mirror
to mirror some projects from a different repository regularly.
As it turns out, it also deletes unknown branches, i.e.pipelines/XXXX
andmerge/XXXX
.We are now pushing & deleting every branch explicitly and ignoring all
pipelines/XXXX
andmerge/XXXX
ones.
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 --mirror
deletes 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