Passing [ci skip] now creates a pipeline and shows the pipeline as skipped via the UI

added 1 deleted label

This might be related to the changes Pipelines for merge request

added devopsverify priority4 severity3 typebug labels

changed the description

added Category:Continuous Integration label

added [deprecated] Accepting merge requests label

removed [deprecated] Accepting merge requests label

This behavior confuses our users, leading to complaints and internal support requests. It would be really great if we could control visibility of skipped pipelines.

changed milestone to %Backlog

added [deprecated] Accepting merge requests label

added 1 deleted label

added sectionops label

added vintage label

Hi @aholland1 👋,

Thanks for raising this bug.

Contributions like this are vital to help make GitLab a better product.

We would be grateful for your help in verifying whether your bug report requires further attention from the team. If you think this bug still exists, and is reproducible with the latest stable version of GitLab, please comment on this issue.

This issue has been inactive for more than 12 months now and based on the policy for inactive bugs, will be closed in 7 days.

Thanks for your contributions to make GitLab better!

added stale label

Hi @aholland1 👋,

Based on the policy for inactive bugs, this issue is now being closed.

If you think this bug still exists, and is reproducible with the latest stable version of GitLab, please reopen this issue.

Thanks for your contributions to make GitLab better!

closed

added auto closed label

Although the author didn't respond to the bot messages, I think this issue should not be closed. It's still appearing as described. The docs for ci.skip clearly state:

| ci.skip | Do not create a CI pipeline for the latest push. |

So I would not expect to see a "skipped" pipeline being created.

@steveazz sorry to ping you for this, but since you were the first one to respond back then, do you think this issue could be reopened (or at least reassessed)? I want to refrain from creating yet another new issue since this one already covers and contains everything.

@Gerrit-K there is no need to apologize. Thank you for lettings me know 🙇 I've reopened it but marked it as UI polish rather than a ~"bug" @v_mishra do you agree with that?

added UI polish label and removed priority4 severity3 stale typebug vintage labels

reopened

This isn't a bug, I agree with UI polish

Just to give some context this is how the pipelines show if you use [ci skip] in your commit message.

But I'd like to vote for keeping skipped pipelines in the UI and instead point users to filter out the noise if they want too. For instance if you only care about passed pipelines, you can filter for just those.

This is possible now, but was not possible when this issue was created.

@pburdette Thanks for providing screenshots and giving the hint with the filter 👍 While I do like that I can filter pipelines based on their status, it's very inconvenient for me to do that every time I visit the pipelines tab (and then I would also have to filter for every state except skipped, or is there some kind of not / inverse filter?).

I would like to raise some questions from the user perspective: When I push with [ci skip] what is the benefit of displaying those pipelines (by default)? How does it improve my usage experience and in what ways can I (or would I want to) interact with those pipelines?

it's very inconvenient for me to do that every time I visit the pipelines tab (and then I would also have to filter for every state except skipped, or is there some kind of not / inverse filter?).

Totally agreed here, we should open an issue to add the inverse filter. If that is added we can hold a url query string like https://gitlab.com/gitlab-org/gitlab/-/pipelines?page=1&scope=all&status=failed but of course with the right params. That way you don't have to perform any manual actions.

I agree with the latest comments, i think it generates a lot of noise for a very minor benefit. I don't think filtering the skipped pipelines by default is a good solution, since they bloat the UI in several places, not only the pipelines list. The skipped pipelines are still associated to their commit or tag, and it makes it harder to retrieve artifacts for those commits or tags.

Not entirely related, but there is also a bug with ci-skip which creates a pipeline that would otherwise not exist. If all your jobs are set to only trigger on a push, for example, adding a tag will not create a pipeline. However, if you add the ci.skip option to your push, a skipped pipeline will be created for the tag. I only tested that using an atomic push with commits and a tag, though, it might not be the default behavior.

Workaround

It sounds a bit stupid, but instead of using the ci.skip push option, you can use ci.variable "DO_CI='false'" and test for DO_CI in a rules:if section in all your jobs. This way a pipeline won't trigger.

If you decide as team that the skipped entries in the pipeline provide no added value and you are hosting your instance yourself a cronjob could also delete all skipped piplines on a regular basis with

gitlab-rails runner "skipped = Ci::Pipeline.skipped; skipped.find_each do |pipe|; pipe.delete; end"

I would like to add my vote to classify this as a bug and not only UI polish. Our situation:

GitLab pipeline runs from a normal push.
Within that pipeline, we bump the version of our code via git push with "[skip ci]" comment.
The push succeeds but then attempts to run a pipeline that, normally, it would just immediately complete with a status of Skipped but, this pipeline, same as executed in step 1, uses an "include". The include pulls in a .gitlab-ci.yml file from another repo that the bot user that did the push in step 2 does not have access to.

As a result, the pipeline which should have never executed or, at worst, immediately completed with a status of Skipped ends up with a status of Failed, complaining that the project referenced by the include was "not found or access denied."

Of course, none of this would have happened if the pipeline was simply really skipped, as requested, but seems GitLab attempts to load the pipeline, and all the includes, before checking to see if it should be skipped.

Ironically, all of the changes get applied to the repo (original push plus the bump-version push) but, because the last pipeline failed, the repo's badge forever says the pipeline has failed and, of course, we end up with double the number of pipelines in the the history that we want, half of which always show a failure.

Large Premium Self-Managed customer is interested in this issue. They note that they would like to avoid generating the extra noise of skipped pipelines.

I have suggested these two workarounds in the meantime:

Internal ZD ticket: https://gitlab.zendesk.com/agent/tickets/248689

added customer label

This bug (or UI noise) also affects the MR screen, i have a pipeline that runs on push and adds a commit to the branch, this commit is with "[ci skip]" but it still creates an empty pipeline, this means that instead of seeing the latest pipeline in the MR screen i see a skipped pipeline in the ui (even though i would like to see the status of the last pipeline that ran)

Hi @cboittin

I couldn't successfully skip the pipelines with your workaround. Maybe, I'm not doing it right. Could you please support here ?

Following are the steps, I did.

Defined global variable for "DO_CI".

variables:
  DO_CI: "true"

Defined global variable for "DO_CI".

build:
  stage: build
  script:
    - git push -o ci.variable="DO_CI='false'" --follow-tags origin HEAD:${CI_DEFAULT_BRANCH}
  rules:
    - if: $CI_DEFAULT_BRANCH
    - if: '$DO_CI == "true"'

Hope, there will be a fix for this issue soon.

Not sure, i haven't tried since a month ago so maybe something changed on gitlab's side, but that would be weird. Maybe the order is wrong or the rules section doesn't like having 2 ifs ?

I push with the following command :

git push --atomic origin $env:STAGING_BRANCH $NEW_VERSION_TAG --push-option ci.variable="DO_CI='false'"

and my build stage looks like this :

build:
  stage: build
  rules:
    - if: '$CI_COMMIT_BRANCH == $DEVELOP_BRANCH && $DO_CI == "true"'
  script:
    # ...

Also verify that your other stages have the DO_CI check, otherwise there's a chance they might spawn, i think.

Because of the way you used your rules:

 rules:
    - if: $CI_DEFAULT_BRANCH
    - if: '$DO_CI == "true"'

instead of:

rules:
    - if: '$CI_COMMIT_BRANCH == $DEVELOP_BRANCH && $DO_CI == "true"'

It is checking if the branch is default, and since that is true, it proceeds. Rules are a little bit unintuitive in my opinion. When in list for, the are treated like or statements, not and.

Note that the global workflow:rules can also be used to avoid running the pipeline. This was easier to add to a workflow rather than having to add an additional job rule for each job in the workflow. Additionally, in my specific case, we could match against a branch name, but this should also work for the push options listed above.

Our workflow rules look like the following, but you'll have to make sure you're including all pipeline sources that your workflow is using to make sure at least one of them matches:

# prevent pipeline running for airflow sync branches and allow it in other cases
workflow:
  rules:
    - if: $CI_COMMIT_BRANCH =~ /^airflow\/(dev|test|ops)$/ # skip CI for airflow sync branches
      when: never
    - if: $CI_PIPELINE_SOURCE == "push"
    - if: $CI_PIPELINE_SOURCE == "web"
    - if: $CI_PIPELINE_SOURCE == "schedule"

added severity3 label

added 1 deleted label

Not sure if I need to put this in a separate issue.

This is also problematic from an artifacts standpoint of view. Skipped pipelines are marked as latest and that means you lose artifacts from the actual latest pipeline if you have enabled "Keep artifacts from most recent successful jobs". I suggest skipped pipelines are not marked as the latest.

As we use maven release to add new snapshots, this also mess with the pipeline badges.

This issue bring problem to our pipeline. We configured webhook which triggered by "Pipeline Events" and "Job Events". the skipped pipeline will trigger the webhook. But unfortunately the third system marked this skipped pipeline with failed status, and we will receive notifications.

Link to request: https://gitlab.my.salesforce.com/0016100001Eo9BF - 1300 seats GitLab Premium
Why we are interested: Some CI jobs push back changes to GitLab using the [ci skip] parameter and also some documentation only commits are performed that way. Sadly all of these interactions cause skipped pipeline entries in the UI and MR views.
Current solution for this problem: In some case we just live with the problem, in other cases we use the already above discussed workarounds via CI rules causing quite bloated pipeline definitions.
How important to us: Besides the simple UX problem (that might be debatable) the real pain has its origin in MR views and the artiacts handling where skipped pipelines are shown and considered as latest. This causes e.g. MR's to display the latest skipped pipeline instead of for example the last real successful pipeline.
Questions: None - in our honest opinion we would prefer if skipped pipelines are not created at all.
PM to mention: @jreporter
CSM: @sbrienen
cc: @RolandGabriel @alex-dess

Adding another "voice" or vote towards classifying this as bug, and not just UI noise.

Our usecase: We have a repo with only one Job. Within that Job, when doing the commits with [ci skip], and after that a push with the "-o ci.skip" option, it still creates a "Skipped", empty pipeline without any jobs.

This doesn't happen if I manually do, say, a commit that doesn't fall within the "if" rules of the only Job we have. So why with the [ci skip] is creating an empty, skipped pipeline? Not sure what would be the rationale behind that, or why anyone would expect that pipeline to be created in such usecases 🤔

Is it possible to save the filter options we set so that we don't have to manually set them every time?

Another customer here, we are also running into problems regarding this behaviour

We are using the gitlab-ci-pipelines-exporter to export metrics of our pipelines and use alerting to detect if pipelines are failing.

Before this change, we were able to determine the status of all projects by looking at the latest pipeline of a project.

Some of our projects are "self-modifying":

a "software project" is build and released
the "sofware project" the publishes the artifacts (typically docker images) into central repository
then the "software project" triggers the "deployment project" via downstream piplines

The child pipeline in the "deployment project" now starts:

first it will persist the newly released version in the source repository
it pushes back the changes to the repository using [ci-skip]
then the regular deployment runs

Now - if the deployment fails we would expect that the latest pipeline is failing and our alerts should notify the reponsible admin. Since the [ci-skip] are producing pielines which are marked skipped we no longer see the failing pipeline in the monitoring.

Hi, what is the current working workaround on gitlab.com ? thanks

mentioned in issue #403065 (closed)

marked this issue as related to #403065 (closed)

I think the behavior with ci.skip seems indeed buggy and can lead to side effects. I have a simple repro showing the erratic behavior when using this push option (or adding it to commit subject).

Create a new project with the following .gitlab-ci.yml

stages:
  - build

build:
  stage: build
  image: alpine:3
  script:
    - echo "Running"
  rules:
    - if: $CI_COMMIT_BRANCH

If you simply push commits, the build job will be triggered as expected
If you push a commit with the ci.skip option, the pipeline will appear as Skipped which, again, is expected because our CI defines a job that is meant to be run on branches but we explicitly tell it not to
If you create a tag and push it, no jobs will appear. It is also expected because we don't specify any jobs with rules related to CI_COMMIT_TAG
Now if you push a tag with the ci.ckip option (or if the tag refers to a commit with with a [skip ci] subject), a Skipped pipeline pops up the pipeline view. This is NOT expected (at least for me) as no jobs related to tags are defined in our CI.

I also noticed a similar behavior with merge request pipelines:

Create a new branch, push some commits and open a merge request
If you push subsequent commits to the new branch, the build job will be triggered normally as expected
If you push a commit with the ci.skip option, the pipeline is duplicated. One pipeline is displayed as Skipped and is a branch pipeline type. That's expected. The other pipeline instance is shown as Skipped and is displayed as a merge request pipeline type. That is NOT expected as our CI does not define any job based on merge_request_event

This can be problematic with workflows using tools like semantic-release which add additional commits and tags using the ci.skip option. As @libsamek pointed out, the skipped pipelines end up being tagged as latest and options like Pipelines must succeed in MR context become useless especially if you do have real merge_request_event jobs in your CI.

Maybe I miss something here or have a wrong understanding of how pipeline definition works in this specific case. Anyway, this behavior definitely begs questions.

Agree this should be classify as a bug. A failed pipeline will trigger a successful "skipped" pipeline, which is confusing.

A different workaround would be to use a custom tag for the same purpose and edit .gitlab-ci.yml for using the rules in the workflow section to avoid creating the pipeline at all when this tag is present on the commit message. Example of a custom [skip_pipeline] tag:

workflow:
  rules:
    - if: $CI_COMMIT_MESSAGE =~ /(?i)\[skip[ _-]pipeline\]|\[pipeline[ _-]skip\]/
      when: never
    - if: $CI_PIPELINE_SOURCE == "push" || $CI_PIPELINE_SOURCE == "merge_request_event" && $CI_PIPELINE_EVENT == "push" || $CI_PIPELINE_EVENT == "merge"
      when: always

Related to #320960 (CI SKIP doesn't stop linting) and #287625 (CI SKIP creating a skipped pipeline means latest isn't useful for dashboards)

added sectionci label and removed sectionops label

mentioned in merge request ccns/neurocog/neurodataops/anc/pipelines/anc-data-acquisition!48 (merged)

removed 1 deleted label

mentioned in issue smilecdr-public/smile-dh-helm-charts#179 (closed)

When using semantic-release it's necessary to use [skip ci] in order to avoid an infinite loop triggered by the automatic commits done by the library.

I've tried many combinations to avoid these Skipped pipelines to be triggered since they add a lot of noise to my UI, without success unfortunately.

Would like this issue to please not to be forgotten, since it's been aprox. 4 years where these issues started and until now apparently they're persisting.

Hello,
We have been struggling with this issue for years as well.

I fully agree with #28369 (comment 1523233009): skipped pipelines are created in gitlab UI in cases we don't expect them at all, and this should be considered a bug.

For example: if we completely disable merge request pipelines at workflow level, we still get a skipped merge request pipeline when pushing with ci.skip, which completely blocks merge requests because a branch pipeline will not take over merge request pipeline as head of MR.
So far, we had a workaround using an external status badge, but this was considered a bug and fixed in recent gitlab releases, so it does not work anymore. Consequently, there is no way around this issue, other than waiting for and deleting the skipped MR pipeline before starting a new branch pipeline, which is a huge pain in the neck.

Looking into gitlab code, it seems this "always create skipped pipeline" feature has been implemented as a performance optimization to avoid parsing the entire yml, which is reasonably understandable.

However, there are still use cases where we do NOT want to see a skipped pipeline, in particular, if you want to start a new pipeline with API right after a push with ci.skip.

If the current behavior of ci.skip cannot be modified, then we would like to have another possibility like "ci.skip_pipeline", that would not only skip the pipeline, but also skip the creation of the skipped pipeline in UI (similar to what has been proposed in #28369 (comment 1598782834)).

mentioned in merge request !163329

added typebug label

added priority3 label

added UX label

Passing [ci skip] now creates a pipeline and shows the pipeline as skipped via the UI

Designs

Child items 0

Activity

Workaround

Passing [ci skip] now creates a pipeline and shows the pipeline as skipped via the UI

Relates to

Activity

Workaround