Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

chore: add UDS Core smoke test #474

Merged
merged 6 commits into from
Mar 4, 2024
Merged

chore: add UDS Core smoke test #474

Show file tree
Hide file tree
Changes from 3 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
2d6e492
wip: Adding UDS Core smoke test to release workflow.
justin-o12 Feb 27, 2024
9846e3f
Add validate for uds core components.
justin-o12 Feb 27, 2024
2e1ba3c
Update renovate tags for uds core and zarf.
justin-o12 Feb 27, 2024
b286742
Use uds-core istio only bundle to deploy from ghcr.
justin-o12 Feb 29, 2024
cb1a63a
Move UDS smoke test from release to nightly.
justin-o12 Feb 29, 2024
643d97e
whitespace
justin-o12 Feb 29, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 46 additions & 1 deletion .github/workflows/release.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -80,9 +80,54 @@ jobs:
if: always()
uses: ./.github/actions/save-logs

push:
uds-core-test:
runs-on: ubuntu-latest
needs: validate
permissions:
contents: read
steps:
- name: Checkout
uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
with:
fetch-depth: 0

- name: Download build artifacts
uses: actions/download-artifact@87c55149d96e628cc2ef7e6fc2aab372015aec85 # v4.1.3
with:
name: build-artifacts
path: build/

- name: Make UDS-CLI executable
run: |
chmod +x build/uds

- name: Create UDS Core bundle
run: build/uds create src/test/bundles/13-uds-core/ --confirm --no-progress
shell: bash

- name: Deploy UDS Core bundle
run: build/uds deploy src/test-bundles/13-uds-core/uds-bundle*.tar.zst --confirm --no-progress
shell: bash

- name: Validate UDS Core deployment
run: |
build/uds zarf tools wait-for pod app.kubernetes.io/instance=grafana -n grafana
build/uds zarf tools wait-for gateway admin-gateway -n istio-admin-gateway
build/uds zarf tools wait-for gateway passthrough-gateway -n istio-passthrough-gateway
build/uds zarf tools wait-for gateway tenant-gateway -n istio-tenant-gateway
build/uds zarf tools wait-for pod app.kubernetes.io/name=loki -n loki
build/uds zarf tools wait-for pod app.kubernetes.io/component=gateway -n loki
build/uds zarf tools wait-for deployment metrics-server -n metrics-server
build/uds zarf tools wait-for apiservice v1beta1.metrics.k8s.io available
build/uds zarf tools wait-for pod app.kubernetes.io/name=alertmanager -n monitoring # Prometheus
build/uds zarf tools wait-for pod app.kubernetes.io/name=prometheus -n monitoring # Prometheus
build/uds zarf tools wait-for pod app.kubernetes.io/name=kube-state-metrics -n monitoring # Prometheus
build/uds zarf tools wait-for pod app.kubernetes.io/instance=promtail -n promtail
shell: bash
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


push:
runs-on: ubuntu-latest
needs: uds-core-test
permissions:
contents: write
steps:
Expand Down
38 changes: 38 additions & 0 deletions src/test/bundles/13-uds-core/uds-bundle.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
kind: UDSBundle
metadata:
name: uds-core
description: Bundle with Zarf init and UDS Core
architecture: amd64
version: 0.0.1

packages:
- name: uds-k3d
repository: ghcr.io/defenseunicorns/packages/uds-k3d
# renovate: datasource=github-tags depName=defenseunicorns/uds-k3d versioning=semver
ref: 0.4.0
overrides:
uds-dev-stack:
minio:
variables:
- name: buckets
description: "Set Minio Buckets"
path: buckets
- name: svcaccts
description: "Minio Service Accounts"
path: svcaccts
- name: users
description: "Minio Users"
path: users
- name: policies
description: "Minio policies"
path: policies

- name: init
repository: oci://ghcr.io/defenseunicorns/packages/init
# renovate: datasource=github-tags depName=defenseunicorns/zarf versioning=semver
ref: v0.32.1

- name: core
repository: oci://ghcr.io/defenseunicorns/packages/uds/core
# renovate: datasource=github-tags depName=defenseunicorns/uds-core versioning=semver
ref: 0.13.1-registry1
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Loading