Infrastructure/11405 gemini automation

[eugene-manuilov]

Summary

Addresses issue:

• Add Gemini AI automation to implement issues #11405

Relevant technical choices

PR Author Checklist

• My code is tested and passes existing unit tests.
• My code has an appropriate set of unit tests which all pass.
• My code is backward-compatible with WordPress 5.2 and PHP 7.4.
• My code follows the WordPress coding standards.
• My code has proper inline documentation.
• I have added a QA Brief on the issue linked above.
• I have signed the Contributor License Agreement (see https://cla.developers.google.com/).

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Code Reviewer Checklist

• Run the code.
• Ensure the acceptance criteria are satisfied.
• Reassess the implementation with the IB.
• Ensure no unrelated changes are included.
• Ensure CI checks pass.
• Check Storybook where applicable.
• Ensure there is a QA Brief.
• Ensure there are no unexpected significant changes to file sizes.

Merge Reviewer Checklist

• Ensure the PR has the correct target branch.
• Double-check that the PR is okay to be merged.
• Ensure the corresponding issue has a ZenHub release assigned.
• Add a changelog message to the issue.

[aaemnnosttv]

Thanks @eugene-manuilov, this is a good start, just a few things to address and consider.

[aaemnnosttv]

Will this run our pre-commit checks? If so, the message needs to end in a full-stop, but also what if lint-staged errors are raised? Should we have the prompt attempt a test commit which can be undone at the end so any issues that are raised can be fixed automatically?

[aaemnnosttv]

Since we can't further restrict the capabilities of the GITHUB_TOKEN here, we should perhaps exclude it since the model should only need read-only access which it should already have as a public repo. If it is needed, perhaps we can provide a PAT with read-only access. Pushing to the repo doesn't happen until the next step anyways so I'd think this should be ok.

[aaemnnosttv]

Can we manually run lint-staged? This can cause failures that might not be triggered by a normal lint run due to incremental rules that are added here. This applies to other places we run linting too, not just here.

[eugene-manuilov]

Good question, let's probably see how it works when i run it as a GitHub workflow, and then if we see problems, i'll update it, ok?

[aaemnnosttv]

GH CLI is already scoped to the current repo in actions, so we can probably exclude this as an argument and even tell it not to pass that. Not sure if it's possible to force externally. See https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-github-cli

[eugene-manuilov]

Sounds good, removed --repo google/site-kit-wp.

[aaemnnosttv]

This would probably be better to handle as a step and provide as an input rather than having the model do it.

[eugene-manuilov]

This is a slash command that we can use locally as well. If we expect it to have IB passed as an argument, then it will be less convenient to use it locally.

[aaemnnosttv]

We shouldn't do this since the body can contain details that aren't relevant, are out of date. If the issue is malformed, then it should stop.

We should actually provide the AC as well, not just the IB since the AC are more important overarching rules.

[eugene-manuilov]

Updated

[aaemnnosttv]

"in the repository" could mean remotely, where I think we mean locally, in the checked out repository / working directory. We don't want the model to make any changes in the actual repository. This is mentioned below too but we should avoid any ambiguity about this.

[eugene-manuilov]

Updated