Support multiple registries

[jmgilman]

Similar to #59, an image is limited to a single registry. This is because skopeo uses the image name to determine where to publish the image when copyToRegistry is called (i.e.,my-registry.com/image-name). Since the name can only be set once in the call to buildImage, currently pushing to multiple registries would require using multiple derivations, which in turn would (I believe) change the image hash and not be a suitable method.

Instead, we could add a registries option to buildImage, which automatically prepends the image name with each registry and pushes the image accordingly. I don't proclaim to be an expert on this subject, so correct me if I'm wrong here.

[blaggacao]

Use case:

• Cluster Registry for Ops
• Github or Docker Registry for Distribution / Releases

[nlewo]

I don't think we should introduce all these attributes (registries, extraTags) related to the image distribution in the image build function.

I introduced the image.copyTo* attributes to cover a simple usecase and it doesn't seem suitable for more complex usecases.

Unfortunately, I didn't find a good idea yet to cover your usecase. Maybe we could introduce a new function (something such as mkDistributionScript) taking an image as argument plus some other optional arguments (such as registries, extraTags). wdyt?

[blaggacao]

We also can implement these in std's Container Block Type Action since that is what blocktype actions deal with. However, it would be good to store image name(s) and tag(s) in a lazyDerivation for trivial access of that meta data.

re @nrdxp 'meta'-sidenote: lazyDerviation seems to be a better transport.

[jmgilman]

@nlewo If I make a mkDistributionScript type function, you'd be happy to merge that?

[nlewo]

@jmgilman yes, i think adding a new function would definitively be possible.

However, i'm not sure that would solve all your issues, since you would also like to add more attributes to the buildImage function: I'm more skeptical on this part.

[nlewo]

As previously discussed, i would prefer to avoid adding tags, names, and registries attributes to the buildImage function, since it's purpose it to build an image and not to push it. I also understand you want to attach such kind information to the image. So, the meta attribute looks like a good tradeoff :+1:

I'm closing this issue since it has been addressed by #65