tide merges PRs when GitHub Actions are retried

[dprotaso]

What happened:

Knative has prow jobs and GitHub Actions setup for our serving repository. For that repo, tide is setup to gate PRs even on unknown contexts.

In one PR (https://github.com/knative/serving/pull/13753) the prow jobs passed and a few actions failed. When I restarted the failed actions in the GitHub UI tide just merged the PR while those restarted actions were in progress.

What you expected to happen:

I expect tide to not merge the PR when failed actions are being retried.

[jmguzik]

/sig testing /area prow

[amirrmonfared]

/assign This seems unusual to me since I haven't noticed it before, but I have been assigned to conduct further investigation into the issue myself. @droslean @chaodaiG, if you could provide any advice on how to identify the root cause, it would be greatly appreciated.

[dprotaso]

@amirrmonfared have you had any luck reproducing the issue?

[amirrmonfared]

@amirrmonfared have you had any luck reproducing the issue?

Hi @dprotaso unfortunately not yet and maybe not in the near future too, but if you can please assign it to yourself or anybody else, I would be happy on helping with the reviews at this moment.

[droslean]

@dprotaso Can you share your configuration? I don't recall if Tide is checking for the GitHub actions statuses by default.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[dprotaso]

/lifecycle frozen

[BenTheElder]

I would not recommend depending on github actions for critical blocking tests if you're using prow, we rarely use them in kubernetes and it's difficult to make the same guarantees about testing the latest commits without control over the git cloning.

For current discussions please file with https://github.com/kubernetes-sigs/prow if you're still interested.

[dprotaso]

We're using actions for quick linting of the PR etc

If I see this again I'll open a new issue in the new repo - thanks for the help

[BenTheElder]

We're using actions for quick linting of the PR etc

Yeah, to be clear I'm using actions in kubernetes-sigs/kind to more easily get local VMs (ironically) for testing with cgroupv2 (and probably in the future with v1 instead), but we're not depending on those being guaranteed before merge and I haven't seen any big problems with it yet.

I would recommend sticking anything that needs to be reliably blocking in prow for now, best effort type stuff can be very convenient in actions.

If I see this again I'll open a new issue in the new repo - thanks for the help

Thanks!

I did a partial sweep of old prow issues here trying to triage where they belong and improve visibility, though I'm not sure how active the new prow-specific issue tracker is ...