GitLab CI "fatal: unable to access" - Runner Repo Clone/Fetch Fails

Before your script runs, the runner clones or fetches the repository. A DNS hiccup, a proxy issue, or a transient GitLab outage makes that fetch fail with a git access error.

What this error means

The job fails in the "Getting source from Git repository" step with "fatal: unable to access" or "could not resolve host". Your script never runs because the workspace was never populated.

Job log

Getting source from Git repository
fatal: unable to access 'https://gitlab.example.com/group/repo.git/':
Could not resolve host: gitlab.example.com

Common causes

Transient DNS or network failure

A momentary DNS resolution or connectivity blip from the runner to GitLab fails the clone. It is environmental and usually clears on its own.

Proxy or TLS misconfiguration

A runner behind a proxy without the right env vars, or missing the GitLab CA, cannot reach the repo host over HTTPS.

Shallow-clone / GIT_STRATEGY contention

A very low GIT_DEPTH against a force-pushed ref, or a corrupted cached clone on the runner, can make the fetch fail until the workspace is reset.

How to fix it

Retry transient clone failures

Scope an automatic retry to runner/infra failures so a transient clone blip self-heals.

.gitlab-ci.yml

default:
  retry:
    max: 2
    when:
      - runner_system_failure
      - stuck_or_timeout_failure

Fix proxy/TLS and clone strategy

Set proxy env vars and the GitLab CA on the runner if it is behind a proxy.
From the runner host, curl -I https://gitlab.example.com to prove reachability.
If a cached clone is corrupt, set GIT_STRATEGY: clone to force a fresh checkout.

How to prevent it

Add retry: when: [runner_system_failure, stuck_or_timeout_failure] for clone resilience.
Keep runner proxy and CA configuration current.
Use a reasonable GIT_DEPTH and fresh clones on flaky workspaces.