test-infra Reply to pr for failed postsubmit jobs

Part of work on #10402

Apr 07 '20 19:04 adshmh

Hi @adshmh. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

Apr 07 '20 19:04 k8s-ci-robot

/ok-to-test

Apr 08 '20 09:04 petr-muller

/cc @cblecker I would appreciate a review as this tries to add the feature you specified.

Apr 20 '20 10:04 adshmh

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

Aug 02 '20 19:08 fejta-bot

/retest

Aug 04 '20 18:08 adshmh

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten

Sep 03 '20 20:09 fejta-bot

/remove-lifecycle rotten

Sep 04 '20 15:09 adshmh

need rebase

Jan 19 '21 20:01 spiffxp

A more general concern: I don't think this fully fixes #10402, I would remove that from the description. The reason is that there's no way to report to the PR on success. Crier's github reporter will post status contexts to a merge commit for postsubmits, and with this change it will create a comment on the PR if there are any failures.

But there is no way to comment to the PR on success. This will require some changes to crier's reporting logic. I want this so that:
* I can see if a PR caused something to successfully deploy

* I can see if a PR caused an image to be built and pushed

Thank you for the review. I have edited the PR title accordingly.

Regarding comments on the PR on success, would it be acceptable to keep the scope of this PR to failed postsubmits? Once this PR is merged, I will follow up with another one, to make changes to crier's logic necessary to support successful postsubmits.

Feb 15 '21 10:02 adshmh

/retest

Feb 15 '21 10:02 adshmh

Regarding comments on the PR on success, would it be acceptable to keep the scope of this PR to failed postsubmits? Once this PR is merged, I will follow up with another one, to make changes to crier's logic necessary to support successful postsubmits.

That sounds good to me. I'll review during working hours tomorrow/

/uncc @Katharine @michelle192837 /cc @cjwagner @alvaroaleman @fejta in case you have any input

Feb 15 '21 22:02 spiffxp

Will try to take a look today

Feb 18 '21 18:02 spiffxp

Can we:

Do most reporting on the commit, rather than the PR?
Optionally drop a note on the PR that postsubmits were scheduled to commit X and to look there fore results?

Mentioned this in #10402

Mar 01 '21 21:03 fejta

Can we:

1. Do most reporting on the commit, rather than the PR?

2. Optionally drop a note on the PR that postsubmits were scheduled to commit X and to look there fore results?

Mentioned this in #10402

Thank you for the review. Should the reporting be kept as is, i.e. to the most recent commit, identified by the after field of the push event? Or should it be changed to report each postsubmit job to the specific commit that triggered it?

Considering the scenario in this review comment, the latter seems more consistent with dropping a single note on the specific PR that triggered a postsubmit.

Mar 09 '21 21:03 adshmh

Considering the scenario in this review comment

I don't think that scenario is correct. How/when do we imagine it would come about?

In the scenario where we merge PR A and then PR B we would get two events and thus wind up triggering two postsubmit jobs, one that would comment on A (repo state at HEAD+A) and another that would comment on B (repo state at HEAD+A+B).

Should the reporting be kept as is, i.e. to the most recent commit, identified by the after field of the push event? Or should it be changed to report each postsubmit job to the specific commit that triggered it?

We should keep it the way it currently is, which is designed to handle single PRs with multiple commits.

When we merge PR C that has 15 commits (C1-C15) we only trigger a single postsubmit job at the latest commit, and we also only comment on the latest commit.

Mar 09 '21 23:03 fejta

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale

Jun 07 '21 23:06 fejta-bot

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten

Jul 08 '21 00:07 fejta-bot

/remove-lifecycle rotten

Jul 25 '21 10:07 adshmh

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:

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 or PR as fresh with /remove-lifecycle stale
Mark this issue or PR as rotten with /lifecycle rotten
Close this issue or PR with /close
Offer to help out with Issue Triage

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

/lifecycle stale

Jan 09 '22 23:01 k8s-triage-robot

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: adshmh, petr-muller To complete the pull request process, please ask for approval from spiffxp after the PR has been reviewed.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

config/prow/cluster/OWNERS
~~prow/OWNERS~~ [petr-muller]

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

Feb 08 '22 19:02 k8s-ci-robot

/remove-lifecycle stale

Feb 08 '22 19:02 adshmh

Is this looking for review again? Not sure.

Feb 14 '22 21:02 fejta

Is this looking for review again? Not sure.

Yes, would appreciate another review. Previous reviews have been addressed, in particular https://github.com/kubernetes/test-infra/pull/17142#issuecomment-788316093 and https://github.com/kubernetes/test-infra/issues/10402#issuecomment-785387313 (the latter is partially addressed, as I think a separate PR is needed to listen to /retest on commits)

Feb 14 '22 21:02 adshmh

@adshmh: PR needs rebase.

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.

Apr 22 '22 06:04 k8s-ci-robot

@adshmh: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-test-infra-unit-test	0a592221e7de92d9d314485b09a45228376c8e0c	link	true	`/test pull-test-infra-unit-test`
pull-test-infra-prow-image-build-test	0a592221e7de92d9d314485b09a45228376c8e0c	link	true	`/test pull-test-infra-prow-image-build-test`

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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.

Jul 18 '22 17:07 k8s-ci-robot

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:

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 or PR as fresh with /remove-lifecycle stale
Mark this issue or PR as rotten with /lifecycle rotten
Close this issue or PR with /close
Offer to help out with Issue Triage

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

/lifecycle stale

Oct 16 '22 18:10 k8s-triage-robot

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:

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 or PR as fresh with /remove-lifecycle rotten
Close this issue or PR with /close
Offer to help out with Issue Triage

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

/lifecycle rotten

Nov 15 '22 18:11 k8s-triage-robot

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

This bot triages PRs 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 PR is closed

You can:

Reopen this PR with /reopen
Mark this PR as fresh with /remove-lifecycle rotten
Offer to help out with Issue Triage

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

/close

Dec 15 '22 19:12 k8s-triage-robot

@k8s-triage-robot: Closed this PR.

In response to this:

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

This bot triages PRs 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 PR is closed

You can:

Reopen this PR with /reopen

Mark this PR as fresh with /remove-lifecycle rotten

Offer to help out with Issue Triage

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

/close

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.

Dec 15 '22 19:12 k8s-ci-robot