Kerberized Gitlab is incompatible with Gitlab CI

The only protocol GitLab CI is using to clone a repository (rather tells a worker to do so) is http[s] with explicitly specified credentials in the URL--constant user name gitlab-ci-token and the token as password.

When GitLab is configured to use Kerberos, Git will try SPNEGO authorization. Since gitlab-ci-token is not a valid realm user (and even if it is, it's password is different from the token), authentication fails. The promised "fallback" feature in Git does not apply to this case, as the code that retries without GSSAPI is never reached when both username and password are explicitly specified. So, in Kerberized GitLab, all Git access is with Kerberos identities only.

This does not play well with GitLab CI: CI workers are unable to do a Git fetch at all!

I see two, not necessarily mutually exclusive, options here:

1. An option to use ssh instead of http URLs for workers (like git@gitlab:user/repo.git). In this case, a worker setup would include a registration of an SSH key in a "regular" (not LDAP or Kerb) GitLab account. Token ignored. Easy enough even for a farm of workers, sharing a key.

2. An option to omit the auth information from the http[s] URL. This works in-line with Kerberos, but setting up worker identities becomes much more troublesome (certainly in a Windows domain environment). In fact, a great solution would be to run the workers under a machine account that does not require a password, but setting up these identities in GitLab is impossible in a normal way because they have no password and cannot log on. They have to be created programmatically. Myself, I would prefer the first option for our set up for its relative simplicity, but other people may have different requirements, and allowing both options does not seem more troublesome than allowing either.