test: promote force and rollback runtime e2e scenarios (U6)#118
Merged
Conversation
Signed-off-by: Joshua Temple <joshua.temple@stablekernel.com>
This was referenced Jun 11, 2026
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
Two promote workflow paths had no runtime coverage:
forcedispatch input (bypasses the no-op promotion guard) had no e2e scenario.rollback_on_failurepath (rollback jobs that revert successful deploys when a sibling deploy fails) had no failure-injection scenario.Changes
Harness (
e2e/harness/):multistep.go: addedRollbackOnFailure booltoPromoteStepwith yaml tagrollback_on_failure. Mirrors the promote workflow'srollback_on_failuredispatch input.runner.go: wireRollbackOnFailureintoexecutePromote- passesrollback_on_failure="true"in the workflow dispatch inputs when set.Scenarios (
e2e/scenarios/promote/):promote-force.yaml: three-step scenario. Clean promote succeeds; re-promote of the same SHA is rejected by the no-op guard (expect_failure); third promote withforce: truebypasses the guard and succeeds. Assertsteststate SHA matchesdevafter force.promote-rollback-runtime.yaml: commits two reusable deploy workflows (deploy-infra.yamlalways succeeds;deploy-app.yamlchecks out the promoted SHA andexit 1s on a marker file). First promote populatesteststate. A marker commit is orchestrated intodev. Second promote withrollback_on_failure: trueruns both deploys -appfails on the marker, sorollback-infraruns to revert the successful infra deploy. Assertspreflight/promote/deploy-infra = success,deploy-app = failure,rollback-infra = success,rollback-app = skipped.Verification
go build ./...andcd e2e && go vet ./...: clean.-timeout 9meach).golangci-lint run ./e2e/...: clean.Gitea-observable trim
The exact
rollback_shavalue passed to the infra deploy callback is trimmed to the job-conclusion claim (rollback-infra: success). On real GitHub the SHA is observable through deployment objects; gitea/act do not model those. The job-conclusion claim is the meaningful observable: the rollback path ran and completed successfully.