Auto-merge workflow skips comment when Contributors.md has multiple line changes

[Sunil0620]

🐞 Problem
The auto_merge_prs.yml workflow has a logic gap that leaves contributors without feedback.
When a PR:

• Only modifies Contributors.md (only_contributors == 'true')
• Has more than 1-2 line changes (one_line_change == 'false')
  the auto-merge step AND the comment step are skipped in the auto_merge_prs.yml workflow, leaving contributors without any feedback from the bot.

**Example:** PR #111402 modified only Contributors.md but received no bot acknowledgment. - **Merge step** requires: `only_contributors == 'true' && one_line_change == 'true'` - **Comment step** requires: `only_contributors != 'true'` - **Gap:** When `only_contributors == 'true' && one_line_change == 'false'`, neither runs!

🎯 Goal
While Contributors.md content doesn't matter contributor experience does. This fix ensures:

• All contributors get feedback - whether their PR is auto-merged or needs review
• No silent failures - contributors understand what's happening with their PR
• Consistency - the bot responds to all PR types, not just some
• Better onboarding - new contributors aren't left confused when automation doesn't respond
  This doesn't change how Contributors.md works, it just fixes the communication gap.
  💡 Possible solutions
  Add a new step in .github/workflows/auto_merge_prs.yml after the "Merge PR" step:

- name: Post comment if Contributors.md has too many changes
  if: env.only_contributors == 'true' && env.one_line_change == 'false'
  uses: actions/github-script@v6
  with:
    script: |
      await github.rest.issues.createComment({
        owner: context.repo.owner,
        repo: context.repo.name,
        issue_number: context.issue.number,
        body: "Thank you for your pull request!  \n\nThis PR modifies Contributors.md with multiple changes. A maintainer will review it soon!\n\nThank you for your contribution! "
      })
    github-token: ${{ secrets.GITHUB_TOKEN }}

📋 Steps to solve the problem

• Comment below about what you've started working on.
• Add, commit, push your changes.
• Submit a pull request and add this in comments - Addresses #<put issue number here>
• Ask for reviews in comments section of pull request.
• Celebrate your contribution to this project. 🎉

[bhuvanakgowda]

Addresses #

[Esh07]

Hey @Sunil0620

Thank you for opening this issue! As one of the contributors to the original auto-script implementation, I appreciate the feedback.

Regarding the logic you mentioned:

Only modifies Contributors.md (only_contributors == 'true')

You are correct. This gate ensures the automation only triggers for Contributors.md changes, preventing unnecessary GitHub Action runs on unrelated PRs.

Has more than 1-2 line changes (one_line_change == 'false')

This is a common point of confusion. Most of the time, a contributor replaces a line thinking it is only '1 change,' but Git itself treats that as 1 addition and 1 deletion (2 changes total). We keep the threshold strict to prevent potential merge conflicts that could happen if we allowed larger automated merges.

Has more than 1-2 line changes (one_line_change == 'false')
the auto-merge step AND the comment step are skipped in the auto_merge_prs.yml workflow, leaving contributors without any feedback from the bot.

Better onboarding - new contributors aren't left confused when automation doesn't respond
This doesn't change how Contributors.md works, it just fixes the communication gap.

You've brought up a very solid perspective here. In a previous version of the script, we actually did have a comment that explained the status and how to reset/revert changes. However, the instructions were too complicated and not beginner-friendly, so we decided to remove it.

You can see that discussion here:

• Enhanced Auto-PR: Add profanity filter, assign review tag to PRs with multiple file changes and more... #73431 (you can check testing section where I mentioned of it)

Add a new step in .github/workflows/auto_merge_prs.yml after the "Merge PR" step:
I agree that adding a specific feedback step is an excellent idea. Many new contributors are currently left without any status updates when their PR falls into this "gap."

I have actually upgraded the script to the latest version and included a fix for this exact case to improve the communication gap. You can check the submitted PR here:

• [v3 Auto Merge Script] Upgraded Github Action script version and converted bash script to optimised js code #111192

Feel free to take a look at the PR and let me know if anything can be done in a better way.

Thanks again for helping improve the project!

[Sunil0620]

Hey @Esh07

Thank you so much for the detailed explanation and context! I really appreciate you taking the time to walk me through the history and reasoning behind the current implementation.

I completely understand the reasoning behind the strict threshold (1 addition, 0 deletions) to prevent merge conflicts - that makes total sense. And thanks for sharing the link to #73431 - it's really helpful to see the evolution of the script and why the previous comment approach didn't work out.

I'm glad to hear that you've already been working on solving this communication gap! I just reviewed PR #111192, and I'm impressed with how thoroughly you've addressed this issue. The new implementation:

Handles (only Contributors.md with multiple line changes)
Provides clear, actionable feedback to contributors
Uses REQUEST_CHANGES review to signal what needs fixing
Includes a helpful diff preview for small changes

This is exactly the kind of contributor experience improvement I was hoping for.

I did notice a small typo in the variable names "(isMutliple instead of isMultiple)", but otherwise the implementation looks solid.

Thanks again for already being ahead of this and for your continued work on improving the project. I'm excited to see this merged!!.

[Esh07]

Hi @Sunil0620 thank you for your time and feedback.

That's spot on!

I have updated PR and here is the commt 7716c8f