gitlab CI: deploy_job fails with sudo error
(initially reported 2020-04-10 as #65549, but that ticket was accidently deleted)
The deploy_job in gitlab fails:
$ sudo salt-call event.fire_master $CI_DEPLOY_PASSWORD salt/fileserver/gitfs/update 00:00 We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. sudo: no tty present and no askpass program specified ERROR: Job failed: exit status 1
Please add the needed sudo rule on the CI runners.
(follow-up comment from 2020-04-10)
on gitlab-runner2, you'll also need to
zypper in sudo
#1 Updated by cboltz over 1 year ago
- Private changed from Yes to No
The sudo rules were fixed in the meantime, but there's still a sudo problem on gitlab-runner2:
Running with gitlab-runner 12.8.0 (1b659122) on gitlab-runner2 W4mGsqz7 [...] $ sudo salt-call event.fire_master $CI_DEPLOY_PASSWORD salt/fileserver/gitfs/update 00:02 /bin/bash: line 89: sudo: command not found ERROR: Job failed: exit code 1
See https://gitlab.infra.opensuse.org/infra/salt/-/jobs/8171 for the full log.
gitlab-runner1 works without problems.
#2 Updated by RicardoFelipeKlein over 1 year ago
- Assignee changed from RicardoFelipeKlein to cboltz
I have added the shell executor to gitlab-runner2, but it seems that it already used gitlab-runner1 to execute the deploy, in this pipeline "https://gitlab.infra.opensuse.org/infra/salt/pipelines/1691" the deployment job "https://gitlab.infra.opensuse.org/infra/salt/-/jobs/8206" went to gitlab-runner1 while the rest went to gitlab-runner2.
cboltz, can you confirm that it is now working in the correct way?