Feat: Add auto formatting bot

[georgereuben]

Description

Added a workflow bot that automatically formats a PR's file changes and raises a separate PR against that PR

How it works :

When someone comments /format-fix apply on a PR, the bot will:

• Check your code using ./gradlew check -x test to find any formatting/style issues
• Fix what it can by running ./gradlew tidy (which includes Google Java Format, EditorConfig fixes, and other style tools)
• Verify everything looks good by running the checks again
• Create a separate PR with just the formatting fixes, so you can review and merge them without mixing formatting changes with your actual code changes

Supported files:

Java, Gradle, Groovy, Markdown, properties, XML, Python, shell scripts, and batch files.
Just comment "/format-fix apply" on any PR to trigger it

Closes: Issue #14835

Test Run : Test PR

[github-actions]

This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. If the PR doesn't need a changelog entry, then add the skip-changelog label to it and you will stop receiving this reminder on future updates to the PR.

[georgereuben]

Hi @dweiss , added a workflow bot to apply formatting fixes and create a PR against a PR. Could you please review and suggest changes.

[dweiss]

This looks very interesting... and way beyond my knowledge of gh actions. What are the security implications for having these permissions in the workflow? Can somebody craft a PR that would somehow alter Lucene's main repo?

[georgereuben]

This looks very interesting... and way beyond my knowledge of gh actions. What are the security implications for having these permissions in the workflow? Can somebody craft a PR that would somehow alter Lucene's main repo?

There is a check before the workflow runs so that only users with admin or write repository permissions can trigger the bot. I have tested it in the test PR and verified that the workflow rejects the trigger command from an external actor

[rmuir]

This one needs to use a different action, one approved by apache. list:

https://github.com/apache/infrastructure-actions/blob/main/actions.yml

[georgereuben]

I tried using ana06/get-changed-files@v2.3.0, but it doesn't support issue comment triggers. So I have replaced this action with a gh cli script that would perform the same action when triggered by a comment. Please let me know if this works.

[dweiss]

Also - this should be primarily for PR authors who, after they submit the PR, find out something didn't pass the check. So it's a convenience to people who don't have permissions to the main Lucene repository. Is this what the permission check is actually verifying (sorry, it's a bit confusing with those permissions)?

[georgereuben]

Also - this should be primarily for PR authors who, after they submit the PR, find out something didn't pass the check. So it's a convenience to people who don't have permissions to the main Lucene repository. Is this what the permission check is actually verifying (sorry, it's a bit confusing with those permissions)?

Understood, thanks for the insight. I see the issue. Should I go ahead and implement a check where it will allow the PR author along with folks with admin and write access to trigger the format bot?
I think this should be fine security wise since the automated PR raised would only suggest edits for the PR raised by the person triggering it and not to the main branch. What would you suggest?

Working on the other suggestions meanwhile, I will update here soon

[github-actions]

This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. If the PR doesn't need a changelog entry, then add the skip-changelog label to it and you will stop receiving this reminder on future updates to the PR.

[dweiss]

Should I go ahead and implement a check where it will allow the PR author along with folks with admin and write access to trigger the format bot?

Yes, I think this makes sense. It's a PR against their own repository (against their PR), so I think it's fine (?).

[dweiss]

Right - thank you for working on this. It seems way more complex than I thought. Also, it entails some worrying uncertainty with respect to what can go wrong. Here's an example - I received an email today with this:

but I can't locate this "comment" anywhere on this issue. Yet it did send out an e-mail, somehow. It's kind of scary to me.

[georgereuben]

Right - thank you for working on this. It seems way more complex than I thought. Also, it entails some worrying uncertainty with respect to what can go wrong. Here's an example - I received an email today with this:
but I can't locate this "comment" anywhere on this issue. Yet it did send out an e-mail, somehow. It's kind of scary to me.

Yes sorry, I was testing the gh cli comment command locally and accidentally added this PR instead of my forked repo's PR as the target. So this test comment was posted from my id on that PR. I deleted it later, my apologies.

[georgereuben]

Hi @dweiss, I now see that it might not be possible to raise a PR against a PR raised from a branch in a forked repo since the github actions workflow will not have access to that forked repo.
The other viable solution I can see is to add a commit to the author's PR itself as this will be possible if the PR author has allowed edits by maintainers. I have been working on this but I wanted to check with you if this would be viable

[dweiss]

Yes, this could be an alternative. I initially wanted a PR because they you'd see what's changed but a commit is also fine if the change is triggered explicitly.

[georgereuben]

Hi @dweiss @rmuir, I have updated the workflow. If the PR is raised in the same repo by a maintainer, it will raise a PR with formatting fixes, and if the PR is raised from a forked repo, it will directly commit the formatting fixes to the author's PR and the author can check the commit changes.

I have updated the workflow with the rest of your suggestions as well, please review and let me know if any other improvements can be made, thanks.