"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
- Create empty project, and turn on
Only allow merge requests to be merged if the pipeline succeedsflag in Settings. - Push initial version of master branch (give it an empty README.md or something)
- Create a branch with a
.gitlab-ci.ymlfile with the following:do:
only:
- master
script:
- echo "Hello World"
- Commit and push the branch
- Create a merge request - this should immediately be mergable - merge it
- Create a new branch updating
.gitlab-ci.ymlfile with the following (remove only: - master):
do:
script:
- echo "Hello World"
- Commit and push the branch (this should trigger the first successful pipeline for the repo)
- Create a merge request - it should be fine and mergeable - DON'T merge it.
- Update the
.gitlab-ci.ymlfile one more time with the following:
do:
only:
- master
script:
- echo "Hello World"
- commit and push the branch
- create a merge request.
- 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)