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

podman-remote build use .containerignore over .dockerignore #10913

Merged
merged 1 commit into from
Jul 15, 2021

Conversation

rhatdan
Copy link
Member

@rhatdan rhatdan commented Jul 12, 2021

$ mkdir zzz;cd zzz
$ printf "FROM quay.io/libpod/testimage:20210610\nCOPY ./ ./\nCOPY subdir ./\n" >Dockerfile
$ printf "\nsubdir\n!/sub1*\n" >.dockerignore
$ mkdir subdir; touch subdir/sub1.txt
$ ../bin/podman-remote build .

Should fail, but succeeds because we are not sending over the
.dockerignore file to the server side. This PR will send the
.dockerignore so the server side and use it.

Fixes: #10907

Also if both .containerignore and .dockerignore in the context
directory, podman-remote should prefer .containerignore and not use
.dockerignore.

Fixes: #10908

Signed-off-by: Daniel J Walsh [email protected]

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 12, 2021
@rhatdan
Copy link
Member Author

rhatdan commented Jul 12, 2021

@edsantiago PTAL

@rhatdan rhatdan force-pushed the build branch 2 times, most recently from d9f63eb to 3971357 Compare July 12, 2021 20:37
@rhatdan
Copy link
Member Author

rhatdan commented Jul 12, 2021

Fixes: #10908

@rhatdan rhatdan changed the title podman-remote build shouldn't exclude .dockerignore/.containerignore podman-remote build use .containerignore over .dockerignore Jul 12, 2021
@edsantiago
Copy link
Member

I don't think this solves the problem; it actually breaks in a different way. I'll update later, after f2f.

@edsantiago
Copy link
Member

Yes, this doesn't seem to fix anything. The fault is mine: I got lazy in writing the reproducer, and wrote something that probably didn't create the correct dockerignore file because of shell expansions. Try this for your dockerignore:

$ cat >zzz/.dockerignore <<EOF
*
subdir
!*/sub1*
EOF

With that file, podman build fails (as it should) but podman-remote build succeeds (bad, #10907)

@edsantiago
Copy link
Member

That seems to have done it, thanks. Passes on my laptop. New CI test run in progress

@edsantiago
Copy link
Member

LGTM! All dockerignore tests are now passing. (Failures are the usual stream-dropped bug, #10154)

@@ -887,4 +887,61 @@ function teardown() {
basic_teardown
}

@test "podman build .dockerignore failure test " {
Copy link
Member

Choose a reason for hiding this comment

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

Could you remove the trailing whitespace from this and all the other new tests?

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 sure what you mean?

Copy link
Member

Choose a reason for hiding this comment

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

Could you remove the space between failure test and the closing double-quote?

Also, still two unresolved bugs from my previous feedback; I'll repeat them


@test "podman build .containerignore and .dockerignore test " {
tmpdir=$PODMAN_TMPDIR/build-test
mkdir -p $subdir
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 you forgot:

    subdir=$tmpdir/subdir

Copy link
Member

Choose a reason for hiding this comment

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

^^

Copy link
Member

Choose a reason for hiding this comment

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

Again, this one seems to have slipped

is "$output" ".*test2" "test2 should exists in the DockerfileExpected to fail"
}

@test "podman build .containerignore and .dockerignore test " {
Copy link
Member

Choose a reason for hiding this comment

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

Could you give this test a unique name? (It's the same as line 909)

Copy link
Member Author

Choose a reason for hiding this comment

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

Removed since it was a duplicate of prior.

RUN ls /tmp/test/
EOF
run_podman build -t build_test $tmpdir
is "$output" ".*test2" "test2 should exists in the DockerfileExpected to fail"
Copy link
Member

Choose a reason for hiding this comment

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

Oops, hit Submit too soon. Also, should be 'exist' (no ess). And, I think the "Expected to fail" is a copy-paste error?

Copy link
Member Author

Choose a reason for hiding this comment

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

Fixed

RUN ls /tmp/test/
EOF
run_podman build -t build_test $tmpdir
is "$output" ".*test1" "test1 should exists in the DockerfileExpected to fail"
Copy link
Member

Choose a reason for hiding this comment

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

same thing (exist, Expected to fail)

Copy link
Member Author

Choose a reason for hiding this comment

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

Fixed

RUN ls /tmp/test/
EOF
run_podman build -t build_test $tmpdir
is "$output" ".*test1" "test1 should exists in the final image" "Confirm only .containerignore is used"
Copy link
Member

Choose a reason for hiding this comment

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

Too many arguments to is(): the last one ("Confirm only...") is ignored. Could you pick one or the other between that and "test1 should exist"?

@TomSweeneyRedHat
Copy link
Member

All kinds of red test unhappiness @rhatdan

@edsantiago
Copy link
Member

oh, you fixed them

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jul 14, 2021

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: edsantiago, rhatdan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@edsantiago
Copy link
Member

Looks like the podman-remote error is different:

#| expected: '.*Error: error building at STEP "COPY subdir ./": no items matching glob'
#|   actual:   'Error: error building at STEP "COPY subdir ./": checking on sources under "/var/tmp/libpod_builder446168272/build": copier: stat: "/subdir": no such file or directory'

My simpleminded workaround would be something like:

    expect_msg="no items matching glob"
    if is_remote; then expect_msg="checking on sources under .*/subdir.*no such file or directory";fi

$ mkdir zzz;cd zzz
$ printf "FROM quay.io/libpod/testimage:20210610\nCOPY ./ ./\nCOPY subdir ./\n" >Dockerfile
$ printf "*\nsubdir\n\!*/sub1*\n" >.dockerignore
$ mkdir subdir; touch subdir/sub1.txt
$ ../bin/podman-remote build .

Should fail, but succeeds because we are not sending over the
.dockerignore file to the server side.  This PR will send the
.dockerignore so the server side and use it.

Fixes: containers#10907

Also if both .containerignore and .dockerignore in the context
directory, podman-remote should prefer .containerignore and not use
.dockerignore.

Fixes: containers#10908

Signed-off-by: Daniel J Walsh <[email protected]>
@edsantiago
Copy link
Member

/lgtm

Thanks @rhatdan !

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jul 15, 2021
@openshift-merge-robot openshift-merge-robot merged commit 47f3517 into containers:main Jul 15, 2021
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 22, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
4 participants