fix: correlate external-update runs and run scoped deploy job in e2e#214
Merged
Conversation
External-update receiver runs had no run-name, so a workflow_dispatch run's displayTitle defaulted to the workflow name and downstream consumers could not correlate a receiver run to the dispatched component and sha. Emit run-name: External Update <deploy_name> <sha> so each run is correlatable. The external-update-deploys-component e2e scenario pointed its on_update.deploy.workflow at a cross-repo reusable workflow that act cannot auth-clone from gitea, failing the generated deploy_cdk job and the whole receiver run. Repoint it at a local reusable workflow seeded into the primary repo so act resolves it via uses: ./ and the scoped deploy job runs to success, exercising the deploy-on-update path live. 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.
Problem
Two deploy-on-update breakages:
The generated
external-update.yamlhad norun-name, so aworkflow_dispatchreceiver run's displayTitle defaulted to the workflow name ("External Update"). Downstream consumers correlate a receiver run by matching the dispatched sha in the run title, which could never match.The
external-update-deploys-componente2e scenario pointedon_update.deploy.workflowat a cross-repo reusable workflow. The receiver workflow runs under act, which cannot auth-clone that cross-repo workflow from gitea, so the generateddeploy_cdkjob failed and the whole receiver run concluded failure, turning Integration red.Fix
run-name: External Update ${{ inputs.deploy_name }} ${{ inputs.sha }}inwriteWorkflowTriggerso each receiver run's displayTitle embeds the component and sha and is correlatable.on_update.deploy.workflowat a local reusable workflow seeded into the primary repo before the dispatch. act resolves it viauses: ./and the scoped deploy job now runs to success, exercising the deploy-on-update path live instead of failing.Verification
go build ./... && go test ./... && golangci-lint run ./...all green (1426 tests pass, lint clean).--- PASS: TestMultiRepoScenarios/external-update-deploys-component (24.88s).