Convert a dependency's bundle interface document into a bundle.json

[carolynvs]

This relies on #2323 being merged before this can be started on.

https://github.com/getporter/proposals/blob/main/pep/003-dependency-namespaces-and-labels.md#bundle-interfaces allows for either referencing an existing published bundle to define a bundle interface, or to use an embedded bundle.json. We don't want to allow any arbitrary json to be embeded in the porter manifest for this and will instead let the user define using the same porter syntax, the parameters, credentials and outputs that should be defined on the bundle in order to use it as a dependency.

When we convert a porter.yaml to a bundle.json, we need to convert the bundle interface document from it's porter representation into an (incomplete) CNAB bundle document and embed it in the final bundle.json for the bundle being converted.

Dependencies

• Define a bundle with the v2 dependencies extension #2323

ℹ️ Read PEP003 - Advanced Dependencies for context about how dependencies should work, design details, and notes about desired behavior.

[carolynvs]

When the interface document is converted into the bundle.json's interface, we need to make a raw json representation of the parameters, credentials and outputs defined on the dependency interface document in porter.yaml, and stuff that into the bundle.json. There won't be a typed data structure to contain it.

porter.yaml

dependencies:
  requires:
    - bundle:
        reference: ghcr.io/getporter/mysql:v1.2.3
        # TODO: Convert these fields below into a raw json document that we can copy into bundle.json
        interface:
          parameters:
            - name: myparam
              type: integer
              default: 2
          credentials:
            - name: mycred
              required: true
          outputs:
            - name: myoutput
              type: string
              default: default value

bundle.json

{
    "custom": {
        "org.getporter.dependencies@v2": {
            "requires": {
                "mysql": {
                    "bundle": "ghcr.io/getporter/mysql:v1.2.3",
                    "interface": {
                        "credentials": {
                            "mycred": {
                                "required": true
                            }
                        },
                        "outputs": {
                            "myoutput": {
                                "definition": "myoutput-output",
                                "path": "/cnab/app/outputs/myoutput"
                            }
                        },
                        "parameters": {
                            "myparam": {
                                "definition": "myparam-parameter"
                            }
                        },
                        "definitions": {
                            "myoutput-output": {
                                "default": "default value",
                                "type": "string"
                            },
                            "myparam-parameter": {
                                "default": 2,
                                "type": "integer"
                            }
                        }
                    },
                    "sharing": {
                        "group": {},
                        "mode": "group"
                    }
                }
            }
        }
    }
}

We can reuse some of the existing functions in pkg/cnab/config-adapter/adapter.go and they will manage converting the creds/params/outputs. We need to put those converted values into a map, and then marshal that to json and save in the final bundle.json under the document field.

Here are some useful functions we can reuse or refactor a bit to take advantage of existing logic to convert from porter data structures to CNAB bundle data structures:

• generateBundleParameters
• generateBundleOutputs
• generateBundleCredentials

Keep in mind that a person can define a bunch of stuff on a param/cred/output that may not be relevant when used in an interface but it's up to the user to decide what is worth defining on a bundle interface. Examples of stuff that is relevant: data type, $id, validations such as min/max. Examples of stuff that isn't relevant but is possible to specify (but not worth testing or making examples/testdata for): default, location(env/path), and other values that are used inside a bundle but don't influence whether or not we can hook up two bundles and have them be able to communicate using that field.

You will need to edit the existing testdata to define an interface. If you look for this issue number 2548 in the code, you'll find commented out places where I thought we may need to edit to implement this feature.