-
Notifications
You must be signed in to change notification settings - Fork 243
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gha: unify windows builds into one workflow and drop sha ID correlating #3974
Conversation
13c5acf
to
c90f992
Compare
This helps circumvent multiple complications. One, windows-e2e workflow does not need to wait for 2 workflows to finish (which is hard for a workflow_run triggered workflow). Two, we do not need to worry about matching the right artifacts from builder workflows with the right workflow_run that needs them (formerly used commit sha to do this). Third, the organization of workflows becomes logical: builder that prepares artifacts, and tester that consumes them and runs tests.
Parametrizing by workflow's matrix entries future-proofs the workflow.
Move all steps that might fail to before the provisioning step to avoid creating a machine if simple steps needed to run tests on it fail anyways.
c90f992
to
500f69f
Compare
@jsliacan: The following test failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: adrianriobo The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Addresses Issue #3975
The solution with many side benefits (see commit log) is to unify what was formerly two workflows
build-tests.yaml
andwindows-installer.yaml
intowindows-artifacts.yaml
. This workflow then triggerswindows-e2e.yaml
viaworkflow_run
and therefore,windows-e2e.yaml
has access to all artifacts fromwindows-artifacts.yaml
directly - no need to correlate via commit sha or similar.As a side effect,
windows-e2e.yaml
only gets triggered after all artifacts are produced, so we can rearrange steps insidewindows-e2e.yaml
in a way that postpones target host provisioning until after we know we have everything else ready (no provisioning if some precondition fails).Finally, parametrize commit status context by matrix entries, to futureproof.
A clean run (with only a
config.feature
run) can be seen checked as part of this dummy PR jsliacan#9. Here's the actual action: https://github.com/jsliacan/crc/actions/runs/7668762265