New rules syntax and detached pipelines

Since GitLab is deprecating the use of only/except in CI configs, I’ve been making changes to my gitlab-ci.yml files.

For example,

    - master

has become:

    - if: '$CI_COMMIT_REF_NAME == "master"'
      when: never
    - when: always


    - master

has become:

    - if: '$CI_COMMIT_REF_NAME == "master"'
      when: always
    - when: never

So far, the correct jobs seem to run in the MRs I’ve tried, but MR pipelines are now marked as detached whereas they weren’t previously. I’m not sure whether that is to be expected, or whether there’s a bug in my config somewhere. The deprecation notice don’t seem to mention this, although I did find an explanation of detached.

Any ideas?



1 Like

So, to answer my own question, adding this to gitlab-ci.yml has removed the duplicate detached pipelines;

        - if: $CI_MERGE_REQUEST_ID
          when: never
        - when: always

There is some documentation here.

check this out :


That’s very useful, thanks!

1 Like


thanks for bringing this to our attention. I’d like to share some updates and clarifications, including hopefully useful details too :sunglasses:

There was a misunderstanding about the term “deprecation”, sorry about that.

only/except are not deprecated

We have discussed this in the last couple of days, and have made it more clear that only/except are not deprecated. The new rules keywords allows to build more fine granular conditions and you are encouraged to use them.

CI/CD Template changes in 13.0

The real change now happens under the hood: GitLab provides several built-in templates, you may have seen that for CI config for Golang or Docker. There are also portions for the Auto-DevOps and Security CI/CD pipelines.

These config templates will be moved over the rules set in 13.0, with literally no visible change.

Important Change

rules and only/except cannot co-exist.

The transition for the Security templates is explained here:

Adjusted information

More Rules References

Design Insights

Lessons learned

  • Deprecation and Removal are strong words which may be understood and used in the wrong context.
  • Use better issue titles and avoid actions like pre deprecation or subject to deprecation anywhere else.
  • Provide migration guides and examples to allow changes by example.