Dependency graph resolution

Let's define how the runtime should resolve the dependency graph for a bundle. There are a few types of dependencies that impact the graph:

hard coded dependencies
dependencies where the user supplies the name of the bundle to use. The runtime will install that dependency
dependencies where the user supplies an existing installation to use. The runtime will not install that dependency but may need to retrieve its outputs to pass to other dependencies of the parent bundle (see the second example in https://github.com/cnabio/cnab-spec/issues/424).

Let's define how tools should resolve a graph of bundle dependencies so that the resolution is consistent and well-defined between tools.

It is a directed acyclic graph
The dependency graph should resolve the bundles/installations that will be used before executing anything.
When a node in the graph is a bundle that needs to be executed, that node must include how the parameters and credentials of that bundle will be satisfied. i.e. it should know that the wordpress connection string parameter will be sourced from the output of the mysql bundle.
A graph can be of any depth (unless it reduces complexity to say otherwise I would like this in there)

Resolving a dependency involves the following checks:

Is the dependency satisfied by an existing installation that was provided?

Tooling can provide an existing installation to use.

Which bundle should be used?

Tooling can override the default bundle reference defined for the dependency.

The default bundle implementation is optional when the dependency defines a bundle interface. In this case the tooling is required to provide either a bundle reference or an existing installation.

When a default bundle implementation is defined, it could be a full bundle reference or it may use a version range. In the case of a version range, the resolver should query for available tags and select the highest semver tag that satisfies the bundle interface.

Does the bundle satisfy the dependency?

All dependencies must satisfy the declared bundle interface, whether it was provided by the tooling or resolved.

In the case of existing installations, only the outputs and custom actions on the bundle interface are compared.

What are the sources for parameters and credentials?

Each required parameter and credential that applies to the parent bundle action must have a source, for example the parent bundle's parameter, or the output of another dependency. Essentially the dependency's install command must be runnable when installing the parent bundle, or if upgrading the parent, the upgrade command for each dependency must be runnable.

The output of the graph resolution is an ordered list of bundles to execute, along with the sources for each parameter and credential that applies to the parent bundle action.

- reference: getporter/mysql:v.1.0.0
   parameters:
     dbName: # use the hard-coded value wordpress for the dbName parameter
        value: "wordpress"
- reference: helm-redis:v2.3.4
   credentials:
     kubeconfig: # Use the k8s installation output admin-kubeconfig for the kubeconfig credential
        installation: k8s
        output: admin-kubeconfig
- reference: getporter/wordpress:v0.1.1
   parameters:
     connection-string: # Use the mysql dependency output connStr for the connection-string parameter
        dependency: mysql
        output: connStr

Upgrade and Custom Actions

See #427

cnabio / cnab-spec