feat(Gitlab): Updated gitlab integration and seer docs #18383
feat(Gitlab): Updated gitlab integration and seer docs #18383sfanahata wants to merge 4 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
billyvg
left a comment
There was a problem hiding this comment.
I don't think we need to clarify MR in places where we mention PR but it's probably fine in Gitlab only sections. No strong opinion though and I'm biased as a GitHub user
| Set up Issue Autofix in your organization or on specific projects: | ||
|
|
||
| 1. Connect to GitHub through the [Sentry GitHub integration](/integrations/source-code-mgmt/github/). You can follow the steps in [Seer settings](https://sentry.io/orgredirect/organizations/:orgslug/settings/seer/) to get started. **Note:** Seer can only be integrated with the cloud version of GitHub. | ||
| 1. Connect to GitHub through the [Sentry GitHub integration](/integrations/source-code-mgmt/github/) or Gitlab through the [Sentry GitLab integration](/integrations/source-code-mgmt/gitlab/). You can follow the steps in [Seer settings](https://sentry.io/orgredirect/organizations/:orgslug/settings/seer/) to get started. **Note:** Seer supports GitLab.com and GitHub.com (cloud versions only). |
|
|
||
| Seer always performs root cause analysis and solution planning using its own internal tools and Sentry context. At the final code generation step, instead of having Seer generate the code fix directly, you can hand off to an external coding agent for implementation. Seer passes along the root cause and solution plan so the coding agent can act on them. This lets you leverage the strengths of specialized code generation tools while still benefiting from Seer's debugging and analysis. | ||
|
|
||
| When your codebase is connected via GitLab, Seer will open a merge request instead of a pull request. Coding agent handoff (Claude Code, Cursor) works the same way regardless of SCM provider. |
There was a problem hiding this comment.
This seems like kind of a random spot to mention it. I think it's better somewhere higher up where we first reference a PR or Pull Request. And just clarify that we use the term Pull Request everywhere in app but it is equivalent to Merge Request in Gitlab terminology
|
|
||
| ### GitLab Permissions | ||
|
|
||
| For GitLab, Code Review uses the permissions granted during the [GitLab integration setup](/integrations/source-code-mgmt/gitlab/#install). The service account used for installation needs at least Maintainer access to the repositories you want Code Review to run on. |
There was a problem hiding this comment.
I wonder if we should expand on the service account and explain our recommendation to create a new Gitlab account that will be used as a service account and that code reviews will be made under the account that was used to install the webhook in Gitlab.
DESCRIBE YOUR PR
Updates gitlab and seer docs for early release of the gitlab seer integration.
IS YOUR CHANGE URGENT?
Help us prioritize incoming PRs by letting us know when the change needs to go live.
SLA
Thanks in advance for your help!
PRE-MERGE CHECKLIST
Make sure you've checked the following before merging your changes: