release-tools fails on verifying subtree changes

[gnufied]

@pohly looks like when we re-merged release-tools it broke the tooling needed for ./verify-subtree.sh and it finds "unmerged" commits and hence build is broken.

[pohly]

Indeed, the fix doesn't work because it couldn't undo the merging of PR #17 . The check isn't prepared for the situation we have now (old commits which touch 'release-tools'). The fastest solution would be to rewrite history. Not nice, but simpler than trying to change the check.

I've prepared a new master branch here: https://github.com/pohly/external-resizer/tree/master-clean

@msau42 if you agree, can you pull that branch and force-push it as external-resizer master?
@gnufied once that is done, PRs need to be rebased onto it.

Short post-mortem:

• Better enable TravisCI before introducing a potentially broken .travis.yml. I think TravisCI is intelligent enough to just skip branches which don't have it. Both PR Add release tools #17 and PR fix release tools #18 would have been prevented by that.
• Always add 'release-tools' as described in the csi-release-tools/README.md.
• When pointing me to a PR, make sure that I get the chance to actually comment before it gets merged (usually this means keeping it open for a day, due to the time zone difference).

The last one is perhaps a bit tricky. I suspect PR #17 got merged unintentionally as soon as @mlmhl added a /lgtm, because it was submitted by a project maintainer and thus automatically approved. An explicit /hold probably would have worked, but I wonder whether we really want this auto-approval feature. It is a bit unexpected.

[gnufied]

Third is a problem for all projects across k8s I guess. It is always tricky when project maintainers submit a PR.

Who has force push access to this repository? @msau42 do you?

[pohly]

These command should do it:

git clone git@github.com:kubernetes-csi/external-resizer.git
cd external-resizer
git fetch git@github.com:pohly/external-resizer.git master-clean
git diff FETCH_HEAD..origin/master # no output expected!
git push origin +FETCH_HEAD:refs/heads/master

[gnufied]

I have been thinking some more about it. Does it make sense to use a content based diff for verifying subtree changes rather than git log based one? Something like:

git remote add csi-release-tools_root https://github.com/kubernetes-csi/csi-release-tools.git
git fetch csi-release-tools_root
git diff remotes/csi-release-tools_root/master HEAD:release-tools/

It does mean all CSI repos must have latest version of release-tools.

[pohly]

@msau42 the alternative to a force push is:

• merge verify-subtree.sh: relax check and ignore old content csi-release-tools#8
• git subtree pull in external-attacher
• create + merge PR in external-attacher

[gnufied]

this is not immediately fixed by linked PR. we still have to probably pull the change.

/reopen

[k8s-ci-robot]

@gnufied: Reopened this issue.

In response to this:

this is not immediately fixed by linked PR. we still have to probably pull the change.

/reopen

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.