docker / docker/buildx

Git remote context should respect system git config

Open
#2,655 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

kind/enhancement status/stale status/triage
Dominant language
Go
Stars
4.5k
Forks
682
Avg merge
2d 14h
Merged PRs (30d)
29

Description

Description

This is somewhere between a bug, feature request, and just discussion... in short, it seems intuitive that a git repo remote context for build/bake should respect any Git configuration present in the context of the command, but it does not.

"Bug," sort of:

I'm specifically thinking about a url.insteadOf rule in ~/.gitconfig, such as to remap SSH Git URLs to equivalent HTTPS+auth URLs (see a gist with specifics of how this would work, e.g. for CI). It seems ideal to leverage GIT_AUTH_TOKEN/BUILDX_BAKE_GIT_AUTH_TOKEN in such cases, but the missing piece is support for handling the same remote context URL in SSH-authenticated environments and HTTP-authenticated environments, by those environments' configurations.

I'm using this as a workaround (again see gist for more), but feel a bit gross about it: sed -i "s|git@gitlab.com:|https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/|" [bake file]

"Feature request," sort of:

While the case I outlined above is focused on the url.insteadOf case, I could imagine others where the host git config would be useful (maybe core.sshCommand). The ideal feature here IMO would leverage any present git config as any standalone git client would whenever resolving a git repo remote build context.

Perhaps it would just be necessary to leverage git_cli as part of relevant functions like ParseGitRef?

"Discussion," sort of:

On the other hand, the dir URL fragment syntax means that git remote build contexts aren't exactly like normal git URLs, so maybe it would add confusion to even leverage git config rules? Cases like this could be easier, but other, stranger unexpected behaviors could arise. Instead, maybe just a bit of docs clarification should specify how these URLs are handled (i.e. not quite like equivalent git clones), to save folks from going down this rabbit hole?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with util/gitutil/git_cli.go and util/gitutil/git_ref.go, especially ParseGitRef, then compare current remote-context handling with standalone Git configuration behavior. Review the linked BuildKit and Git documentation to determine whether support or documentation is intended; done requires a clear decision on the expected URL and authentication semantics.

Written by the indexing model from the issue text.

Assessment

Tech stack
git, go
Domain
build-system, cli
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.