Website: Why dev-1.18 keeps generating merge conflicts

[zacharysarah]

What's the problem?

I notice that the dev-1.18 branch repeatedly generates merge conflicts for unrelated files, often for the same file (/content/en/docs/reference/kubectl/overview.md), every time a PR merges into the branch.

Example

Here's the timeline view:

Here's the commit view:

The commit for #19008 generates merge conflicts for unrelated files:

To break this down:

1. I merged master into dev-1.18, which generated merge conflicts. https://github.com/kubernetes/website/pull/19116/commits/78193337e445629b9f72bc2920a04ead003bb6ff

2. I added a commit resolving the merge conflicts generated by https://github.com/kubernetes/website/pull/19116/commits/78193337e445629b9f72bc2920a04ead003bb6ff, and restored the branch to health. https://github.com/kubernetes/website/pull/19116/commits/4582f017e27aa19fe98068765eac4cd2f8f9078e

3. 19008 merges into dev-1.18 and generates merge conflicts for unrelated files.

This is one example of a larger pattern in dev-1.18 beginning with the erroneous merge in #19055 and subsequent attempts to repair the branch.

What will happen if we don't fix it?

I think that new merge conflicts will generate every time a feature PR merges into dev-1.18 unless every open PR based on dev-1.18 rebases.

Currently that's 32+ PRs.

How do we fix it?

Every open PR based on dev-1.18 needs to rebase.

Yes, that's a lot. Feature developers will probably grumble.

It's better than having to resolve (the same) merge conflicts every time a PR merges.

Does this seem accurate? For review:
@VineethReddy02 @jimangel @sftim @kbhawkey

[kbhawkey]

If rebasing fixes (permanently) the problem(s), then I think that is a favorable outcome.
I don't think there will be grumbling (I would gather that most developers rebase regularly).

[sftim]

Every open PR based on _dev-1.18_ needs to rebase.

Yes, that's quite a lot. It does seem like the best approach.

[zacharysarah]

@sftim @kbhawkey Thanks for the feedback.

@VineethReddy02 To make the rebase requests easier, here's some sample text to comment on open PRs:

👋 Please rebase this PR on `dev-1.18` in order to avoid merge conflicts.

Feel free to `/hold cancel` after you've rebased.

/hold

Feel free to adjust to your liking. 👍 Given the number of comments, if you're comfortable working with the GitHub API, it may be worthwhile to add comments with a script. If not, manually adding them is OK too.

[zacharysarah]

Bless this Prow. ⛵️ ☸️ 🙏 😂

[zacharysarah]

/hold cancel

[zacharysarah]

@kubernetes/sig-release @alejandrox1 👋 Heads up that this is a thing.

[sftim]

/sig release

[VineethReddy02]

Hi @zacharysarah @sftim but I already see /hold label for some other reasons by reviewers and owners. How will the behavior be if I add something like this

👋 Please rebase this PR on `dev-1.18` in order to avoid merge conflicts.

Feel free to `/hold cancel` after you've rebased.

/hold

[VineethReddy02]

/hold cancel

[sftim]

This is an issue; the /hold command and associated label are (I think) mainly for PRs.

If I'm right @zacharysarah was adding /hold here merely to show the sample text.

Prow doesn't stack /hold labelling, so if the PR is already held for one reason I would adjust the message to say something like:

Feel free to /hold cancel once the upstream code is merged and you've rebased your changes.

If you have rebased but the upstream code is not yet merged, please leave the /hold in place and
add a note to let SIG Docs know you have done that.

[VineethReddy02]

Thanks, @sftim @zacharysarah I reached out to all 31 open PR's against dev-1.18 and I see 4 PR's already with /hold label. So I don't think it should be a problem for us. However, I can try to have a close eye on them.

[justaugustus]

xref: https://github.com/kubernetes/test-infra/pull/16892
(which I think will solve a chunk of the problem here)

[jimangel]

+1 for avoiding this issue with proper dev-branch management. Closing for now.
/close

[k8s-ci-robot]

@jimangel: Closing this issue.

In response to this:

+1 for avoiding this issue with proper dev-branch management. Closing for now.
/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.