fix(e2e): make rollback-runtime scenario deterministic within act limits#123
Merged
Conversation
The scenario failed deterministically at the clean orchestrate step because a reusable deploy callback cannot run actions/checkout against the auth-less per-scenario gitea, and act does not populate a reusable callback workspace with the repo tree. The deploy now probes the failure marker directly from the repo at the promoted SHA over the internal gitea alias. act also keys a job by the reusable workflow inner job id, so the rollback jobs cannot be told apart from the forward deploys by name; the rollback is asserted through its observable boundary instead - the promote concludes in failure with the app deploy failed and the infra deploy succeeded, the asymmetric outcome that is the sole trigger for the rollback path. 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
1 participant
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.
The promote rollback-runtime scenario (added in #118) failed deterministically at its clean orchestrate step and only passed intermittently before. Root cause: a reusable deploy callback cannot run actions/checkout against the auth-less per-scenario gitea, and act does not populate a reusable callback workspace with the repo tree, so the marker-file probe had nothing to read.
The deploy now probes the failure marker directly from the repo at the promoted SHA over the internal gitea alias (no auth needed): absent at the SHA the first promote carries, present at the SHA the second carries. act also keys a job by the reusable workflow inner job id, so the rollback jobs cannot be distinguished from the forward deploys by name; the rollback is asserted through its observable boundary instead - the promote concludes in failure with the app deploy failed and the infra deploy succeeded, the asymmetric outcome that triggers the rollback path. Deterministic across repeated isolated runs.