-
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
dockerfile (labs): implement ADD <git ref>
#2799
Conversation
32ab7ed
to
ca8d552
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.
@AkihiroSuda Is this supposed to be still draft?
ca8d552
to
c12674f
Compare
frontend/dockerfile/docs/syntax.md
Outdated
```dockerfile | ||
# syntax=docker/dockerfile:1.5 | ||
FROM alpine | ||
ADD https://github.com/moby/buildkit.git#v0.10.1 /buildkit |
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.
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".
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 think the named contexts is a separate topic.
ADD
instructions would be easier to use for typical users.
Somewhat orthogonal to this PR; I recently moved some code around in moby/moby, and improved some of the docs of the When working on those changes, I noticed that the "moby" variant (used by the classic builder) is hardcoded to 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 |
if err != nil { | ||
return errors.Wrapf(err, "failed to parse a git ref %q", src) | ||
} | ||
st := llb.Git(g.Repo, g.Commit, llb.KeepGitDir()) |
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.
KeepGitDir()
default correct in here? On build context it is not default? I guess we could use a build-arg for this as well?
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 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) ...
.
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'm not sure. Don't like to add lots of very specific flags either.
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.
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.
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.
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)?
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.
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?
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.
@tonistiigi SGTY? ↑
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 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.
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.
Added --keep-git-dir
. Defaults to false.
CreateDestPath: true, | ||
}}, copyOpt...) | ||
if a == nil { | ||
a = llb.Copy(st, "/", dest, opts...) |
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.
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.
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.
Do we need to work on this in this PR or a separate PR?
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.
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.
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.
Do we have that optimization for http
sources?
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.
Added an optimizer in the second commit
ce2d58f
to
1e14e51
Compare
1e14e51
to
9fe2edb
Compare
CreateDestPath: true, | ||
}}, copyOpt...) | ||
if a == nil { | ||
a = llb.Copy(st, "/", dest, opts...) |
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.
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.
e3e5765
to
2667f5a
Compare
ADD <git ref>
ADD <git ref>
; llb: add FileOp optimizer
2667f5a
to
0ae20b2
Compare
bd4048c
to
0365e67
Compare
0365e67
to
192be4c
Compare
192be4c
to
3734ca1
Compare
Rebased |
@tonistiigi PTAL 🙏 |
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.
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?
3734ca1
to
784a780
Compare
ADD <git ref>
; llb: add FileOp optimizerADD <git ref>
; llb: add FileOp optimizer
Removed the second commit from the PR.
Yes, moved to the |
ADD <git ref>
; llb: add FileOp optimizerADD <git ref>
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 <[email protected]>
784a780
to
8bfeafa
Compare
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
|
@Talv Please try |
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:
With the short syntax -
With So my issue here is not being able to specify an ssh port other than default (22). Using |
Workaround: create .ssh/config |
e.g.,
Close #775
Expected to be used with: