Problem you have encountered:

pip install from GAR index does not allow any caching within pip. The behavior of GAR Python Repositories prevents pip from caching any responses from GAR's Python Index.

What you expected to happen:

pip install should pull from the GAR index the first time, subsequent calls should allow pip cache to pull from its prior local cache. It currently does not due to GAR returning 307 to returned packages.

Steps to reproduce:

1. Create Python repository in GAR (Virtual/Standard/Remote does not matter)
2. pip install -vv from that index

Given no hashes to check 17 links for project 'bump2version': discarding no candidates
Collecting bump2version
  Created temporary directory: /tmp/pip-unpack-kme95ke5
  Looking up "https://us-central1-python.pkg.dev/--/--/bump2version/bump2version-1.0.1-py2.py3-none-any.whl" in the cache
  No cache entry available
  https://us-central1-python.pkg.dev:443 "GET /--/--/bump2version/bump2version-1.0.1-py2.py3-none-any.whl HTTP/1.1" 307 0
  Status code 307 not in (200, 203, 300, 301, 308)
  Looking up "https://us-central1-python.pkg.dev/artifacts-downloads/namespaces/--/repositories/--/downloads/..._s=" in the cache
  No cache entry available
  https://us-central1-python.pkg.dev:443 "GET /artifacts-downloads/namespaces/--/repositories/--/downloads/..._s= HTTP/1.1" 200 22030
  Downloading https://us-central1-python.pkg.dev/--/--/bump2version/bump2version-1.0.1-py2.py3-none-any.whl (22 kB)
  Updating cache with response from "https://us-central1-python.pkg.dev/artifacts-downloads/namespaces/--/repositories/--/downloads/..._s="
  Caching b/c of expires header. expires in 0 seconds
  Added bump2version from https://us-central1-python.pkg.dev/--/--/bump2version/bump2version-1.0.1-py2.py3-none-any.whl (from -r requirements.txt (line 3)) to build tracker '/tmp/pip-build-tracker-pm3nfa83'
  Removed bump2version from https://us-central1-python.pkg.dev/--/--/bump2version/bump2version-1.0.1-py2.py3-none-any.whl (from -r requirements.txt (line 3)) from build tracker '/tmp/pip-build-tracker-pm3nfa83'

Other information (workarounds you have tried, documentation consulted, etc):

Open Pip issue https://github.com/pypa/pip/issues/10694

No other google documentation available

This affects all pip installs, not just from CI. Pip's cachecontrol only considers (200, 203, 300, 301, 308) as cacheable status codes. In that issue, there's a response from a Microsft Dev from Azure that states that Azure's GAR equivalent has the same issue.

Breaking local pip cache completely while using private indexes really prevents us from using GAR, and we might end up using a different product completely.