From ac1a4196ea15431227368c887285ec795bb38ece Mon Sep 17 00:00:00 2001 From: Louis Parkin Date: Tue, 4 Aug 2026 14:38:28 +0200 Subject: [PATCH] STAC-25521 Document beest end-to-end verification The GitLab pipeline had a beest_k8s_1_33_containerd_trigger_verification job that triggered the beest project. It was dropped in the GitHub migration and Testing.md only covered local and Vagrant testing, so there was nothing pointing a developer at end-to-end verification at all. The trigger job itself does not need reimplementing. It was `when: manual` with allow_failure on every branch, so it was always a button someone pressed, and beest has since moved to GitHub with a workflow_dispatch that takes process_agent_branch_under_test directly. Rebuilding a cross-repo trigger would mean giving this public repo a token with actions:write on a private repo to replace a button that is already one click away. beest resolves the branch to the latest 8-character short SHA and uses it as the image tag, which matches the tags publish-image produces, so the two sides already line up. Documents the real remaining constraint: publish-image and merge-multiarch-manifest are gated on refs/heads/master, so no image exists for a feature-branch commit and beest cannot verify one pre-merge. GitLab published per-commit images on every branch, so this is a behaviour change. Left as a note against STAC-25521 rather than quietly relaxing a publishing policy that was set deliberately. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- Testing.md | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/Testing.md b/Testing.md index 9d5493464..318f1c210 100644 --- a/Testing.md +++ b/Testing.md @@ -4,6 +4,38 @@ Pre-requisites: * Build the process-agent +## End-to-end (beest) + +Local and VM testing below covers the agent in isolation. End-to-end verification against a +real cluster and a real SUSE Observability backend is done by +[beest](https://github.com/StackVista/beest). + +The GitLab pipeline had a `beest_k8s_1_33_containerd_trigger_verification` job for this. It +was `when: manual` on every branch, so it was never automatic — someone pressed it. The +equivalent on GitHub is to dispatch the beest workflow directly: + +``` +gh workflow run agent-x86.yml --repo StackVista/beest \ + -f process_agent_branch_under_test= +``` + +Or from the beest repo's Actions tab, via *Run workflow*. The same +`process_agent_branch_under_test` input exists on `agent-x86.yml` (x86 EKS), `arm.yml` +(ARM EKS) and `openshift.yml` (ROSA). + +You do not pass a commit or an image tag. beest resolves the branch to the latest 8-character +short SHA on it and uses that as the image tag, which is exactly what this repo's +`publish-image` job publishes. + +**Images are only published from `master`.** `publish-image` and `merge-multiarch-manifest` +in `.github/workflows/ci.yml` are gated on `refs/heads/master`, so there is no image for a +feature-branch commit and beest will not find one to pull. In practice that means beest +verification currently happens *after* merge. Pre-merge verification of a feature branch is +tracked in [STAC-25521](https://stackstate.atlassian.net/browse/STAC-25521). + +Note that beest runs cost real AWS infrastructure and all of its AWS workflows share a single +global concurrency lock, so runs queue rather than run in parallel. + ## Local Make sure to change in the `conf-dev.yaml` the address of the StackState backend to `localhost`.