How to Stop Release Jobs From Creating New Pipelines

When using Gitlab Releases in a job, It creates a new pipeline. This behavior causes a double deployment which is redundant and interfering with deployment process.

The below job would cause a new pipeline to be started out of nowhere once Gitlab creates a release. How can I prevent this behavior and just have Gitlab release in that pipeline and not move into a new pipeline?

dev-release:
  stage: dev-release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  environment:
    name: dev
  script:
    - RELEASE_VERSION=$(cat ./scripts/$RELEASE)
    - echo "RELEASE_VERSION = $RELEASE_VERSION"
  release:
    name: "v$(cat ./scripts/$RELEASE)"
    tag_name: $(cat ./scripts/$RELEASE)
    description: '${CI_COMMIT_MESSAGE} - Build: ${BUILD}'
  only:
    - main

Hi,

I don’t see how this would start another pipeline unless you have another jobs that you haven’t included here.
The simple solution is to have rules set in such a way that nothing would run on a Tag pipeline.

There are other jobs here of course. But I have never experienced a new pipeline starting up until I started using the release job.

The release job creates new Tag in your project. If you have jobs that run for tags this will trigger a pipeline.

This is new to me, “If you have jobs that run for tags this will trigger a pipeline”, the thing is, I do not set up my pipeline for this workflow so this must be a default behavior to run a new pipeline after tag/release created.

I see this solution on stackoverflow. Will try it

workflow:
 rules:
 - if: $CI_COMMIT_TAG
   when: never
 - when: always

Any job without only or except or rules runs for any branch and any tag.
So when the release job creates a Tag all jobs without any restrictions will run.

If you don’t want to run a pipeline when Tag is created, the simplest solution is to disable Tag pipelines using workflow

workflow:
  rules:
    - if: $CI_COMMIT_TAG
      when: never
    - when: always
1 Like