chore: add UDS Core smoke test

[justin-o12]

Description

This adds a new job in the release workflow that will deploy a new test UDS bundle consisting of:

• k3d cluster
• zarf init
• uds core

It then validates a majority of the UDS core packages excluding pepr (it needs npx, but we can probably add it and make this work if we think it's necessary) and the packages that uds core doesn't test themselves.

Related Issue

Fixes #399

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc) - chore for new test

Checklist before merging

For testing, I created and deployed the new test bundle locally and ran the validate steps manually.

• Test, docs, adr added or updated as needed
• Contributor Guide Steps followed

[mjnagel]

I do like the idea of testing against uds-core in general but this would create a weird circle dependency I think? If uds-cli has a breaking change what would the path forward be to cut a release? It seems like you'd have to update uds-core to match the syntax/whatever for the un-released version of uds-cli?

[UncleGedd]

That's a really good point that I hadn't thought of. On the one hand, I'd really like to know if we have an unidentified breaking change, but I wouldn't want it to block releases. @justin-o12 what do you think of making this a nightly job instead? (see example here)

[justin-o12]

Yeah, I think making it a nightly job could work. Possibly noob question: is it even possible that uds-cli would have a breaking change that would affect the published uds Zarf package? I'm guessing by depending on a Zarf version that would have a breaking change for the published uds zarf package?

Either way, by having this test outside of the release workflow we won't block releases.

[mjnagel]

Yeah I guess technically would be a breaking change in zarf probably that would cause the above scenario - didn't think about that... since we're just consuming the zarf package here and the bundle is crafted in this test file. That's probably a pretty unlikely case then?

[justin-o12]

We've switched to deploying the k3d dev bundle, because we do not publish the k3d dev Zarf package to OCI. So, we're back to your original point that we could have a breaking change. So, we've moved this workflow to a nightly so it doesn't block releases.

[justin-o12]

wait-for does not need a condition like ready for gateways. Below is a command without ready on a gateway that exists.

uds zarf tools wait-for gateway passthrough-gateway -n istio-passthrough-gateway --timeout 20s                                   130 ↵

 NOTE  Using config file

 NOTE  Using config file
  ✔  Waiting for gateway/passthrough-gateway in namespace istio-passthrough-gateway to exist.

Next is the command with ready on that same gateway.

💻 ~ » uds zarf tools wait-for gateway passthrough-gateway ready -n istio-passthrough-gateway --timeout 20s

 NOTE  Using config file

 NOTE  Using config file
     ERROR:  Wait timed out.

Next is the command on a gateway that doesn't exist without ready:

💻 ~ » uds zarf tools wait-for gateway fake-gateway -n istio-passthrough-gateway --timeout 20s                                            1 ↵

 NOTE  Using config file

 NOTE  Using config file
     ERROR:  Wait timed out.

[decleaver]

looks good! checked out and ran steps manually