-
Notifications
You must be signed in to change notification settings - Fork 33
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
feat(import): copy folder contents #453
Conversation
^ at least this works with this PR. Evaluating what changes will be needed. |
d067a1a
to
7e5f826
Compare
208a909
to
6e339fe
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.
LGTM
- path: stacker://fourth/folder4/subfolder5/ | ||
dest: /folder6/ | ||
- path: stacker://fourth/folder4/ | ||
dest: /folder7/ |
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.
You are not testing an import of a 'stacker://' path without a trailing /.
You should add an import of:
- path: stacker://fourth/folder4
dest: /folder8
And then a test of
[ -d /folder8/folder4 ]
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.
The issue is if folder8 is present then [ -d /folder8/folder4 ] will evaluate to true else false. But let me add this test and see what happens.
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.
oh, yuck.
i think that 'target' (the full path to the imported thing) should be fully determined by the 'dest', and not dependent on either the 'path' or the contents of the filesystem to which it is being imported. At worst, target should be determined by 'path' and 'dest', rather than 'path', 'dest' and 'target-filesystem'.
that just seems the least surprising behavior to me.
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.
The added test failed. The trailing slash determines what the behavior is - a trailing slash means contents, else the folder itself, applies for path
and dest
independently
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.
Removed the test.
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.
a trailing slash means contents, else the folder itself,
that part makes sense.
applies for
path
anddest
independently
that I don't understand.
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.
As I understand from reading, a trailing '/' on a path that is a directory means that the contents of the provided path should be placed at 'dest', rather than inside of dest as 'dest/$(basename $path)'.
In #455 I suggested a different set of rules / behavior.
I think we should just not bother with the 'basename' behavior. It makes things much more clear.
The other behavior I think we should iron out is what happens when the 'dest' exists? Does it replace it or "fill" it?
Documenting https://docs.docker.com/engine/reference/builder/#add Looks like source's file mode is detected at build time from the filesystem and the dest file mode is inferred from trailing slash (and hence copying file to dir is an error, etc) [Source folder1 is a dir, Destination /folder1 doesn't exist]
[Source folder1 is a dir, Destination /folder1 already exists] Same as above [Source file1, Destination /file1 doesn't exist]
[Source file1, Destination /file1 already exists]
|
ADD definitely looks like a bunch of iterative behaviors. complete with behavior like:
Also, ADD seems to indicate add not "merge", and I really could be missing something in the long description of ADD's behavior, but I don't see what happens if I ADD directory 'foo' to /etc which already has 'foo'. Do the contents get merged somehow? As I can tell, that is "union" and I only see that term used wrt tar. if you want to use that as your reference of something to implement, and then attempt to keep your implementation bug-for-bug in sync with docker's then I guess its fine. I just think that it is more complex than required. |
Not yet sure what stacker does in all these scenarios to compare/contrast yet. Not one-on-one, but we are constrained by
|
It is a union. If the entry exists in the destination, it gets overwritten. |
d1b9614
to
c85b2fd
Compare
Codecov Report
@@ Coverage Diff @@
## main #453 +/- ##
==========================================
- Coverage 13.32% 13.05% -0.27%
==========================================
Files 40 40
Lines 5863 5982 +119
==========================================
Hits 781 781
- Misses 4954 5073 +119
Partials 128 128
... and 1 file with indirect coverage changes 📣 Codecov offers a browser extension for seamless coverage viewing on GitHub. Try it in Chrome or Firefox today! |
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 would like to see some tests that cover 'overlay/existing' behavior.
build:
from:
type: oci
url: $CENTOS_OCI
run: |
mkdir /output/
echo "my-ls" > /output/ls
touch /output/whizbang
assemble:
from:
type: oci
url: $CENTOS_OCI
import:
- path: stacker://build/output/
dest: /usr/
run: |
# existing file in /usr/bin should still be there
[ -f /usr/bin/env ]
# 'ls' should be updated.
read line < /usr/bin/ls
# whizbang should be present
[ -f /usr/bin/whizbang ]
if idest == "" || source[len(source)-1:] != "/" { | ||
err = c.Execute(append(bcmd, "cp", source, "/stacker/"+path.Base(source)), nil) | ||
} else { | ||
err = c.Execute(append(bcmd, "cp", source, "/stacker/"), nil) |
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.
it looks like you're not using 'idest' here at all.
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.
line #35
if idest == ""
test/convert.bats
Outdated
@@ -48,7 +48,6 @@ EOF | |||
} | |||
|
|||
@test "alpine" { | |||
skip_slow_test |
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.
was this set of changes intentional?
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.
was this set of changes intentional?
I see that this is part of "test - remove commit", so maybe remove that commit?
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.
Will do. Once I am convinced that stacker convert
tests are not broken with these changes.
tag: first | ||
run: | | ||
mkdir -p /folder1 | ||
touch /folder1/file1 |
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.
what does this do?
'second' comes from 'first', which has /folder1, so why create it (with mkdir) and then touch '/folder1/file1' which already exists. is that supposed to force a copy-up?
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.
Yup.
d081627
to
f0ed4d2
Compare
import: - path: folder1/ dest: / vs import: - path: folder1 dest: / The former will copy the contents of folder1/ at / and the latter will make and copy a /folder1 at / Signed-off-by: Ramkumar Chinchani <[email protected]>
import: - path: folder1 dest: /folder2 will cause contents of folder1 to show up as and under /folder2 Signed-off-by: Ramkumar Chinchani <[email protected]>
- path: folder1 | ||
dest: /folder2 | ||
run: | | ||
[ -f /folder2/file1 ] |
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.
This is unfortunate. Using rsync semantics:
serge@jerom ~/delme$ mkdir folder1
serge@jerom ~/delme$ touch folder1/file1
serge@jerom ~/delme$ rsync -va folder1 folder2
sending incremental file list
created directory folder2
folder1/
folder1/file1
sent 138 bytes received 69 bytes 414.00 bytes/sec
total size is 0 speedup is 0.00
serge@jerom ~/delme$ ls folder2
folder1
So let's make sure to have a very clear documentation for these semantics. Right now this testcase appears to be the clearest documentation.
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.
Mind you I think I like the behavior you have here better. I'm surprised by what rsync is doing.
So I'm not asking you to change it. Just document it :)
What type of PR is this?
Which issue does this PR fix:
What does this PR do / Why do we need it:
If an issue # is not available please add repro steps and logs showing the issue:
Testing done on this change:
Automation added to e2e:
Will this break upgrades or downgrades?
Does this PR introduce any user-facing change?:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.