kubernetes
Do not run CI tests when a PR needs rebase
What would you like to be added: I pushed a commit that needed a rebase as it had a merge conflict. https://github.com/kubernetes/kubernetes/pull/104049 The PR started the test because ok-to-test was applied.
Why is this needed:
- If a PR does have merge conflicts, not saving the CI would save resources for other PRs that do not have merge conflicts.
- It reduces the number of comments from the ci-robot for test failures as well leading to a better reviewer experience.
/sig testing
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
This should only be applied to presubmit jobs as:
- Merged PRs should not have merge conflict, so not applicable to postsubmit jobs
The GitHub PullRequest webhook event already contains Mergeable field https://github.com/kubernetes/test-infra/blob/d8035cceb460e2f65888a6c2c7afa0c77af09796/prow/github/types.go#L273 that can be used for checking whether the PR is mergeable or not. According to the documentation that this field might not have been computed but since this is the best effort, it's still better than always trigger.
The only place that need to change is in plugins/trigger, https://github.com/kubernetes/test-infra/blob/master/prow/plugins/trigger/trigger.go, should check this field right before triggering.
One thing could happen is that:
- Commit-1 passed all prowjobs
- Commit-2 has a merge conflict
So not triggering prowjobs on Commit-2 means that all prowjobs still displayed as passing, which is fine as:
- PR with merge conflict won't be merged any ways
- Tide will ensure that prowjobs run against latest commits
/help /label good-first-issue
@chaodaiG: This request has been marked as needing help from a contributor.
Guidelines
Please ensure that the issue body includes answers to the following questions:
- Why are we solving this issue?
- To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
- Does this issue have zero to low barrier of entry?
- How can the assignee reach out to you for help?
For more details on the requirements of such an issue, please see here and ensure that they are met.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.
In response to this:
This should only be applied to presubmit jobs as:
- Merged PRs should not have merge conflict, so not applicable to postsubmit jobs
The GitHub PullRequest webhook event already contains
Mergeablefield https://github.com/kubernetes/test-infra/blob/d8035cceb460e2f65888a6c2c7afa0c77af09796/prow/github/types.go#L273 that can be used for checking whether the PR is mergeable or not. According to the documentation that this field might not have been computed but since this is the best effort, it's still better than always trigger.The only place that need to change is in
plugins/trigger, https://github.com/kubernetes/test-infra/blob/master/prow/plugins/trigger/trigger.go, should check this field right before triggering.One thing could happen is that:
- Commit-1 passed all prowjobs
- Commit-2 has a merge conflict
So not triggering prowjobs on Commit-2 means that all prowjobs still displayed as passing, which is fine as:
- PR with merge conflict won't be merged any ways
- Tide will ensure that prowjobs run against latest commits
/help /label good-first-issue
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.
@chaodaiG: The label(s) /label good-first-issue cannot be applied. These labels are supported: api-review, tide/merge-method-merge, tide/merge-method-rebase, tide/merge-method-squash, team/katacoda, refactor
In response to this:
This should only be applied to presubmit jobs as:
- Merged PRs should not have merge conflict, so not applicable to postsubmit jobs
The GitHub PullRequest webhook event already contains
Mergeablefield https://github.com/kubernetes/test-infra/blob/d8035cceb460e2f65888a6c2c7afa0c77af09796/prow/github/types.go#L273 that can be used for checking whether the PR is mergeable or not. According to the documentation that this field might not have been computed but since this is the best effort, it's still better than always trigger.The only place that need to change is in
plugins/trigger, https://github.com/kubernetes/test-infra/blob/master/prow/plugins/trigger/trigger.go, should check this field right before triggering.One thing could happen is that:
- Commit-1 passed all prowjobs
- Commit-2 has a merge conflict
So not triggering prowjobs on Commit-2 means that all prowjobs still displayed as passing, which is fine as:
- PR with merge conflict won't be merged any ways
- Tide will ensure that prowjobs run against latest commits
/help /label good-first-issue
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.
@chaodaiG: This request has been marked as suitable for new contributors.
Guidelines
Please ensure that the issue body includes answers to the following questions:
- Why are we solving this issue?
- To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
- Does this issue have zero to low barrier of entry?
- How can the assignee reach out to you for help?
For more details on the requirements of such an issue, please see here and ensure that they are met.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.
In response to this:
/good-first-issue
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.
Hey @Akshit42-hue are you still working on it? I'm interested, please assign me if you don't. thanks
Hey @amirrmonfared, I am not working you can take it For assigning just write /assign and the k8s-ci-robot will assign you For reference comment
Hello @amirrmonfared this pr is already merged and probably this issue is solved please close this pr.
@amirrmonfared: You can't close an active issue/PR unless you authored it or you are a collaborator.
In response to this:
/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.
closing this as resolved by https://github.com/kubernetes/test-infra/pull/28321. Thanks @amirrmonfared /close
@SD-13: Closing this issue.
In response to this:
closing this as resolved /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.