search

WordPress / props-bot-action

A GitHub Action for compiling a list of contributor props.
Other
13 stars 5 forks source link

Maintain bots ignore list #77

Open thelovekesh opened 8 months ago

thelovekesh commented 8 months ago

Problem

There can be chances when a bot comments on the pull request that isn't a user with login i.e. API-based hosted bot. In such cases, API will be unable to resolve the information about user login.

Originally discovered while evaluating props for a bot user on https://github.com/WordPress/performance/pull/981. See : Runner logs

Feature Request

In case the current contributor matches the name from the ignore list, simply exit the workflow gracefully.

Workaround

Add a function in the action to read a file which can be named something like props-bot-contributors-ignore.json which can contain the metadata like:

{
  "github-advanced-security": "GitHub CodeQL bot"
}

Later a message can be logged based on the above metadata and workflow can be skipped.

Repository

No response

thelovekesh commented 8 months ago

@desrosj Feel free to assign it to me in case the above feature request looks good.

desrosj commented 8 months ago

Thanks for this suggestion, @thelovekesh!

We do currently have a list of excluded users, but this one is not yet included.

I think in general, bots should never be included in the list and we can handle this list within the action. They will never be linked to a w.org account, and GitHub pre-populates the necessary Co-authored-by trailer for these bots in the suggested merge commit message. We specify that those should be left in the merge commit message in the guidelines.

What would the benefits be for your suggested approach vs. the current one?

thelovekesh commented 8 months ago

Thanks, @desrosj for the confirmation on the skip users list.

What would the benefits be for your suggested approach vs. the current one?

The current action code seems to hardcode usernames within the existing code. It's worth considering if storing such metadata directly in the code is the best approach. Perhaps, if someone needs to exclude specific users, proposing a pull request to the relevant repository might be a more flexible solution. This would facilitate easier management and updates compared to hardcoded values.

I'm noticing that the workflow at https://github.com/WordPress/performance/pull/981 encounters issues when the GitHub Rest API cannot resolve the user login. To enhance robustness, I propose decoupling the users list configuration. This way, if similar problems occur in the future, solutions can be implemented directly at the source, preventing the need to update the list within the action code in this repository. This would not only streamline maintenance but also avoid potential delays in merging pull requests due to workflow failures, especially if a "pass all workflows" merge policy is in place.