-
Notifications
You must be signed in to change notification settings - Fork 208
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
workflows: check status of Relay port-forward #390
Conversation
Will remove draft mode when #336 is merged. |
GKE https://github.com/cilium/cilium-cli/actions/runs/990923464 hit
The flow logs look like #367 (DNS request made but no TCP connection) but this time it's from an internal pod-to-service EKS https://github.com/cilium/cilium-cli/actions/runs/990923461 failed with:
This is because we are now not removing the |
97c9285
to
e56619b
Compare
e56619b
to
3d252a3
Compare
Rebased to pick up EKS workflow fixes in #394. |
GKE https://github.com/cilium/cilium-cli/actions/runs/1001017290 hit:
Never seen this one before (why am I hitting all the new flakes 🤔). EDIT: created new issue in #399. PR is blocked. |
3d252a3
to
79bbdfa
Compare
Added missing check for multicluster testing. |
79bbdfa
to
8bc435c
Compare
Since we start a background process for port-forwarding Relay, we must check if it actually succeeded or failed before allowing workflows to continue. When passing additional flags to `cilium hubble port-forward`, both the original command and `kubectl` child process might be conflated with additional flags. We add wildcards for matching the additional flags to both `pkill` cleanups and `pgrep` port-forward success checks. We also standardize a 10s allowance time for port-forward to start. Signed-off-by: Nicolas Busseneau <[email protected]>
8bc435c
to
821af71
Compare
It seems nobody else has been hitting #399. Considering that:
It seems we are now in the "unreproducible flake" scenario, which is an exception to our zero-flake strategy. Issue will be left open in case someone does end up hitting the same flake 🤔 |
Since we start a background process for port-forwarding Relay, we must check if it actually succeeded or failed before allowing workflows to continue.
We also standardize a 10s allowance time for port-forward to start.
This is a follow-up to the discussion here: #336 (comment)