-
Notifications
You must be signed in to change notification settings - Fork 2.8k
capz: debug failing periodic main job #26746
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
capz: debug failing periodic main job #26746
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jackfrancis The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
| preset-azure-anonymous-pull: "true" | ||
| extra_refs: | ||
| - org: kubernetes-sigs | ||
| - org: jackfrancis |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should be running the same tests as presubmit jobs, is there any reason we can't use CI running on a PR to investigate failures? are there flakes observed in periodic jobs that can't be reproduced in presubmit?
|
/hold |
|
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
This PR updates the capz periodic main test job to this dedicated PR branch used for turning these flakes green:
kubernetes-sigs/cluster-api-provider-azure#2451
As of 5 July 2022 8 of the past 10 jobs have failed, so it would be defensible to consider this job (or capz @ main) unstable. Having a dedicated branch to change and observe outcomes to test configuration (or code) changes will help us triage which of those two possibilities are true, and how best to make things healthy again.