feat(e2e): execute per-component promote workflows and assert component-scoped state - #519
Merged
Merged
Conversation
…nt-scoped state The harness can now target a specific component's generated workflow and assert its recorded state. A promote or orchestrate step takes an optional component: an empty component runs the flat promote.yaml/orchestrate.yaml and asserts state.<env> exactly as before (byte-identical); a named component runs promote-<name>.yaml/orchestrate-<name>.yaml and asserts state.components.<name>.<env>. State sync parses the components subtree into composite keys so a component-scoped expectation reads the owning node. A new scenario seeds and promotes one component through the ladder, asserts a sibling component's recorded state stays byte-unchanged across that cycle, then advances the sibling independently, proving per-component promotion isolation end-to-end in the act and gitea run. Refs #290, #291. 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
Per-component promotion state (#517) and per-component promote workflows (#518) are in place, but the act+gitea harness could only run the flat
promote.yamland assert flatstate.<env>. Proving per-component promotion isolation end-to-end needs the harness to run a named component's workflow and assertstate.components.<name>.<env>.Fix
component. Empty runspromote.yaml/orchestrate.yamland assertsstate.<env>exactly as before (byte-identical). Named runspromote-<name>.yaml/orchestrate-<name>.yamland assertsstate.components.<name>.<env>.componentssubtree into composite keys so a component-scoped expectation reads the owning node; the flat path is untouched.51-component-promote-isolation.yaml: seeds and promotes one component through the ladder, asserts a sibling component's recorded state stays byte-unchanged across that cycle, then advances the sibling independently.Verification
go build ./...,go test ./...(2585 pass),golangci-lint run ./...clean; e2e build+vet clean; byte-identical baseline gate green. New scenario passes locally in the act+gitea harness (Per-Component_Promotion_Isolation, 39.7s); the single-component regression scenarioTwo_Environment_Happy_Pathalso passes locally (54.7s), confirming the flat path is unchanged.Refs #290, #291.