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, with dockerignore, unexpected (wrong) diagnostic #12838

Closed
edsantiago opened this issue Jan 12, 2022 · 13 comments
Closed

podman-remote build, with dockerignore, unexpected (wrong) diagnostic #12838

edsantiago opened this issue Jan 12, 2022 · 13 comments
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. remote Problem is in podman-remote

Comments

@edsantiago
Copy link
Member

containers/buildah#3576 added an error message and a test for it. This is failing in podman-remote (not podman).

The error emitted by buildah and regular podman:

Error: error building at STEP "COPY test1.txt /upload/test1.txt": 
   no items matching glob "[SOURCEPATH]/bud/dockerignore3/test1.txt" copied
   (1 filtered out using [SOURCEPATH]/bud/dockerignore3/.dockerignore):
    no such file or directory

The error emitted by podman-remote:

Error: error building at STEP "COPY test1.txt /upload/test1.txt":
    checking on sources under "/var/tmp/libpod_builder317490355/build":
    copier: stat: "/test1.txt": no such file or directory

(line breaks added for readability)

@edsantiago edsantiago added the remote Problem is in podman-remote label Jan 12, 2022
edsantiago added a commit to edsantiago/libpod that referenced this issue Jan 12, 2022
 - reenable git:// tests
 - git command fails with (EVIL) status 128. Deal with it.
 - skip two failing tests that I don't know how to fix:
   a) --unsetenv is not passed on to buildah (should be easy)
   b) something manifest-related

 - skip a bunch more podman-remote tests. Filed an issue for
   one of them (containers#12838), the others may not be fixable.

Signed-off-by: Ed Santiago <santiago@redhat.com>
edsantiago added a commit to edsantiago/libpod that referenced this issue Jan 12, 2022
 - reenable git:// tests
 - git command fails with (EVIL) status 128. Deal with it.
 - skip two failing tests that I don't know how to fix:
   a) --unsetenv is not passed on to buildah (should be easy)
   b) something manifest-related

 - skip a bunch more podman-remote tests. Filed an issue for
   one of them (containers#12838), the others may not be fixable.

Signed-off-by: Ed Santiago <santiago@redhat.com>
Luap99 pushed a commit to Luap99/libpod that referenced this issue Jan 13, 2022
 - reenable git:// tests
 - git command fails with (EVIL) status 128. Deal with it.
 - skip two failing tests that I don't know how to fix:
   a) --unsetenv is not passed on to buildah (should be easy)
   b) something manifest-related

 - skip a bunch more podman-remote tests. Filed an issue for
   one of them (containers#12838), the others may not be fixable.

Signed-off-by: Ed Santiago <santiago@redhat.com>
Luap99 pushed a commit to Luap99/libpod that referenced this issue Jan 13, 2022
 - reenable git:// tests
 - git command fails with (EVIL) status 128. Deal with it.
 - skip two failing tests that I don't know how to fix:
   a) --unsetenv is not passed on to buildah (should be easy)
   b) something manifest-related

 - skip a bunch more podman-remote tests. Filed an issue for
   one of them (containers#12838), the others may not be fixable.

Signed-off-by: Ed Santiago <santiago@redhat.com>
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Luap99 pushed a commit to Luap99/libpod that referenced this issue Jan 13, 2022
 - reenable git:// tests
 - git command fails with (EVIL) status 128. Deal with it.
 - skip two failing tests that I don't know how to fix:
   a) --unsetenv is not passed on to buildah (should be easy)
   b) something manifest-related

 - skip a bunch more podman-remote tests. Filed an issue for
   one of them (containers#12838), the others may not be fixable.

Signed-off-by: Ed Santiago <santiago@redhat.com>
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Luap99 pushed a commit to Luap99/libpod that referenced this issue Jan 13, 2022
 - reenable git:// tests
 - git command fails with (EVIL) status 128. Deal with it.
 - skip a bunch more podman-remote tests. Filed an issue for
   one of them (containers#12838), the others may not be fixable.

Signed-off-by: Ed Santiago <santiago@redhat.com>
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Luap99 pushed a commit to Luap99/libpod that referenced this issue Jan 13, 2022
 - reenable git:// tests
 - git command fails with (EVIL) status 128. Deal with it.
 - skip a bunch more podman-remote tests. Filed an issue for
   one of them (containers#12838), the others may not be fixable.

Signed-off-by: Ed Santiago <santiago@redhat.com>
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
@mheon mheon added the kind/bug Categorizes issue or PR as related to a bug. label Jan 13, 2022
@vrothberg vrothberg self-assigned this Jan 24, 2022
@vrothberg
Copy link
Member

I'll take a look. Thanks for opening an issue, @edsantiago!

@vrothberg
Copy link
Member

vrothberg commented Jan 24, 2022

Ah, OK.

Since #8374, the remote client is parsing the ignore files and excludes matches from being tar'ed up. This explains the stat error: the file is really not there.

Not sure if we should massage the test OR if we should send the entire context over and let the server exclude the files.

@baude @rhatdan WDYT?

@rhatdan
Copy link
Member

rhatdan commented Jan 24, 2022

I think the test should be massaged.

@rhatdan
Copy link
Member

rhatdan commented Jan 24, 2022

As long as podman --remote build is doing what is supposed to.

@vrothberg
Copy link
Member

As long as podman --remote build is doing what is supposed to.

I am not entirely sure if the context should be pre-processed on the client side. @jwhonce WDYT?

@rhatdan
Copy link
Member

rhatdan commented Jan 25, 2022

The issue would then be sending files over that are not needed, so you are wasting bandwidth. But then again, the excludes also have to happen when you call in with the API.

@jwhonce
Copy link
Member

jwhonce commented Jan 25, 2022

@vrothberg I put the pre-processing on the client to not waste bandwidth. Otherwise there is the risk of copying a huge file to the server and then ignoring it.

@rhatdan podman-py processes the ignores on the client.

@rhatdan
Copy link
Member

rhatdan commented Jan 25, 2022

Works for me.

@github-actions
Copy link

A friendly reminder that this issue had no activity for 30 days.

@rhatdan
Copy link
Member

rhatdan commented Feb 28, 2022

@jwhonce @edsantiago @vrothberg Where are with this one?

@edsantiago
Copy link
Member Author

The test is currently disabled in podman:

skip_if_remote "Podman #12838: different error messages" \
"bud with .dockerignore #2"

Although I have provisions in apply-podman-deltas to change the expected error message, I don't have any mechanism to do so only for podman-remote. I'm not especially keen on adding that complexity. If the team's recommendation is to live with that new changed error message, I would suggest just keeping the test as skipped in podman. (But will implement change-error-if-remote or whatever the team recommends)

@rhatdan
Copy link
Member

rhatdan commented Feb 28, 2022

I think we can live with the difference and should close this issue.

@vrothberg
Copy link
Member

I think we can live with the difference and should close this issue.

OK

@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 20, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. remote Problem is in podman-remote
Projects
None yet
Development

No branches or pull requests

5 participants