porter bundle publish command

[carolynvs]

We need a new command porter bundle publish, alias porter publish that uses cnabio/duffle#681 to push a bundle to a docker registry.

porter  publish [--file myapp/porter.yaml] [--tag altreg/myapp:tag] [--cnab-file bundle.json]

• --file defaults to the bundle in the current directory
• --tag defaults to a tag specified in the porter.yaml. This would be a new manifest field, Tag.
• --cnab-file is an optional flag (cannot be specified when --file is present), that points to a bundle.json and is used for non-porter bundles only.

We aren't using the push verb because it's a composite command doing multiple bits of work under the hood:

• This should follow the behavior outlined in Improve abstraction over CNAB #320, namely ensuring that cnab/bundle.json is up-to-date with porter.yaml before pushing, and potentially rebuilding.
• Push the invocation image.
• Push the bundle manifest.
• TODO: I forgot the rest, sorry. Will fill in later.

[vdice]

Do we need a separate issue to track removing the invocation image push step from porter build (assuming consensus on this change is met)? Or add to AC to this one?

[carolynvs]

If we remove it, without making any other change, will stuff still work? Or do we need do it as part of publish at the same time to not break porter?

[vdice]

If we remove it without making any other change, local bundle installation will continue to work (assuming using same docker daemon as image was built with) but the bundle may not be installable by another user on a different machine (unless porter build is run on their machine from same bundle source).

I would think adding it as part of publish in this/same set of commits would make the most sense, to cover the latter case mentioned above. It feels 'right' that the invocation image would/should only be pushed to a remote repo when the bundle is published.

[carolynvs]

Ok, sounds good to me to do it all in a single PR then.

[jeremyrickard]

CLOSED BY OTHER PRS