CLA check failing on sync PR due to co-authored web-based suggestion commits

[singh1203]

This is a Bug Report

Problem:
Weekly sync PR kubernetes/website#55936 (merging main into dev-1.37) is failing CLA checks due to Co-authored-by trailers on commits accepted via GitHub's web-based suggestion flow.

Root Cause:
When accepting suggestions via GitHub UI:

• The suggester becomes a co-author with their GitHub email in Co-authored-by
• No --signoff is added automatically
• EasyCLA validates co-author emails against CLA registration
• Even with correct email matching CLA, the missing signoff causes the check to fail

Impact:

• Sync PRs to dev-1.37 are blocked on CLA checks
• Requires manual CLA re-authorization for each co-author

Proposed Solution:
Require sign-off on web-based commits (GitHub feature: https://github.blog/changelog/2022-06-08-admins-can-require-sign-off-on-web-based-commits/)

Page to Update:
N/A (this is a repository configuration issue, not content)

cc: @reylejano @kernel-kun

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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-sigs/prow repository.

[kernel-kun]

This issue is also being discussed with the kubernetes org Github Admins in the following Slack Thread

[sayanchowdhury]

Enabling the required --signoff on web-based commits won't actually fix the issue I guess as because DCO/signoff and CLA are separate checks. I would dig deeper and to see how the CLA checks actually happens.

[singh1203]

After further investigation, I found that the CLA failure in the weekly sync PR was not directly related to missing --signoff on web-based commits, but rather a CLA email revocation issue.

Actual Root Cause:
When the original PR was merged into main, the co-author had signed the CLA using their corporate email. However, by the time the weekly branch sync PR (#55936) was created (merging main into dev-1.37), that corporate email had been revoked (likely due to an employer change), causing the CLA check to fail on the sync PR.

And in this case, the co-author is in the process of re-signing the CLA with an appropriate email, which should resolve the immediate blocker.

My Recommendation:
To prevent similar issues from impacting release sync PRs in the future, I'd suggest adding an advisory note in the contributor documentation, specifically around contributor employer transitions, recommending that:

• Re-sign the CLA promptly with a personal or new corporate email when changing employers.
• Ensure their CLA-registered email matches the email used in Co-authored-by trailers.

This kind of proactive guidance could help avoid blocking release-critical sync PRs (especially during active release cycles like 1.37) due to stale CLA registrations.

cc: @sayanchowdhury @kernel-kun @reylejano

[lmktfy]

We'll struggle to get contributors to do the right thing.

I have a different idea:

• track that commits were submitted using a valid CLA
• even if the CLA is revoked for the author, remember it for that commit
  • either for all commits ever
  • or for all commits in all open PRs that could merge into our upstream

That way, even if a company closes or a contributor unsigns their CLA, or perhaps even niche cases such as a power of attorney being used: we still rely on the agreement that was in effect when those commits were pushed.

[lmktfy]

I suggest:
/transfer community

Although we see this in k/website, it is a wider challenge for Kubernetes.

[kernel-kun]

/transfer-issue community

Ref. prow command

[kernel-kun]

/sig contributor-experience

Adding relevant SIG