Primary artifact for releases (imgpkg)

[iancoffey]

Starting in the next cycle we will need to tie in imgpkg as the primary build artifact that ties together the components which are part of the hub.

This will cascade into TCE consumption.

cc @pbarker @cppforlife @joshrosso

Collated Context

Context from 2021-03-13 19:34:07
User: pbarker
I'm working on some integrations with Tanzu for the performance team, I'm looking at imgpkg for the release, but I've run into an issue:

If I want to put the CLI plugin in the imgpkg, it is OS specific.

There are a couple paths here:
a. Have an imgpkg per host OS arch type
b. Put all arch builds in the imgpkg
c. Have conditional dependencies for imgpkg
d. Include Go in the imgpkg and build from source adhoc on the host OS
e. Not include the CLI binaries and simply have them sourced elsewhere (may be challenging for airgapping)

Option A seems the most sane, but also comes with a fair amount of overhead

Curious about thoughts!

Context from 2021-03-18 17:54:59
User: cppforlife
this issue is probably relevant as well: carvel-dev/imgpkg#93

[rajaskakodkar]

@vuil can you please add some more context around this?