Auto-comment on ECA check failure with instructions for contributors

Currently, the ECA GitHub App fails the status check on pull requests when one or more commit authors have not signed the Eclipse Contributor Agreement (ECA) or have not linked their GitHub account. However, this failure is often unclear to contributors, especially those who are new and making first-time contributions.

To improve the contributor experience and reduce the burden on project maintainers, we propose that the ECA check GitHub App automatically post a comment on the pull request when it detects a failure, clearly explaining the issue and how to resolve it.

Proposed Behavior:

When the ECA check fails on a pull request, and one or more commit authors have not signed the ECA or linked their GitHub account, the GitHub App should automatically post a comment similar to the following:

Hi @user1 @user2 — thank you for your contribution!

The Eclipse Contributor Agreement (ECA) check has failed for this pull request due to one of the following reasons:

• Your GitHub account is not linked to an Eclipse Foundation account or
• Your Eclipse account does not have a valid ECA on file

To resolve this, please:

1. Sign in or create an Eclipse Foundation account: https://accounts.eclipse.org/user/eca
2. Ensure your GitHub username is linked to your Eclipse account
3. Complete and submit the ECA form

Once done, push a new commit (or rebase) to re-trigger the ECA validation.

If you believe you’ve already completed these steps, please double-check your account settings or report an issues to Eclipse Foundation Helpdesk.

Thanks again for your contribution!

marked this issue as blocking eclipsefdn/helpdesk#5806

Since this is for the GitHub PRs, we should be able to update the revalidation line like below.

Once all users have been updated/created, the ECA validation will need to be re-triggered to validate with the newly updated users. This can be done through pushing a commit, rebasing, or by using the status page for the current pull request.

This would allow for an easier way to trigger revalidation for the users without having to force an empty update.

mentioned in issue eclipsefdn/helpdesk#5806

assigned to @gnugomez

added team:webdev label

added webdev:java label

added statetodo label

added Feature Request label

changed due date to April 30, 2025

added statewip label and removed statetodo label

@malowe In regards to the behavior, given that this validation would be triggered on every commit, do we want to update the existing comment or create several ones?

Additionally, once the validation passes, wouldn't it be great to either remove or resolve the comment?

This will sound gross, but we will want to check existing comments. We will want to see if the user that failed validation is already mentioned in a comment. If they are, don't do anything. If they haven't been yet, add to a list of users to be mentioned in the new comment, and send 1 at the end.

mentioned in merge request !222

added statereview label and removed statewip label

Yesterday, @cguindon challenged me to consider releasing this task with a whitelist of repositories, likely excluding the community-driven ones. This would allow us to test if it works without causing spam, due to an error or something like that. Does that sound good to you @malowe?

I think that's a great idea, though use the term allow-list over whitelist for the config item when you set it up!

The general idea is we could roll this out gradually and monitor it to ensure all is well before we roll this out to all our projects.

For more background on @malowe comments regarding using allow-list over whitelist. We prefer to use inclusive naming when possible. See https://inclusivenaming.org/word-lists/ for more information!

I'll work on the patch for that

changed due date to July 31, 2025

I'm updating the due date to July 31 to allow 1.5 months for a proper progressive rollout. That said, my expectation is that everything will be fully functional by that date. Any concerns?

Sounds good.

This week, I'll wrap up the changes needed for a gradual rollout. We could potentially start testing at the end of this month or early next month.