Skip to content
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

dockerfile (labs): implement ADD <git ref> #2799

Merged
merged 1 commit into from Aug 2, 2022

Conversation

AkihiroSuda
Copy link
Member

@AkihiroSuda AkihiroSuda commented Apr 12, 2022

e.g.,

# syntax=docker/dockerfile-upstream:master-labs
# ↑ Will be included in `syntax=docker/dockerfile:1.5-labs`
FROM alpine
ADD --keep-git-dir=true https://github.com/moby/buildkit.git#v0.10.1 /buildkit

Close #775

Expected to be used with:

Copy link
Member

@tonistiigi tonistiigi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AkihiroSuda Is this supposed to be still draft?

util/gitutil/git_ref_test.go Outdated Show resolved Hide resolved
util/gitutil/git_ref_test.go Outdated Show resolved Hide resolved
frontend/dockerfile/docs/syntax.md Outdated Show resolved Hide resolved
frontend/dockerfile/docs/syntax.md Outdated Show resolved Hide resolved
util/gitutil/git_ref_test.go Outdated Show resolved Hide resolved
```dockerfile
# syntax=docker/dockerfile:1.5
FROM alpine
ADD https://github.com/moby/buildkit.git#v0.10.1 /buildkit
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps a silly question; how does this relate to the named contexts that were added in docker/buildx#904 / docker/buildx#965 ? Mostly curious if some of these would make sense to be implemented as a "context".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the named contexts is a separate topic.
ADD instructions would be easier to use for typical users.

@thaJeztah
Copy link
Member

Somewhat orthogonal to this PR; I recently moved some code around in moby/moby, and improved some of the docs of the urlutil package;
https://github.com/moby/moby/blob/c5f18aac9f27ad88166ddfbec7822a2f1c6f0c20/builder/remotecontext/urlutil/urlutil.go#L24-L78

When working on those changes, I noticed that the "moby" variant (used by the classic builder) is hardcoded to master, and when I started implementing that, I saw that BuildKit had exactly the code I was about to write 😂.

If possible, I think we should try to unify those packages (moby/moby consuming it from BuildKit), however (need to look again to double-check) the BuildKit code was in a package that also imported llb, which made it difficult to consume it for the classic builder, but wondering if it would be possible to somehow split some of the code to make it consumable without that dependency.

if err != nil {
return errors.Wrapf(err, "failed to parse a git ref %q", src)
}
st := llb.Git(g.Repo, g.Commit, llb.KeepGitDir())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

KeepGitDir() default correct in here? On build context it is not default? I guess we could use a build-arg for this as well?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we could use a build-arg for this as well?

Should this be rather an flag for ADD instruction? e.g., ADD --keep-git-dir=(true|false) ....

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure. Don't like to add lots of very specific flags either.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While the git dir is not preserved for build contexts, I'd prefer to keep the git dir for the ADD instruction, as Makefiles often need git rev-parse, git describe, etc.

https://github.com/containerd/containerd/blob/8e74f2af0096a046ac004dc954105b010b9ee2d5/Makefile#L33

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we still do something for this that would allow have same defaults as context but opt-in to keep-git-dir. Maybe a convention on the URL, or a ARG definition before the command that controls this(or maybe a flag is fine)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a huge fan of complicating the URL microformat.
I also fear that adding an ARG like ARG KEEPGITDIR=true may conflict with user-defined ARG arguments.

Maybe ADD --keep-git-dir=(true|false) ... is the best?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tonistiigi SGTY? ↑

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is fine yes. In addition to plain keep-git we might need a way to configure the depth size as well in the future.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added --keep-git-dir. Defaults to false.

CreateDestPath: true,
}}, copyOpt...)
if a == nil {
a = llb.Copy(st, "/", dest, opts...)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should make sure that

FROM scratch
ADD git:// / (or .)

Is converted to direct llb.Git(), not llb.Scratch().File(llb.Copy(llb.Git(), "/", "/")) . Possibly this could be also optimized in the llb libarary.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to work on this in this PR or a separate PR?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be better in this PR. Separate commit is ok. If you want to do this in llb client level then it can be done in parallel on separate PR but we should avoid the possibility of having the git feature but not this optimization merged.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have that optimization for http sources?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added an optimizer in the second commit

frontend/dockerfile/dockerfile_test.go Outdated Show resolved Hide resolved
frontend/dockerfile/docs/syntax.md Outdated Show resolved Hide resolved
@AkihiroSuda AkihiroSuda force-pushed the dockerfile-add-git branch 5 times, most recently from ce2d58f to 1e14e51 Compare April 27, 2022 10:27
@AkihiroSuda AkihiroSuda marked this pull request as ready for review May 9, 2022 05:08
frontend/dockerfile/docs/syntax.md Outdated Show resolved Hide resolved
frontend/dockerfile/builder/build.go Outdated Show resolved Hide resolved
CreateDestPath: true,
}}, copyOpt...)
if a == nil {
a = llb.Copy(st, "/", dest, opts...)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be better in this PR. Separate commit is ok. If you want to do this in llb client level then it can be done in parallel on separate PR but we should avoid the possibility of having the git feature but not this optimization merged.

@AkihiroSuda AkihiroSuda force-pushed the dockerfile-add-git branch 3 times, most recently from e3e5765 to 2667f5a Compare May 30, 2022 08:44
@AkihiroSuda AkihiroSuda changed the title dockerfile: implement ADD <git ref> dockerfile: implement ADD <git ref> ; llb: add FileOp optimizer May 30, 2022
@AkihiroSuda
Copy link
Member Author

Rebased

@AkihiroSuda
Copy link
Member Author

@tonistiigi PTAL 🙏

Copy link
Member

@tonistiigi tonistiigi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for getting this PR stuck in the fileop+scratch optimization, but I don't like the FileOptimize public function at all. Split the second commit to another PR so we can get the main part merged.

For the optimization(follow-up), it should be either in Dockerfile or on always. Or if it is opt-in then optimization bool passed to Marshal.

Should we leave this in labs channel for one release to make sure we got the syntax right and commit to backwards compatibility then?

@AkihiroSuda AkihiroSuda changed the title dockerfile: implement ADD <git ref> ; llb: add FileOp optimizer dockerfile (labs): implement ADD <git ref> ; llb: add FileOp optimizer Aug 2, 2022
@AkihiroSuda
Copy link
Member Author

Sorry for getting this PR stuck in the fileop+scratch optimization, but I don't like the FileOptimize public function at all. Split the second commit to another PR so we can get the main part merged.

Removed the second commit from the PR.

Should we leave this in labs channel for one release to make sure we got the syntax right and commit to backwards compatibility then?

Yes, moved to the labs channel with dfaddgit tag

@AkihiroSuda AkihiroSuda changed the title dockerfile (labs): implement ADD <git ref> ; llb: add FileOp optimizer dockerfile (labs): implement ADD <git ref> Aug 2, 2022
e.g.,

  # syntax=docker/dockerfile-upstream:master-labs
  FROM alpine
  ADD https://github.com/moby/buildkit.git#v0.10.1 /buildkit

Close issue 775

Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
@tonistiigi tonistiigi merged commit 28817fc into moby:master Aug 2, 2022
@Talv
Copy link

Talv commented Oct 7, 2022

What's the syntax to get it to clone a repo via SSH on non-default port? Or is it even possible with current implementation? @AkihiroSuda @tonistiigi

ADD ssh://git@gitlab.localhost:10022/path/repo.git /src doesn't work - it attempts to use HTTPS...

------
 > git://gitlab.localhost/10022/path/repo.git#master:
#0 0.243 fatal: unable to access 'https://ssh://git@gitlab.localhost:10022/path/repo.git/': Could not resolve host: ssh
------
failed to solve: failed to load cache key: failed to fetch remote https://ssh://git@gitlab.localhost:10022/path/repo.git: exit status 128

@AkihiroSuda
Copy link
Member Author

AkihiroSuda commented Oct 7, 2022

@Talv Please try ADD git@HOST:REPO.git /src

@Talv
Copy link

Talv commented Oct 8, 2022

@Talv Please try ADD git@HOST:REPO.git /src

Well, there's no port in your example, which is what I'm getting at.

Here's what I've tried besides the first example:

# ADD git@gitlab.localhost:10022/path/repo.git#master /src
#  > git://gitlab.localhost/10022/path/repo.git#master:
# #0 129.5 ssh: connect to host gitlab.localhost port 22: Connection timed out

With the short syntax - git@, where ssh is implied - it ignores the port and treats it as a path which is valid according to the specs [1], but not what I want here...

# ADD git://gitlab.localhost:10022/path/repo.git#master /src
#  > git://gitlab.localhost:10022/path/repo.git#master:
#0 0.235 fatal: protocol error: bad line length character: SSH-

With git:// I was able to customize the port of a host, however it establishes the connection via git protocol which is different from ssh, so it fails (correct behavior).

So my issue here is not being able to specify an ssh port other than default (22). Using git cli it's only possible using the full syntax with ssh://, and as seen in my previous post it doesn't work, because docker seems to default to https:// on anything unknown.

[1] https://git-scm.com/docs/git-clone#_git_urls

@AkihiroSuda
Copy link
Member Author

Workaround: create .ssh/config
https://stackoverflow.com/questions/5767850/git-on-custom-ssh-port

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

dockerfile2llb: support ADD git:// with git source op
5 participants