I just upgraded to Gitlab CE 18.6.0, and suddenly all our CI jobs are failing with the error as in subject. The runner is able to pick up the jobs, but is unable to pull down the repositories from the gitlab server, showing “fatal: could not read Username for [local gitlab HTTPS url]: terminal prompts disabled” in the job text.
What’s up? It worked yesterday. I’m not 100% sure how it works, but I think that CI_JOB_TOKEN should be getting passed to the runner, which then uses it to pull the actual repository data for building.
edit: I was able to downgrade to 17.5.2 without issue and it’s working fine now.
edit 2: I should mention that I upgraded gitlab-runner at the same time.
We had the same problem. We upgraded from 18.5 to 18.6 and updated the gitlab-runner from 18.5 to 18.6.
We had to downgrade them both back to previous versions.
We have the same issue. We updated from ‘18.5.2-ee.0’ to ‘18.6.0-ee.0’
I went to a build dir on the runner and used git remote to find the remote URL with temp token. It says (edit: this was probably wrong):
# git clone https://gitlab-ci-token:glcbt-64_REMOVEDIT@gitlab.example.nl/myrepo.git
Cloning into 'myrepo'...
remote: HTTP Basic: Access denied. If a password was provided for Git authentication, the password was incorrect or you're required to use a token instead of a password. If a token was provided, it was either incorrect, expired, or improperly scoped. See https://gitlab.example.nl/help/topics/git/troubleshooting_git.md#error-on-git-fetch-http-basic-access-denied
Edit: actually, I was in the wrong build dir… When I go the actual build dir, the git remote doesn’t have the gitlab-ci-token stanza anymore. It’s just a plain https url.
Trying to find more info.
I can try downgrading, but I’m not sure if there are DB changes that are incompatible.
Still borked for us on 18.6.1 runner.
Instead of downgrading (or doing token registration) the lazy path of nuking repos and letting it start fresh seems to be working. However, we’re also seeing a similar issue with sub modules in our main repo..
Cloning into ‘D:/bld/proj/submodule’… bash: line 1: /dev/tty: No such device or address error: failed to execute prompt script (exit code 1) fatal: could not read Username for ‘<https-self-host-url>’: No such file or directory fatal: clone of ‘<https-self-host-url>/proj-group/submodule.git’ into submodule path ‘D:/bld/proj/submodule’ failed Failed to clone ‘submodule’ a second time, aborting
Curious why all of a sudden the runner is going through this flow. Is this a credential cache issue? Why is the runner even using credential manager since it should be getting job tokens right?
This is a windows service runner, no docker or any of that fancy stuff, just gitlab-runner installed as a service with basic config. We use custom project dirs to reduce file path length / avoid some of our tooling screaming about junctions / long file names, but otherwise its quite vanilla runner setup.
I have the same problem. Upgrade to 18.6.1.1. not help.
Running with gitlab-runner 18.6.1 (b5e9c6d0) on gitlab-ubuntu eAJJ4dNo_, system ID: ******* Preparing the "shell" executor 00:00 Using Shell (bash) executor... Preparing environment 00:01 Running on gitlab-ubuntu... Getting source from Git repository 00:00 Gitaly correlation ID: ******************** Fetching changes with git depth set to 20... Reinitialized existing Git repository in /home/gitlab-runner/builds/***** fatal: could not read Username for '[here is URL]': terminal prompts disabled Retrying in 5s Cleaning up project directory and file based variables 00:00 ERROR: Job failed: exit status 1
Fix for me was to either delete your runner local repo and make sure it runs as a fresh clone OR add this to your local git config (which apparently it only sets up on the clone)