jonasmalacofilho
Clone as fallback is not working if fetch fails on non-first-clone jobs
If I'm reading the code correctly, there is an assumption that git fetch can only fail if the target directory is missing, i.e. this is first-clone time. However, should fetch fail for whatever reason while the target directory exists (e.g. wrong credentials), it is not deleted to make room for a clone.
That's true. Though I'm not sure if the cache (target) directory should be deleted.
I think such a failure should be reported to the end user, as it's probably a network error or other non-recoverable problem (authentication has already succeeded for control flow to reach this point).
Does this make sense?
Yes, report it to the user and abort the request. The authentication problem has been two-fold until now: you have been authenticating to upstream with the credentials you've got via the request, but actually fetched newest revisions with the credentials saved in .git/config. This shouldn't be the case anymore with my patch for #7, but there might be some edge cases which are not covered.
Either way: error message and abort should be good enough.