-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Centralize git cli operations #4106
Conversation
1aa6885
to
310ea33
Compare
Is the idea to also port https://github.com/docker/buildx/tree/master/util/gitutil in BuildKit? |
@crazy-max I'd like to take as much as is reasonable. I don't think we should take the gitpath WSL stuff, since that doesn't make much sense to me for use in BuildKit, or the testutils. But otherwise, I think we should take the other helpers? We should take as much as possible, but I want to avoid having any buildx-specific stuff in BuildKit as much as is possible, so we might need to leave some stuff downstream. |
Sounds good! |
3d2370c
to
6cc6832
Compare
For now, I've just got |
36cc47b
to
96097aa
Compare
@@ -578,7 +586,7 @@ func setupGitRepo(t *testing.T) gitRepoFixture { | |||
"echo sbb > foo13", | |||
"git add foo13", | |||
"git commit -m third", | |||
"git tag lightweight-tag", | |||
"git tag --no-sign lightweight-tag", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it to skip GPG sign to suppress warning?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, this was from https://github.com/moby/buildkit/pull/3960/files#diff-a7d654e4edba8b86b4853225da6c0e915b401becf96b20c380ac7105c3850610R585 - I don't think this needs to change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I added this because I was running the tests directly on my machine which has various things integrated with git
for commit signing and such. Feel free to remove it if you only care about running the tests in a container.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aha, this is a good call IMO, I'll split this to a separate commit 🎉
96097aa
to
6d5b061
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this worth 300 extra lines?
Another issue is that while the previous code is "secure by default" then now, because it is in reusable package, caller needs to configure it properly every time which is more error-prone. Eg. runWithUmask
is now in multiple places where previously it was just impossible to not have umask on. If it is forgotten in one caller then it is a bug that is very hard to track down. Is there a user for the new package? If not then can we take this code, make it private and maybe remove the umask/streams etc configuration. Or alternatively, if we want to keep the package make sure that source/git
only makes its calls through helper functions so there is only one configuration to gitutil.
dba10ef
to
ecd43b0
Compare
I'd argue definitely yes - keep in mind, that a lot of these lines are adding the verbose For example, _, err := gitWithinDir(ctx, dir, "", "", "", auth, "remote", "add", "origin", remote) becomes git := gitCLI(
gitutil.WithGitDir(dir),
gitutil.WithArgs(authArgs...),
)
_, err := git.Run(ctx, "remote", "add", "origin", remote) Yes, this is longer, but I think it's much clearer and more readable - given the security sensitivity of this code as you point out, I think it's better to be more explicit here. The previous collection of all the args as unnamed parameters is hard to read and track. In writing new code, and reviewing code, it would be easy to switch the work tree and git directories, or to pass accidental values into the known hosts. The options add some bloat - we could just use a
See docker/buildx#2005 (not up-to-date with the latest changes I've made here, but it's a working demo). It doesn't make sense that we have split logic for calling into git, and we have to duplicate helpers, etc. However, if we want to keep it private - I could be persuaded. My original idea was to have a reusable git helper that I could use both in the client and on the server to be able to do some context transfer related changes - but I'm not as interested in this anymore, so I have less need for the helper.
I've updated to do this. |
ecd43b0
to
4e60b1d
Compare
I have not dug into the changes; just a quick question:
I love functional arguments, but for some case like above, details may matter, so just double-checking if they are taken into account (again for the security angle of things) |
I don't think so. Maybe the
No dependents, each option just sets a single property - there's no intersection. The last applied option takes precedence, which allows overriding it later. |
Thanks! I'll step out of the discussion beyond that 😂 as I'm not familiar in-depth with this. |
4e60b1d
to
319130d
Compare
Move all of the git command line logic into a single object, inspired by the object already in buildx. The basic implemenation allows for configuring a git cli for a specific repository, along with various authorization settings and custom binaries. Commands can be run for that repository, and a few helpers are provided for accessing data on it - more to come in the future hopefully. Signed-off-by: Justin Chadwell <me@jedevc.com>
Co-authored-by: Alex Suraci <suraci.alex@gmail.com> Signed-off-by: Justin Chadwell <me@jedevc.com>
@@ -528,49 +504,50 @@ func (gs *gitSourceHandler) Snapshot(ctx context.Context, g session.Group) (out | |||
if err := os.MkdirAll(checkoutDir, 0711); err != nil { | |||
return nil, err | |||
} | |||
_, err = gitWithinDir(ctx, checkoutDirGit, "", sock, knownHosts, nil, "-c", "init.defaultBranch=master", "init") | |||
checkoutGit := git.New(gitutil.WithWorkTree(checkoutDir), gitutil.WithGitDir(checkoutDirGit)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🙈
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm understanding correctly, the simplest fix for #5066 is including gitutil.WithExec(runWithStandardUmask)
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... I guess all instances of WithWorkTree
in this file technically need/should have it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tianon Yes, assuming there isn't more cases like this.
But I think we need some refactoring here that would better guarantee such bugs not reappearing as described in as described in #4106 (review) and also make sure test can reliably cover it. cc @jedevc We can still take your patch as a quick mitigation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, we actually specify this option - the issue was is that we weren't correctly propagating it down to this level. Opened an alternative PR here that fixes the root cause: #5096.
Inspired by @vito's changes to the git operations in #3960 (comment)
Essentially, this helps to reduce the number of arguments to each call to git, and makes any changes less error-prone, and makes the whole thing more reusable. When this is merged, we can use it in buildx as well, where we already have a similar implementation in https://github.com/docker/buildx/blob/master/build/git.go (since docker/buildx#1297).
At the moment, this just has the basic
Run
operation, but I'm wondering if we want to add more utilities, as in the buildx implementation? I'll have a look and try and put together a list of utilities to include.