Semantic release authentication precedence prevents pipeline triggers when GitLab CI_JOB_TOKEN has push permissions

Summary

When GitLab's "push with CI Job token" feature is enabled, semantic-release pushes fail to trigger pipelines even when configured with a Personal Access Token (PAT). This breaks continuous deployment workflows that depend on semantic-release triggering subsequent pipelines.

Background

GitLab recently introduced the ability to push using CI_JOB_TOKEN. As a security measure, commits pushed with CI_JOB_TOKEN intentionally don't trigger new pipelines (for now) to prevent infinite loops. However, this creates an issue with how semantic-release/gitlab handles authentication.

The Problem

semantic-release/gitlab appears to use CI_REPOSITORY_URL for git operations, which includes embedded CI_JOB_TOKEN credentials:

https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.example.com/group/project.git

Even when semantic-release is configured with a PAT (via GITLAB_TOKEN), semantic-release prioritizes the credentials embedded in the remote URL over other authentication methods. This means:

1. All pushes authenticate with CI_JOB_TOKEN instead of the provided PAT
2. GitLab correctly identifies these as CI_JOB_TOKEN pushes and skips pipeline triggers
3. Release workflows break when they depend on subsequent pipeline triggers

Current Workaround

Users can manually override the remote URL before running semantic-release:

release:
  script:
    - git remote set-url origin https://gitlab.com/${CI_PROJECT_PATH}.git
    - npx semantic-release

Impact

This affects all GitLab users who:

• Use semantic-release for automated releases
• Have "CI_JOB_TOKEN can push" enabled (increasingly common as it's a recommended security practice)
• Depend on release commits/tags triggering deployment pipelines

Additional Context

• GitLab Issue: [#560654](https://gitlab.com/gitlab-org/gitlab/-/issues/560654)
• The issue occurs because Git's credential precedence favors URL-embedded credentials over credential helpers

Testing

I'm happy to help test any proposed solutions. As a GitLab engineer, I can also provide additional context about GitLab's authentication behavior if needed.

Start by tracing semantic-release/gitlab's handling of CI_REPOSITORY_URL and GITLAB_TOKEN, then reproduce the push path with the documented git remote set-url workaround. Done means pushes use the configured PAT when present and GitLab pipeline triggers are preserved, with both credential cases verified.