Add a way to handle dependencies within components of a package

[vyta]

Is your feature request related to a problem? Please describe.
Deployments of components may fail if it depends on other components that have not been fully deployed via flux. (For example, an application relying on certain CRD's deployed as part of bigbang, helm install returns successfully so zarf moves onto the next component (app), but flux hasn't deployed everything yet)

Describe the solution you'd like
A mechanism to denote dependencies such that zarf can ensure certain resources exist before deployment of a component. Perhaps specifying namespace, deployment name, or a healthcheck/readiness endpoint that zarf can verify

[RothAndrew]

This may be best handled in Flux. Flux HelmRelease custom resources allow for a dependency tree natively (see example).

If desired to have a zarf component wait until something is fully ready the scripts.after block (or scripts.before if you want to wait for something before running the component) may be used as well as an alternate solution.

components:
  - name: foo
    scripts:
       after:
         # waits until the deployment exists
         - while ! kubectl get deployment gitlab-webservice-default -n gitlab; do sleep 5; done
         # waits for the deployment to be healthy/ready
         - kubectl rollout status deployment/gitlab-webservice-default -n gitlab --watch --timeout=300s

[vyta]

Was not aware of the script blocks, perhaps I missed it in the docs somewhere?

[RothAndrew]

Docs are still rough, so wouldn't fault you for missing it :) They're being worked on right now though.

@YrrepNoj have you by any chance looked yet into what automated tools there might be to document the zarf yaml schema, in a similar way that we automatically document the CLI?

[YrrepNoj]

@RothAndrew I have not yet but I imagine there are some tools that would be really useful. I'll spend a little bit of time looking into that.

[jeff-mccoy]

We've also had some discussions around basic "ready" tests we could do, but haven't come up the right solution. For example, having a component wait for a specific deployment to be ready might look like:

components:
  - name: foo
    waitFor:
      - deployment: example-deployment
         namespace: example

or maybe

components:
  - name: foo
    waitFor:
      - crd: cool-crd

Would love to have further dialog on that

[mahomedalid]

I was checking today the porter tool (https://github.com/getporter/) and seems they are having a similar need (getporter/porter#1939). I guess @jeff-mccoy are maybe already aware that Porter is also a go tool, so would be interesting to see if there is a chance to join efforts.

[jeff-mccoy]

@mahomedalid I learned about Porter a few months ago, but haven't had any conversations with that team yet. We probably should at some point. CNAB seems pretty complicated, but thought it might be worth adding as a source in the future if adoption grew beyond Azure quick starts (primary use I've seen so far).

[Noxsios]

With the wait-for feature completed, I believe this can be safely closed. @Racer159 @jeff-mccoy

[Racer159]

Closing per the above since wait-for exists. This will also be enhanced further in #1873