Creating a tag in a CI/CD job with git push doesn't trigger a tag pipeline

Summary

When a new tag is created in a CI/CD job, a tag pipeline doesn't get created.

Steps to reproduce

.gitlab-ci.yml:

variables:
  COMMIT_BRANCH: $CI_COMMIT_REF_NAME
  COMMIT_TAG: $CI_COMMIT_TAG
  CUSTOM_PIPELINE: "false"

stages:
  - build
  - scan
  - test
  - cypress
  - cleanup
  - tag
  - deploy


include:
  ### DEFAULT PIPELINES ###
  - local: default.yml
    rules:
      - if: $CI_COMMIT_REF_NAME == "main"
  ### TAG PIPELINES ###
  - local: tags.yml
    rules:
      - if: $CI_COMMIT_REF_NAME !~ /^qf/ && $CI_COMMIT_REF_NAME =~ /^beta/

default.yml:

# Main branch pipeline jobs
main-branch-job:
  stage: build
  image: alpine:latest
  script:
    - echo "Running on main branch " + "$CI_COMMIT_REF_NAME"
    - echo "Commit SHA " + "$CI_COMMIT_SHA"
  rules:
    - if: $CI_COMMIT_REF_NAME == "main"

# Include other pipeline files
include:
  - local: "tagging-beta.yml"

tagging-beta.yml:

tag:beta:
  stage: tag
  retry: 0
  needs: []
  variables:
    TAG_STRING: beta/3.3-7.7/3.3.11-7.7.8.4
  script:
    - export SHA_SUFFIX=$(echo $CI_COMMIT_SHA | cut -c 1-7)
    - export TAG_STRING=$TAG_STRING/$SHA_SUFFIX
    - git tag $TAG_STRING $CI_COMMIT_SHA
    - git push origin $TAG_STRING
  rules:
    - when: manual
      allow_failure: true

Result:

Tag got created; no tag pipeline got created.

Deleting the tag and manually creating the tag creates a new tag pipeline.

Example Project

https://gitlab.com/e_munn_ultimate_group/tests/ci-tests/tag-pipelines

What is the current bug behavior?

Creating a new tag in a CI/CD job via git tag and git push doesn't create a tag pipeline.

What is the expected correct behavior?

A tag pipeline should be created.

Relevant logs and/or screenshots

When tag is created in CI/CD pipeline via git tag and pushed to the repository, only branch pipeline is created; tag pipeline isn't created.

The expectation is like in this screenshot, the branch pipeline creates a new tag, and a new tag pipeline should be created.

Screenshot_2025-09-09_at_09.50.37

Output of checks

This bug happens on GitLab.com

Results of GitLab environment info

Expand for output related to GitLab environment info 

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)

Possible fixes

Use the REST API endpoint to create the tag in the CI/CD job instead of git tag. However, CI_JOB_TOKEN doesn't have enough permissions so need to authenticate with either a personal access token, project access token or group access token.

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.

Edited by 🤖 GitLab Bot 🤖