Question 46655 in Debian Question posted in
The oficial documentation can be found here.

Gitlab jobs failling (sudo: command not found OR Failed to fetch) – Debian

I am using Gitlab Jobs to deploy a tool. The code below returns sudo: command not found. If I remove the sudo I get the following:

W: Failed to fetch http://deb.debian.org/debian/dists/stable/InRelease  Could not connect to deb.debian.org:80 (199.232.138.132), connection timed out
W: Failed to fetch http://security.debian.org/debian-security/dists/stable-security/InRelease  Could not connect to security.debian.org:80 (151.101.130.132), connection timed out Could not connect to security.debian.org:80 (151.101.66.132), connection timed out Could not connect to security.debian.org:80 (151.101.2.132), connection timed out Could not connect to security.debian.org:80 (151.101.194.132), connection timed out
W: Failed to fetch http://deb.debian.org/debian/dists/stable-updates/InRelease  Unable to connect to deb.debian.org:80:
W: Some index files failed to download. They have been ignored, or old ones used instead.
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package latex209-bin
E: Unable to locate package texlive-latex-base
E: Unable to locate package texlive-latex-extra
E: Unable to locate package ant
Cleaning up project directory and file based variables
00:01
ERROR: Job failed: exit code 1

This is the .gitlab-ci.yml file:

stages:
  - deploy
variables:
  RA_NAME: "My_project"
default:
  before_script:
    - sudo apt-get update -qq && sudo apt-get install -y latex209-bin texlive-latex-base texlive-latex-extra ant && sudo apt-get install zip unzip
    
deploy_Default:
  stage: deploy
  script:
    - sh -x deploy.sh "$RA_NAME" "$(cat RA_VERSION)"
  artifacts:
    paths:
      - "${RA_NAME}_$(cat RA_VERSION).zip"
  only:
    - master
    - dev
    - tags

This has been happening for 1 week (most likely from the Gitlab 15.0 release).
Every Job before this started to happen Passed without any problems. Now, without changing anything they all fail (even trying to rerun old ones that Passed).

I tried adding

build_image:
  script:
    - docker build --network host

and a couple of similar configurations but none of them worked.

Now my question: why sudo doesn’t work anymore without changing anything on my .gitlab-ci.yml and what can I do to solve it.
I should mention that these Jobs are triggered by commits to the branches mentioned in only. I can run them by running pipeline or rerun the ones that were already run. I am not aware of any other modality to run them. All the work with Gitlab and this Docker are done by Gitlab UI

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    I solved the problem. Before the update, without specifying any image in .gitlab-ci.yml, by default it used my company Docker Image enter image description here.

    After the update I noticed it used another one enter image description here

    I added to my .gitlab-ci.yml the following:

    image: myCompanyImage

    and now works fine as before.
    If you encounter such a problem, check the image it's using and the image used in a previous successfully run pipeline.


  2. 0

    This happens when the instance/server has networking issues. If the runner isn’t self-hosted then Gitlab should fix the problem fairly soon. If the runner is self-hosted then you’ve got networking issues. Here’s what I can propose:

    Note: Try this without sudo

    1. Select the debian mirror close to you from the debian mirror sites list
    2. Edit the sources list via nano /etc/apt/sources.list if nano is not available then use vi
    3. Change to a different mirror

    For example

    http://deb.debian.org/debian/dists/stable/InRelease // <-- remove this
http://ftp.us.debian.org/debian/dists/stable/InRelease // <-- add this
    1. Save.
    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search