Add dependency check for current child samples

[michael-valdron]

Which area/kind this issue is related to?

/area ci
/area registry

Issue Description

In order to ensure our current child samples remain compatible with changes to their parent stacks, a dependency check on these samples will be necessary to prevent breaking changes from being introduced to the parents. This dependency check should be run on all PRs made to the community registry repository.

We need to:

1. Set up a dependency tree that shows the current child samples for each parent stack
2. Triggers the testing of child samples as part of the PR tests of the parent stacks

The auto-generated dependency tree and inclusion of additional child stacks/samples are planned in the upcoming #1060 changes.

[michael-valdron]

Targeting this issue for next sprint to focus on higher prior items.

[michael-valdron]

For the parent stack dependency tree we can use a parents.yaml file which could be built from a script that runs nightly.

Proposed parents file:

parents:
  stack1_name:
    children:
      - name: child1_name
      - name: child2_name
        version: 1.0.2
  stack2_name:
    version: 1.1.0
    children:
      - name: child3_name

[elsony]

How quick is the script to build the parent.yaml? If the generation of the script is quick, can we just generate it on the fly instead of storing it as part of the repo? The issue with running nightly is what if the PR introduces a new dependency? Then the PR build may not be able to trigger the dependent child test run.

[michael-valdron]

How quick is the script to build the parent.yaml? If the generation of the script is quick, can we just generate it on the fly instead of storing it as part of the repo? The issue with running nightly is what if the PR introduces a new dependency? Then the PR build may not be able to trigger the dependent child test run.

@elsony I'll need to look into building the file using multiple versions but yeah this makes for sense on the fly over nightly due to it building fast enough and getting the recent sample changes in real-time. I could still build this yaml in the check script then passing it into the Go test suite to be worked on.

[michael-valdron]

Proposed parents file:

parents:
  stack1_name:
    children:
      - name: child1_name
      - name: child2_name
        version: 1.0.2
  stack2_name:
    version: 1.1.0
    children:
      - name: child3_name

Revised parents yaml based on multiple parent versions:

parents:
  - name: stack1_name
    children:
      - name: child1_name
      - name: child2_name
        version: 1.0.2
  - name: stack2_name
    version: 1.1.0
    children:
      - name: child3_name
  - name: stack2_name
    version: 1.2.0
    children:
      - name: child3_name
      - name: child4_name

[michael-valdron]

Have created test suite for validating child samples, continuing to work out errors and fit multi versions for both stacks and samples. Targeting next sprint to accomplish this.

[michael-valdron]

Have created test suite for validating child samples, continuing to work out errors and fit multi versions for both stacks and samples. Targeting next sprint to accomplish this.

Additional test suite has been scrapped for reuse of existing test suite for stack validation, some stack testing cannot be reused and is omitted from these additions.