Prior to Gitlab version 12.0, you could control whether your project did a “Fetch” or “Clone” when the pipeline job ran. This was controlled by the “GIT_STRATEGY”, which you could set in the pipeline script or set at the project settings level on the Pipeline Properties page. Apparently, this all changed when Gitlab-runner issue #3983 was implemented.
Now the runner will always do the following:
-
if clonedelete the project directory git initgit remote set-url origingit fetch origin origin --prune refspecs
This causes problems with any repository that is using Git filters that may execute git commands against commit history, such as “git describe”, “git log”, etc. Those calls will error out with…
fatal: Not a valid object name HEAD
fatal: your current branch ‘master’ does not have any commits yet
This appears to be due to the fact that the filters are triggered by the “git fetch” instead of a clone and none of the head references have been capture yet.
It seems that the Gitlab CI/CD documentation should change to indicate what Git commands the runner is actually doing rather than continue to state it performs a “clone” operation.
Also, I’m hoping someone that knows Git better than me can give me a hint as to how to change the “git log” command to find the Commit Author, Commit Date, Commit SHA for a file in the repo that will work with no HEAD or master branches references that I can use in my Git filter.