feat: Honor gitops in GitLab threads replies #2281
Conversation
Summary of ChangesHello @chmouel, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a significant improvement to the GitLab provider by enabling the Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Pull Request Overview
This PR enhances the GitLab provider to honor /ok-to-test commands when posted as replies within merge request discussion threads, rather than only checking top-level comments.
- Added support for processing
/ok-to-testcommands in thread replies - Enhanced ACL checking to iterate through all notes in discussion threads
- Added comprehensive E2E testing for the new functionality
Reviewed Changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
pkg/provider/gitlab/acl.go |
Modified ACL logic to check all notes in discussion threads instead of only the first note |
pkg/provider/gitlab/acl_test.go |
Added test case to verify /ok-to-test works in thread replies |
pkg/provider/gitlab/test/test.go |
Added helper function to simulate discussion threads with replies |
test/gitlab_oktotest_thread_reply_test.go |
Added E2E test to verify the new thread reply functionality |
pkg/provider/gitlab/README.md |
Removed documentation note about thread comments not being supported |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
The pull request enhances the GitLab provider to recognize the /ok-to-test command when posted as a reply within a merge request discussion thread. An E2E test was added to verify this behavior, and the README.md was updated to reflect the new capability. The code changes primarily involve modifying the acl.go file to iterate through all notes in a discussion thread, adding a new test case in acl_test.go to verify the new functionality, and creating a new E2E test file gitlab_oktotest_thread_reply_test.go.
Previously, the GitLab provider only checked the top-level comment of a discussion for the `/ok-to-test` command. This limited where the command could be effectively used. The `/ok-to-test` command is now recognized when posted as a reply within a merge request discussion thread. An E2E test was added to verify this behavior, and the `README.md` was updated to reflect the new capability. Jira: https://issues.redhat.com/browse/SRVKP-8324 Co-authored-by: Gemini <[email protected]> Signed-off-by: Chmouel Boudjnah <[email protected]>
chmouel
force-pushed
the
SRVKP-8324-feat-gitlab-honor-ok-to-test-in-thread-replies-and
branch
from
e579cdc to
d8d9ffa
Compare
1 participant
📝 Description of the Change
Previously, the GitLab provider only checked the top-level comment of a discussion for the
/ok-to-testcommand. This limited where the command could be effectively used. The/ok-to-testcommand is now recognized when posted as a reply within a merge request discussion thread. An E2E test was added to verify this behavior, and theREADME.mdwas updated to reflect the new capability.👨🏻 Linked Jira
Jira: https://issues.redhat.com/browse/SRVKP-8324
🔗 Linked GitHub Issue
Fixes #
🚀 Type of Change
fix:)feat:)feat!:,fix!:)docs:)chore:)refactor:)enhance:)deps:)🧪 Testing Strategy
🤖 AI Assistance
If you have used AI assistance, please provide the following details:
Which LLM was used?
Extent of AI Assistance:
Important
If the majority of the code in this PR was generated by an AI, please add a
Co-authored-bytrailer to your commit message.For example:
Co-authored-by: Gemini [email protected]
Co-authored-by: ChatGPT [email protected]
Co-authored-by: Claude [email protected]
Co-authored-by: Cursor [email protected]
Co-authored-by: Copilot [email protected]
**💡You can use the script
./hack/add-llm-coauthor.shto automatically addthese co-author trailers to your commits.
✅ Submitter Checklist
fix:,feat:) matches the "Type of Change" I selected above.make testandmake lintlocally to check for and fix anyissues. For an efficient workflow, I have considered installing
pre-commit and running
pre-commit installtoautomate these checks.