git-initializer component does not work with repos hosted on Azure DevOps

[krancour]

Thank you to @emilwangaa for reporting this.

This is due to libgit2/git2go#64

There's already been one attempt to fix this by switching to git2go, which is the official Go bindings for the libgit2 library. See #1939.

1939 had to be rolled back by #1950. See #1950 for further details.

I'm opening this issue so that we don't lose track of where we stand with this. There is a range of options for proceeding. I'd like to invite other maintainers and the community to weigh in:

1. State, even temporarily, that we're incompatible with Azure DevOps.
2. Wait for git-go to start supporting multi-ack: I see no evidence that this is in the works.
3. Wait for git2go to support the newest libgit2: There is an open issue for this at https://github.com/libgit2/git2go/issues/899.
   1. We can tentatively hack in support ourselves, but not until https://github.com/libgit2/libgit2/pull/6278 lands.
   2. Newer versions of libgit2 introduce permission issues ("by design") that may be troublesome for us, but are likely solvable. (It won't clone into directories you don't own -- even if you have permission to write to that location by virtue of group membership. That makes it difficult to run the git-initializer as a nonroot user -- because when Kubernetes mounts a volume to a pod, security context can make the mount location group writeable, but it's still owned by root. We can probably work around that by cloning to a temporary location and them moving the working tree to the volume in question. Running as root is out of the question because even if the danger is negligible in this case, too many people have security policies that forbid containers that run as root.)
4. Go back to scripting the git cli like we did in v1. This is not without its own complications:
   1. git-initializer image (for Linux) gets much bigger and will have more attackable surface, although the possible attack vectors should be negligible because the component runs only momentarily, executing commands we define, and doesn't listen for any inbound connections.
   2. Script may require different implementations for Linux and Windows (the git initializer needs to be able to run on either kind of node since Windows-based jobs are supported).
   3. Script will require third-party tools (like jq) for parsing JSON -- and again this may require different implementations for Linux and Windows.
5. Use either the old git-go-based implementation or the new git2go-based implementation, but shell out to the git CLI for the fetch. As with the previous option, this does mean larger images and more attackable surface, although the risk should be negligible.

Personally, I find 3 and 5 most appealing. 5 might be a good short-term fix, with 3 being a longer-term solution once all the required pieces fall into place.

[emilwangaa]

Good catch @krancour. Keep up the good work.

[krancour]

1952 solved this.