8000 feat: GitLab support with tests by jpaodev · Pull Request #1034 · SWE-agent/SWE-agent · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

feat: GitLab support with tests #1034

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

jpaodev
Copy link
Contributor
@jpaodev jpaodev commented Mar 17, 2025

Reference Issues/PRs

See also #220 #209 #162

What does this implement/fix? Explain your changes.

This issue implements GitLab Support. A previous Merge Request has existed, however used the python-gitlab library. To keep the setup minimal, the already existing requests library has been used in this version.

Additionally tests have been added to ensure functionality, as previously requested.

The Merge Requests aims to achieve GitLab support, motivated by the fact, that many developers use GitLab as an alternative solution to GitHub. Through this feature those developers can test SWE-Agent on their repositories as well.

I hope the changes are satisfactory and apologize for the huge delay to the first Merge Request! Once again big thanks for making this available for everyone to use!

@klieret
Copy link
Member
klieret commented Mar 17, 2025

Hi @jpaodev ! Thank you for this PR. I see lots of changes, it will take me a while to review this in detail.

Really appreciate that its well tested!

So here's what I think from top of my head:

  1. Basic support for problem statement/repo etc.: Looking all good, no problems. Maybe we can factor out some shared code of the copy_repo bit between the github and gitlab repo cloning. But basically as this seems to work and doesn't increase complexity, all good.
  2. OpenPR action: This class just gets a lot more complicated with this PR, which is not great. We want to keep things simple and maintainable, so this makes me uncomfortable. I think it would make more sense to have a OpenMRGitLab hook (as a separate class/file) and then add that if the open_pr action is specified and we have a gitlab repo.

Regarding 2) In run_single.py:

    @classmethod
    def from_config(cls, config: RunSingleConfig) -> Self:
        ....
        if config.actions.open_pr:
            self.logger.debug("Adding OpenPRHook")
            if isinstance(config.repo, GitHub...) 
                self.add_hook(OpenPRHook(config.actions.pr_config))
            elif isinstance(config.repo, GitLab...)
                self.add_hook(...)
        return self

So tl;dr: I'm happy to merge anything that doesn't increase the complexity of what we have and that can simply live in a separate class/file. This is true for the ProblemStabement and Repo part, but maybe not yet for the open_pr part.

@jpaodev
Copy link
Contributor Author
jpaodev commented Mar 17, 2025

Hi @jpaodev ! Thank you for this PR. I see lots of changes, it will take me a while to review this in detail.

Really appreciate that its well tested!

So here's what I think from top of my head:

  1. Basic support for problem statement/repo etc.: Looking all good, no problems. Maybe we can factor out some shared code of the copy_repo bit between the github and gitlab repo cloning. But basically as this seems to work and doesn't increase complexity, all good.
  2. OpenPR action: This class just gets a lot more complicated with this PR, which is not great. We want to keep things simple and maintainable, so this makes me uncomfortable. I think it would make more sense to have a OpenMRGitLab hook (as a separate class/file) and then add that if the open_pr action is specified and we have a gitlab repo.

Regarding 2) In run_single.py:

    @classmethod
    def from_config(cls, config: RunSingleConfig) -> Self:
        ....
        if config.actions.open_pr:
            self.logger.debug("Adding OpenPRHook")
            if isinstance(config.repo, GitHub...) 
                self.add_hook(OpenPRHook(config.actions.pr_config))
            elif isinstance(config.repo, GitLab...)
                self.add_hook(...)
        return self

So tl;dr: I'm happy to merge anything that doesn't increase the complexity of what we have and that can simply live in a separate class/file. This is true for the ProblemStabement and Repo part, but maybe not yet for the open_pr part.

Totally agree! I haven't noticed how big the file has gotten, phew! 😄
Also really looking forward to write those tests with SWEAgent in the future fully 😄

Tested both the GitHub issue / GitLab issue combinations manually (the hello world example from your repository and the one I placed on GitLab)

Let me know if the changes are fine!

Copy link
codecov bot commented Apr 4, 2025

Codecov Report

Attention: Patch coverage is 79.33526% with 143 lines in your changes missing coverage. Please review.

✅ All tests successful. No failed tests found.

Files with missing lines Patch % Lines
sweagent/run/hooks/open_pr_gitlab.py 33.60% 81 Missing ⚠️
sweagent/utils/gitlab.py 58.33% 35 Missing ⚠️
sweagent/run/run_single.py 33.33% 8 Missing ⚠️
tests/test_gitlab_integration.py 91.66% 8 Missing ⚠️
sweagent/agent/problem_statement.py 85.71% 4 Missing ⚠️
tests/test_gitlab_mr.py 92.30% 4 Missing ⚠️
sweagent/environment/repo.py 93.47% 3 Missing ⚠️
Files with missing lines Coverage Δ
tests/test_gitlab_repo.py 100.00% <100.00%> (ø)
tests/test_gitlab_run_single.py 100.00% <100.00%> (ø)
tests/test_gitlab_utils.py 100.00% <100.00%> (ø)
sweagent/environment/repo.py 83.33% <93.47%> (+9.74%) ⬆️
sweagent/agent/problem_statement.py 91.15% <85.71%> (+1.61%) ⬆️
tests/test_gitlab_mr.py 92.30% <92.30%> (ø)
sweagent/run/run_single.py 85.59% <33.33%> (-4.32%) ⬇️
tests/test_gitlab_integration.py 91.66% <91.66%> (ø)
sweagent/utils/gitlab.py 58.33% <58.33%> (ø)
sweagent/run/hooks/open_pr_gitlab.py 33.60% <33.60%> (ø)

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@klieret
Copy link
Member
klieret commented May 6, 2025

Sorry that I didn't have time to merge this yet. I'll need to review again, but it might happen only after the NEURIPS deadline. We were working a lot on https://swesmith.com/ and had to prioritize this over supporting other platforms. That being said, I think the basic support for gitlab repos is great (the PR thing yes, if it doesn't add more complexity).

@jpaodev
Copy link
Contributor Author
jpaodev commented May 8, 2025

@klieret no worries - I spotted some problems and I will test everything by hand again, because we also plan to use and present this. Very greatful for the solution overall.

Will comment if everything also works fine with subgroups!

@jpaodev
Copy link
Contributor Author
jpaodev commented May 8, 2025

@klieret ok now LGTM, tested with normal groups and subgroups (Docker ReX Deployment) and also ran jobs within GitLab CI jobs (Local ReX Deployment)

The only thing that is in the PR that bothers me is the Merge Request creation: It has no retry logic -> on my switch-openai branch I drafted a retry with Tenacity, though I'll have to check tenacity a bit to ensure there's nothing wrong

Lmk if you spot anything that's wrong! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0