Skip to content

Conversation

@heoyongun
Copy link
Contributor

@heoyongun heoyongun commented Jan 21, 2026

User description

Summary

When using private_token authentication (GITLAB.AUTH_TYPE = "private_token"), the ssl_verify setting was not being passed to the GitLab client constructor.

Problem

The oauth_token authentication path correctly includes ssl_verify:

if auth_method == "oauth_token":
    self.gl = gitlab.Gitlab(
        url=gitlab_url,
        oauth_token=gitlab_access_token,
        ssl_verify=ssl_verify  # ✅ Present
    )

But the private_token path was missing it:

else:  # private_token
    self.gl = gitlab.Gitlab(
        url=gitlab_url,
        private_token=gitlab_access_token
        # ❌ ssl_verify missing
    )

This caused SSL certificate verification to remain enabled even when ssl_verify was explicitly set to false in the configuration, breaking connections to self-hosted GitLab instances with self-signed certificates.

Solution

Add the missing ssl_verify=ssl_verify parameter to the private_token authentication path to ensure consistent behavior for both authentication methods.

Testing

Tested on a self-hosted GitLab instance with self-signed certificate:

  • Before fix: SSL: CERTIFICATE_VERIFY_FAILED error even with ssl_verify = false
  • After fix: Connection successful with ssl_verify = false

PR Type

Bug fix


Description

  • Add missing ssl_verify parameter to private_token authentication path

  • Ensures consistent SSL certificate handling across both auth methods

  • Fixes connections to self-hosted GitLab with self-signed certificates


Diagram Walkthrough

flowchart LR
  A["private_token auth path"] -->|missing ssl_verify| B["SSL verification always enabled"]
  C["oauth_token auth path"] -->|has ssl_verify| D["SSL verification configurable"]
  B -->|fix applied| E["Both paths now consistent"]
  D --> E
Loading

File Walkthrough

Relevant files
Bug fix
gitlab_provider.py
Add ssl_verify parameter to private_token auth                     

pr_agent/git_providers/gitlab_provider.py

  • Added ssl_verify=ssl_verify parameter to the private_token GitLab
    client initialization
  • Ensures SSL certificate verification respects the configuration
    setting for private_token authentication
  • Aligns private_token authentication behavior with existing oauth_token
    implementation
+2/-1     

When using private_token authentication (GITLAB.AUTH_TYPE = 'private_token'),
the ssl_verify setting was not being passed to the GitLab client constructor.

This caused SSL certificate verification to remain enabled even when
ssl_verify was explicitly set to false in the configuration, breaking
connections to self-hosted GitLab instances with self-signed certificates.

The oauth_token authentication path correctly includes ssl_verify, but the
private_token path was missing it. This commit adds the missing parameter
to ensure consistent behavior for both authentication methods.
@qodo-free-for-open-source-projects
Copy link
Contributor

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢
No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
🎫 No ticket provided
  • Create ticket/issue
Codebase Duplication Compliance
Codebase context is not defined

Follow the guide to enable codebase context checks.

Custom Compliance
🟢
Consistent Naming Conventions

Objective: All new variables, functions, and classes must follow the project's established naming
standards

Status: Passed

No Dead or Commented-Out Code

Objective: Keep the codebase clean by ensuring all submitted code is active and necessary

Status: Passed

Robust Error Handling

Objective: Ensure potential errors and edge cases are anticipated and handled gracefully throughout
the code

Status: Passed

Single Responsibility for Functions

Objective: Each function should have a single, well-defined responsibility

Status: Passed

When relevant, utilize early return

Objective: In a code snippet containing multiple logic conditions (such as 'if-else'), prefer an
early return on edge cases than deep nesting

Status: Passed

Compliance status legend 🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

@qodo-free-for-open-source-projects
Copy link
Contributor

PR Code Suggestions ✨

No code suggestions found for the PR.

Copy link
Collaborator

@naorpeled naorpeled left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔥
Thanks for this 🙏

@naorpeled naorpeled merged commit 1ac0e27 into qodo-ai:main Jan 30, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants