Add dry-run mode to copy skopeo-copy

[deriamis]

Dry-run functionality was merged into the sync command in #1608. Here, the same sort of functionality is added to the copy command as well.

Also, containerized targets weren't working with docker due to a few missing items. I fixed them in a second commit so I could verify all the make targets passed. If you would prefer that commit in a second PR, I can do so.

[mtrmac]

Thanks for the PR.

Why does this need to be an option? A single skopeo copy always copies one image, so what good does this do? With skopeo sync, it might be interesting to see which images are going to be copied, because that is dynamic and changing.

In here, just substituting skopeo copy with echo skopeo copy in the callers would, AFAICS, deliver broadly the same kind of information; so why have the new option?

---

I didn’t actually review the implementation in detail yet, but the git config --global --add calls are a clear blocker.

[mtrmac]

I consider a single project overwriting users’ configuration like this completely unexpected to the point of being hostile.

[deriamis]

It looks a lot worse than it is. This only happens inside a container that is built from an image the user doesn't control, so it can't overwrite their configuration. It's really only modifying root's git config in the container's ephemeral root volume. Without the change, the git command to grab the current commit hash fails and therefore the go build command also fails.

Incidentally, this seems to be a problem with an ownership mismatch due to user ID mapping issues when the container is started. Either the image should be fixed or user ID mapping should be implemented. This is only a stopgap measure so the tests actually run.

[deriamis]

Why does this need to be an option? A single skopeo copy always copies one image, so what good does this do? With skopeo sync, it might be interesting to see which images are going to be copied, because that is dynamic and changing.

In here, just substituting skopeo copy with echo skopeo copy in the callers would, AFAICS, deliver broadly the same kind of information; so why have the new option?

It's true that copy.Image from containers/image/copy doesn't know how to do a dry-run - as in, ensuring the source image and destination repository both exist but not doing the copy. That would be nice for CI/CD operations when testing publish functionality, like we do here in this MR:

https://gitlab.com/gitlab-org/cloud-native/charts/gitlab-ingress-nginx/-/merge_requests/13/diffs#deda9b12c56fbec4fa6d58b177145eba56e84db3_0_19

Even so, skopeo-copy does a lot of argument checks and also some image name parsing before it writes the dry-run output, so seeing the output at least tells you the command is structured correctly, which is more than echo can do.

I didn’t actually review the implementation in detail yet, but the git config --global --add calls are a clear blocker.

See my reply to your comment about the command. I can move the test infrastructure changes to a separate PR if you still have questions and are otherwise satisfied with what I am doing. I only needed them so I could run the tests locally on my Mac.