Excluding the .imgpkg folder of a bundle does not allow pushing as an image

[StevenLocke]

What steps did you take:
Create a bundle directory (bundle_dir) including the necessary .imgpkg dir and images.yml file
Attempt to push the bundle directory as an image
imgpkg push -i <repo> -f bundle_dir
Observe the expected error.

...consider using a bundle

Now, exclude the .imgpkg directory from the push command.
imgpkg push -i <repo> -f bundle_dir --file-exclude-defaults .imgpkg

What happened:
The same error.

...consider using a bundle

What did you expect:
The directory and its contents pushed as an image to the repo.

Unsure if this is a pathway we want to allow/encourage, it's a little strange to be pushing a bundle as an image, but I would expect the tool to respect my "exclude" choices.

Anything else you would like to add:
This happens because of where our excluded files are checked, only when making the tarball, after the image/bundle verification steps.

Environment:

• imgpkg version (use imgpkg --version): imgpkg version 0.2.0
• Docker registry used (e.g. Docker HUB): Any repo
• OS (e.g. from /etc/os-release): Mac

[joaopapereira]

Given the help text of the --file-exclude-defaults flag, I would be inclined to say that if the flag is present and excludes the .imgpkg folder when pushing the image to the registry the folder should not be present.
But my expectation when trying to exclude .imgpkg folder is that I would get an error, since this is part of the imgpkg internals.

IMHO I believe what we should do is give a different error message when you try to exclude the .imgpkg folder using --file-exclude-defaults. Something in the lines of Error: The folder .imgpkg cannot be excluded.

In my research, for this issue, I found out that you can push a bundle and ignore the .imgpkg folder which is a problem and the solution that I propose above could solve it.
The example:

$ imgpkg push -b localhost:5000/test -f examples/basic-bundle --file-exclude-defaults .imgpkg
dir: .
file: config.yml
Pushed 'localhost:5000/test@sha256:319deaae5b3ce1633f14000f57144ebe1c73fbd4eb3d37874910335a92ab32ca'
Succeeded


$ imgpkg pull -b localhost:5000/test -o tmp
Pulling image 'localhost:5000/test@sha256:319deaae5b3ce1633f14000f57144ebe1c73fbd4eb3d37874910335a92ab32ca'
Extracting layer 'sha256:53484d40f83668beb17852cc4d95b4530fad5aca908446288136b75b6aa3e06b' (1/1)

Error: Rewriting image lock file: Reading image lock file: open tmp/.imgpkg/images.yml: no such file or directory

[danielhelfand]

Agree with @joaopapereira that the error message for this specific case makes sense. It should be easy enough to catch if .imgpkg is part of the path included with --file-exclude-defaults and error out to explain to the user why not to do this.