kubernetes-csi / csi-release-tools

shared build and test files used by kubernetes-csi projects
Apache License 2.0
22 stars 73 forks source link

Do full git clones in travis #36

Closed msau42 closed 5 years ago

k8s-ci-robot commented 5 years ago

@msau42: Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
msau42 commented 5 years ago

/assign @davidz627

msau42 commented 5 years ago

/release-note-none

k8s-ci-robot commented 5 years ago

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: msau42

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

The pull request process is described here

Needs approval from an approver in each of these files: - ~~[OWNERS](https://github.com/kubernetes-csi/csi-release-tools/blob/master/OWNERS)~~ [msau42] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment
davidz627 commented 5 years ago

Do we have the root cause? "depth exactly 50" is suspicious or does this mean "depth >= 50 but we only ever get to 50 before failing". Besides that LGTM @krzyzacy did you ever run into something like this before with PROW?

davidz627 commented 5 years ago

/lgtm

msau42 commented 5 years ago

cc @pohly I don't fully understand it either. Because https://github.com/kubernetes-csi/external-provisioner/pull/354 which went in right before mine succeeded.

pohly commented 5 years ago

Do we have the root cause? "depth exactly 50" is suspicious or does this mean "depth >= 50 but we only ever get to 50 before failing".

When "git clone --depth=50" happens to truncate exactly at a merge commit inside release-tools, then that commit is replaced with a grafted commit that has zero parents instead of the real two parents. That then is picked up by the test as an invalid modification of release-tools.

If we truncate at some other commit, the test passes.

@krzyzacy did you ever run into something like this before with PROW?

Prow doesn't use shallow checkouts, so no.