feat: disable cache-copy-layers in multistage builds; closes 2065

[dradetsky]

Fixes #2065

Description

If CacheCopyLayers is enabled, and the user is trying to build a multi-stage Dockerfile, exit immediately since this doesn't work properly.

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

• Includes unit tests
• Adds integration tests if needed.

See the contribution guide for more details.

Reviewer Notes

• The code flow looks good.
• Unit tests and or integration tests added.

Release Notes

Anyone who is currently passing --cache-copy-layers with multistage Dockerfiles will have their builds break.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[imjasonh]

Looks like a gofmt needed: https://github.com/GoogleContainerTools/kaniko/runs/8026358658?check_suite_focus=true#step:4:1362

Otherwise lgtm, thanks for sending this

[dradetsky]

@imjasonh just so there's no misunderstanding

A slower correct build is also better IMO than a fast silently-broken one, or a fails-immediately one.

This is true, but my opinion is that changing opts.CacheCopyLayers = false in this case is not a "slower correct build". The amount of time to change this one value is trivial. The reason I'm dubious about it is that it is non-defensive programming. To do things this way we would have to be sure that no part of the code attempted to read had already attempted to read the value of opts.CacheCopyLayers either now or as the result of any future changes. This assumption might hold, but it seems much safer to just not have to make it.

Maybe it would be possible to, at this point, restart execution of the entire process from the beginning with CacheCopyLayers=false, which seems more like a "slower but correct build", but this seems like too much added complexity to be worth it. Like, I'd assume that this extra complexity would result in breaking something else (it definitely would if I was the one doing it). By contrast, a few users having their builds break when they're already doing something unsupported which probably isn't working properly seems like it's not so bad.

And this is only users who have chosen not to pin their dependencies, such as their version of executor. I always pinned the executor image I used in my argo workflows since I wanted to make sure that upstream updates don't change anything unless I want them to. But if somebody doesn't pin the executor, they're saying they're okay with upstream breaking their build on upgrades. And this is a case where upstream breaking your build is a good thing, since you were doing something very bad, you just didn't understand it.

[dradetsky]

I'm choosing to interpret the previous "lgtm" as implying that integration tests are not required, and crossing that off

[dradetsky]

Should probably also close #1877 on merge