Purpose

This pull request fixes a bug where python-semantic-release fails to create releases on self-hosted GitLab instances that use self-signed or internally-issued SSL certificates.

When the insecure = true flag is set in pyproject.toml, the release process currently fails with an SSLCertVerificationError, preventing users from publishing releases in their private GitLab environments. This PR ensures that the insecure flag is correctly honored.

Solves: requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed when running semantic-release publish against a self-hosted GitLab instance.

Rationale

The root cause of the issue is that the allow_insecure parameter in the semantic_release.hvcs.gitlab.Gitlab class was not being passed down to the underlying python-gitlab client.

The gitlab.Gitlab constructor accepts an ssl_verify parameter, which defaults to True. The python-semantic-release wrapper did not utilize the allow_insecure flag to modify this behavior. As a result, the python-gitlab client always attempted to verify SSL certificates, regardless of the user's configuration in pyproject.toml.

The solution is to explicitly pass ssl_verify=not allow_insecure during the initialization of the gitlab.Gitlab client within semantic_release/hvcs/gitlab.py. This directly connects the configuration option to the client's behavior, making the insecure flag work as intended.

Workarounds like setting REQUESTS_CA_BUNDLE or GITLAB_SSL_VERIFY environment variables were considered but are less ideal as they require extra configuration in the user's CI/CD environment rather than fixing the bug at its source.

How did you test?

This change was validated through manual end-to-end testing in a CI/CD environment that replicates the original issue.

Methodology:

1. Forked the Repository: Created a fork of python-semantic-release and applied the code change on a new branch.
2. CI Pipeline Setup: Configured a GitLab CI pipeline to run against a self-hosted GitLab instance using a self-signed certificate.
3. Configuration: The pyproject.toml file was configured with the following remote settings:

   [tool.semantic_release.remote]
   type = "gitlab"
   insecure = true
   gitlab_url = "https://your.self-hosted.gitlab"

4. Installation: The CI job was modified to install python-semantic-release directly from the forked Git repository and branch.

   - uv pip install "git+https://github.com/your-username/python-semantic-release.git@fix/gitlab-ssl-verify"

5. Execution: Ran the semantic-release publish command.
6. Validation:
   • Before Fix: The pipeline failed with the SSLCertVerificationError.
   • After Fix: The pipeline successfully executed the publish step, creating a new release in the self-hosted GitLab project.

No edge cases were identified, as this change simply wires a boolean flag to its intended destination. Existing unit tests continue to pass.

How to Verify

A reviewer can verify this fix by following these steps:

1. Check out this PR branch locally.
2. Set up a test environment pointing to a self-hosted GitLab instance that uses a self-signed or non-publicly trusted SSL certificate.
3. In a test project, configure pyproject.toml as follows:

   [tool.semantic_release]
   # ... other settings
   [tool.semantic_release.remote]
   type = "gitlab"
   gitlab_url = "https://your.gitlab.instance"
   token = { env = "GITLAB_TOKEN" }
   insecure = true

4. Install this patched version of python-semantic-release.
5. Run semantic-release publish.
6. Expected Result: The command should complete successfully, creating a release on the GitLab instance without any SSL errors. To confirm the failure, run the same command on the main branch, which should fail with the SSLCertVerificationError.

PR Completion Checklist

• Reviewed & followed the Contributor Guidelines
• Changes Implemented & Validation pipeline succeeds
• Commits follow the Conventional Commits standard and are separated into the proper commit type and scope (recommended order: test, build, feat/fix, docs)
• Appropriate Unit tests added/updated
• Appropriate End-to-End tests added/updated
• Appropriate Documentation added/updated and syntax validated for sphinx build (see Contributor Guidelines)