fatal: unable to access 'https://github.com/': Could not resolve host" - private git dependency during pip install in...

TL;DR: The CI runner cannot resolve the git host's name, so the git clone inside pip install fails before credentials ever come into play. Fix the runner's DNS or network egress rules first. Only then sort out authentication for the private repo with a deploy key or credential helper, never by pasting secrets into requirements files.

fatal: unable to access 'https://github.com/': Could not resolve host

1. Reproduce the DNS failure on the runner itself: nslookup github.com or getent hosts github.com. Expected: the lookup fails, confirming this is DNS and not a git or pip problem.

2. Check the CI runner's egress and firewall rules for outbound HTTPS to the git host. Expected: you find whether traffic is blocked or needs an allowlist entry, and you open it.

3. If the organization routes traffic through a proxy, verify the proxy variables (HTTPS_PROXY and friends) are set in the CI environment. Expected: curl to the git host through the proxy succeeds; git and pip both honor these variables.

4. Once DNS works, authenticate to the private repo: use an SSH deploy key with the SSH clone URL, or supply a short-lived access token through the git credential helper. Expected: git ls-remote against the private repo succeeds without embedding secrets in the requirements file.

5. Re-run the pip install step. Expected: the private dependency clones and installs.

Use this when

• Pip installs a git-based dependency (git+https or git+ssh URL) and fails with the exact "Could not resolve host" message.
• The install works on your dev machine but fails in CI.
• The traceback shows git, not pip's package index, as the failing step.

Not for this skill when

• Git returns 401 or 403; DNS works fine and the credential is wrong or lacks repo scope.
• The error is "repository not found"; the URL or the token's permissions are wrong.
• Public PyPI installs time out; that is a package-index network issue, not git DNS.

Variant phrasings

• "pip install git+https could not resolve host github.com"
• "private git dependency pip install CI DNS failure"
• "fatal unable to access could not resolve host gitlab runner"
• "pip git dependency Could not resolve host in docker build"

Why it happens

pip shells out to git for git-based dependencies, and git must resolve the host name before anything else. CI runners often live in locked-down networks with custom DNS or egress allowlists where the git host is unreachable. Because resolution fails first, the error looks like a git problem when the real fix is network configuration; credentials only matter after DNS works.

Edge cases

• Prefer SSH deploy keys over HTTPS tokens where the runner supports SSH; keys are scoped to one repo and never appear in logs.
• Rotate any token that was ever pasted into a URL or log; assume it is compromised.
• Self-hosted runners with split-horizon DNS resolve internal git hosts differently than public ones; test from the runner, not your laptop.
• IPv6-only runners can fail against hosts with broken IPv6 records; forcing IPv4 in git config is a valid workaround.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_8nJFxW8jXLCnsp-COxqRQg