"Could not connect to the CI server" for master-only MR with previous branch pipeline run without master restriction

I did my best to search for the error message, and none of the existing issues appear to be match my repro steps.

Summary

User receives Could not connect to the CI server. Please check your settings and try again when trying to create a merge request with .gitlab-ci.yml file with only only: - master builds steps. Issue only occurs if a prior pipeline run has executed and then .gitlab-ci.yml is changed; i.e. creating a new empty project with an identical .gitlab-ci.yml file works fine.

Steps to reproduce

  1. Create empty project, and turn on Only allow merge requests to be merged if the pipeline succeeds flag in Settings.
  2. Push initial version of master branch (give it an empty README.md or something)
  3. Create a branch with a .gitlab-ci.yml file with the following:do:
  only:
   - master
  script:
    - echo "Hello World"
  1. Commit and push the branch
  2. Create a merge request - this should immediately be mergable - merge it
  3. Create a new branch updating .gitlab-ci.yml file with the following (remove only: - master):
do:
  script:
    - echo "Hello World"
  1. Commit and push the branch (this should trigger the first successful pipeline for the repo)
  2. Create a merge request - it should be fine and mergeable - DON'T merge it.
  3. Update the .gitlab-ci.yml file one more time with the following:
do:
  only:
   - master
  script:
    - echo "Hello World"
  1. commit and push the branch
  2. create a merge request.
  3. User sees error message, Could not connect to the CI server. Please check your settings and try again

Example Project

https://gitlab.com/ryanthecubfan/gitlab-ci-bug/merge_requests/2

What is the current bug behavior?

In step 5, the user is allowed to merge with the only: - master restriction in the only build task in .gitlab-ci.yml, while in step 12, the user is not allowed to merge with the identical gitlab-ci.yml file.

What is the expected correct behavior?

I would expect identical .gitlab-ci.yml to produce identical results, regardless of whether a branch pipeline had been run at some point previously. Consistency is the primary, goal - I would expect them to behave the same way. Ideally, I would prefer that behavior to be that both merge requests are immediately mergable.

Relevant logs and/or screenshots

(Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's very hard to read otherwise.)

Output of checks

(If you are reporting a bug on GitLab.com, write: 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

(If you can, link to the line of code that might be responsible for the problem)

Edited Aug 30, 2025 by 🤖 GitLab Bot 🤖
Assignee Loading
Time tracking Loading