test: run real external-update and notify path in multi-repo e2e#119
Merged
Conversation
…o e2e Signed-off-by: Joshua Temple <joshua.temple@stablekernel.com>
Signed-off-by: Joshua Temple <joshua.temple@stablekernel.com>
Signed-off-by: Joshua Temple <joshua.temple@stablekernel.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The multi-repo e2e harness was simulation-dominant. The generated
external-update.yaml,the
cascade external updateverb, and the satellite notify step were never executed:cross-repo dispatch recorded external state straight into an in-memory
ExecutionContextand the final assertions read it back from the same place, so the external/notify product
surface had no real coverage.
Fix
MultiRepoHarness.CreateReponow writes the manifest to.github/manifest.yaml(the CLI default; it previously wrote a path the CLI never reads)carrying both
configandstate, then runscascade generate-workflowfor each repo,reusing the single-repo generate/localize/converge machinery.
external-update.yamlunder act with the inputs the satellite would send. The real
cascade external updateverb writes
state.<env>.external.<name>back to the primary's manifest in gitea, and thefinal assertions read that committed manifest instead of in-memory state.
orchestrate.yamlis read from gitea and checked for the dispatch step targeting theprimary's external-update workflow.
external-update.yamlran the update verb (which commits andpushes the manifest) without first setting a git identity, which aborts on a clean runner.
It now emits a Configure Git step before the verb, matching the other state-writing
workflows.
The live cross-repo dispatch network hop is a no-op against gitea (it does not implement the
Actions dispatch API), so the harness bridges it by invoking the primary's external-update
workflow directly with the same inputs. The network hop itself is real-GitHub validation
material and is documented as residue in the harness.
Verification
go build ./...,go vet ./e2e/...,golangci-lint run ./e2e/...and./internal/generate/...all clean.satellite-notifies-primary, external-state-promotion, mixed-deploys. The rollback scenario
still passes against the real manifest. Product generate tests and harness unit tests green.