Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@saschagrunert
Copy link
Member

@saschagrunert saschagrunert commented Aug 24, 2020

What type of PR is this?

/kind failing-test

What this PR does / why we need it:

The merge base is wrong for release branches. To decrease the complexity
we now just use the HEAD^ commit and assume that a PR consists of one
commit.

Which issue(s) this PR fixes:

None

Special notes for your reviewer:

git-validation is currently broken for release-1.19. So we might also
/cherrypick release-1.19

Does this PR introduce a user-facing change?

None

The merge base is wrong for release branches. To decrease the complexity
we now just use the HEAD^ commit and assume that a PR consists of one
commit.

Signed-off-by: Sascha Grunert <[email protected]>
@openshift-ci-robot openshift-ci-robot added release-note-none Denotes a PR that doesn't merit a release note. kind/failing-test Categorizes issue or PR as related to a consistently or frequently failing test. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. labels Aug 24, 2020
@openshift-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: saschagrunert

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

The pull request process is described here

Details Needs approval from an approver in each of these files:

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

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 24, 2020
@openshift-cherrypick-robot

@saschagrunert: once the present PR merges, I will cherry-pick it on top of release-1.19 in a new PR and assign it to you.

Details

In response to this:

/cherrypick release-1.19

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.

@codecov
Copy link

codecov bot commented Aug 24, 2020

Codecov Report

Merging #4112 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #4112   +/-   ##
=======================================
  Coverage   41.58%   41.58%           
=======================================
  Files         110      110           
  Lines        9042     9042           
=======================================
  Hits         3760     3760           
  Misses       4943     4943           
  Partials      339      339           

@saschagrunert
Copy link
Member Author

/retest

1 similar comment
@saschagrunert
Copy link
Member Author

/retest

@saschagrunert
Copy link
Member Author

/test e2e-aws

@openshift-ci-robot
Copy link

@saschagrunert: The following tests failed, say /retest to rerun all failed tests:

Test name Commit Details Rerun command
ci/openshift-jenkins/e2e_crun_cgroupv2 730176b link /test e2e_cgroupv2
ci/prow/e2e-aws 730176b link /test e2e-aws

Full PR test history. Your PR dashboard.

Details

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.

@umohnani8
Copy link
Member

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Aug 25, 2020
@haircommander
Copy link
Member

I am unsure of this one, though not enough to put a hold on it. I would rather we find a way to actually only check the commits that differ between upstream and HEAD. There are definite cases to have more than one commit per PR, and we risk having those not signed if we don't validate...

@saschagrunert
Copy link
Member Author

I am unsure of this one, though not enough to put a hold on it. I would rather we find a way to actually only check the commits that differ between upstream and HEAD. There are definite cases to have more than one commit per PR, and we risk having those not signed if we don't validate...

Hm I'm not sure about the git-validation in general. Do we really need it? We enforce the signing already via prow, and checking for whitespace changes is mostly done by our linters. The only thing we not check right now is the "short subject".

@haircommander
Copy link
Member

I am unsure of this one, though not enough to put a hold on it. I would rather we find a way to actually only check the commits that differ between upstream and HEAD. There are definite cases to have more than one commit per PR, and we risk having those not signed if we don't validate...

Hm I'm not sure about the git-validation in general. Do we really need it? We enforce the signing already via prow, and checking for whitespace changes is mostly done by our linters. The only thing we not check right now is the "short subject".

yeah the one whitespace fix we miss is in the actual git commit itself. though, I can't really see that being very useful. I am in favor of dropping it. wdyt @umohnani8 @mrunalp

@saschagrunert
Copy link
Member Author

I am unsure of this one, though not enough to put a hold on it. I would rather we find a way to actually only check the commits that differ between upstream and HEAD. There are definite cases to have more than one commit per PR, and we risk having those not signed if we don't validate...

Hm I'm not sure about the git-validation in general. Do we really need it? We enforce the signing already via prow, and checking for whitespace changes is mostly done by our linters. The only thing we not check right now is the "short subject".

yeah the one whitespace fix we miss is in the actual git commit itself. though, I can't really see that being very useful. I am in favor of dropping it. wdyt @umohnani8 @mrunalp

I'll propose that as another PR so that we can continue the discussion there 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. kind/failing-test Categorizes issue or PR as related to a consistently or frequently failing test. lgtm Indicates that a PR is ready to be merged. release-note-none Denotes a PR that doesn't merit a release note.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants