Project

General

Profile

Actions
Copy link

tickets #65585

closed

gitlab CI: deploy_job fails with sudo error

Added by cboltz almost 5 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
cboltz
Category:
Configuration management (CM)
Target version:
-
Start date:
2020-04-13
Due date:
% Done:

0%

Estimated time:

Description

(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

Actions
Copy link
 #1

Updated by cboltz almost 5 years 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.

Actions
Copy link
 #2

Updated by RicardoFelipeKlein almost 5 years 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?

Actions
Copy link
 #3

Updated by cboltz almost 5 years ago

  • Status changed from New to Resolved

As discussed on IRC, I've seen gitlab trying both runners some days ago, even if only one of them provided the shell runner.

Anyway - my tests show that it works now on both servers :-)

Thanks for fixing the CI!

Actions
Copy link

Also available in: Atom PDF