Error job failed exit status 1 gitlab

Summary Installed gitlab ci multi runner in my c9.io vm ubuntu using this guide
Skip to content



Open


Issue created Mar 27, 2017 by DannyNeverfade @dannyneverfade

ERROR: Job failed: exit status 1 on ubuntu 14.04 when trying to build a test project

Summary

Installed gitlab ci multi runner in my c9.io vm ubuntu using this guide https://docs.gitlab.com/runner/install/linux-repository.html. Then registered runner by following the instructions using this guide https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/tree/master/docs/commands, I started the service and then I pushed a commit on my project to gitlab with .gitlab-ci.yml file, with correct syntax verified using CI LINT Page, and the script commands are tested locally and works fine, but when the pipeline runs, I always get ERROR: Job failed: exit status 1.

Steps to reproduce

On c9.io vm ubuntu blank workspace, install latest gitlab ci multi runner by following this guide https://docs.gitlab.com/runner/install/linux-repository.html and you will get that error.

Actual behavior

Gitlab ci runner throws ERROR: Job failed: exit status 1 every time when I run a job process in gitlab.

Expected behavior

Gitlab ci runner builds the project and passes the stage.

Environment description

I am using my own gitlab runner hosted in c9.io and my repo is located in gitlab.com

Gitlab runner version

Version:      9.0.0
Git revision: 08a9e6f
Git branch:   9-0-stable
GO version:   go1.7.5
Built:        Wed, 22 Mar 2017 16:29:52 +0000
OS/Arch:      linux/amd64

Gitlab runner config.toml

concurrent = 1
check_interval = 0 
[[runners]]
  name = "test-runner"
  url = "https://gitlab.com/ci"
  token = "4299126adfadf334343dfdfdfd313457889"
  executor = "shell"

OS Version

Distributor ID: Ubuntu
Description:    Ubuntu 14.04.3 LTS
Release:        14.04
Codename:       trusty

Relevant logs

dannyneverfade:~/workspace $ sudo gitlab-runner --debug run
Runtime platform                                    arch=amd64 os=linux revision=08a9e6f version=9.0.0
Starting multi-runner from /etc/gitlab-runner/config.toml ...  builds=0
Checking runtime mode                               GOOS=linux uid=0
Running in system-mode.                                                                
Configuration loaded                                builds=0
metricsserveraddress: ""
concurrent: 1
checkinterval: 0
user: ""
runners:
- name: test-runner
  limit: 0
  outputlimit: 0
  requestconcurrency: 0
  runnercredentials:
    url: https://gitlab.com/ci
    token: 4299126adfadf334343dfdfdfd313457889
    tlscafile: ""
  runnersettings:
    executor: shell
    buildsdir: ""
    cachedir: ""
    environment: []
    preclonescript: ""
    prebuildscript: ""
    postbuildscript: ""
    shell: ""
    ssh: null
    docker: null
    parallels: null
    virtualbox: null
    cache:
      type: ""
      serveraddress: ""
      accesskey: ""
      secretkey: ""
      bucketname: ""
      bucketlocation: ""
      insecure: false
      path: ""
      shared: false
    machine: null
    kubernetes: null
sentrydsn: null
modtime: 2017-03-27T14:51:20.240876357Z
loaded: true
  builds=0
Waiting for stop signal                             builds=0
Metrics server disabled                            
Feeding runners to channel                          builds=0
Starting worker                                     builds=0 worker=0
Trying to load /etc/gitlab-runner/certs/gitlab.com.crt ... 
Dialing: tcp gitlab.com:443 ...                    
Feeding runners to channel                          builds=0
Checking for jobs... received                       job=13074496 repo_url=https://gitlab.com/dannyneverfade/test-project.git runner=42991260
Failed to requeue the runner:                       builds=1 runner=42991260
Running with gitlab-ci-multi-runner 9.0.0 (08a9e6f)
  on test-runner (42991260)  job=13074496 project=2177565 runner=42991260
Shell configuration: environment: []
dockercommand:
- sh
- -c
- "if [ -x /usr/local/bin/bash ]; thenntexec /usr/local/bin/bash --loginnelif [
  -x /usr/bin/bash ]; thenntexec /usr/bin/bash --loginnelif [ -x /bin/bash ]; thenntexec
  /bin/bash --loginnelif [ -x /usr/local/bin/sh ]; thenntexec /usr/local/bin/sh
  --loginnelif [ -x /usr/bin/sh ]; thenntexec /usr/bin/sh --loginnelif [ -x /bin/sh
  ]; thenntexec /bin/sh --loginnelsentecho shell not foundntexit 1nfinn"
command: bash
arguments:
- --login
passfile: false
extension: ""
  job=13074496 project=2177565 runner=42991260
Using Shell executor...                             job=13074496 project=2177565 runner=42991260
Waiting for signals...                              job=13074496 project=2177565 runner=42991260
WARNING: Job failed: exit status 1                  job=13074496 project=2177565 runner=42991260
Submitting job to coordinator... ok                 job=13074496 runner=42991260
Checking for jobs... nothing                        runner=42991260

Job process output in gitlab

Running with gitlab-ci-multi-runner 9.0.0 (08a9e6f)
  on test-runner (42991260)
Using Shell executor...
Running on dannyneverfade-gitlab-runner-4624780...
`ERROR: Job failed: exit status 1`

.gitlab-ci.yml

test:
  script:
   - echo "test"

Running a local build is successful

dannyneverfade:~/workspace/test-project(master) $ gitlab-runner exec shell test
Running with gitlab-ci-multi-runner 9.0.0 (08a9e6f)
  on  ()
Using Shell executor...
Running on dannyneverfade-test-runner-4624780...
Cloning repository...
Cloning into '/home/ubuntu/workspace/test-project/builds/0/project-0'...
done.
Checking out 3a6cd3c6 as master...
Skipping Git submodules setup
$ echo "test"
test
Running after script...
Job succeeded

Источник

Содержание

  1. GitLab CI Shell Executor failing builds with ERROR: Job failed: exit status 1
  2. Interactions with this post
  3. Upload artifact fails but jobs succeeds
  4. Summary
  5. Steps to reproduce
  6. Actual behavior
  7. Expected behavior
  8. Relevant logs and/or screenshots
  9. Environment description
  10. Used GitLab Runner version
  11. Container killed while running / Output logs missing in GitLab console
  12. Summary
  13. Context
  14. Output
  15. Reproducibility
  16. More information
  17. Configuration
  18. Make it possible to control build status using exit codes
  19. Update
  20. Description
  21. Proposal
  22. Invalid configurations:
  23. References
  24. Sequencing
  25. gitlab runner выдает в конце сообщение «Очистка файловых переменных 00:01 ERROR: Job failed: exit code 1»
  26. 4 ответа
  27. Обзор
  28. Мой код
  29. Как я это исправил

GitLab CI Shell Executor failing builds with ERROR: Job failed: exit status 1

Tonight I’ve been playing around with GitLab CI’s shell executor, and my builds have been failing with this error:

After some searching online, it appeared that similar to when receiving No Such Directory , this comment noted that it’s an issue with SKEL — the solution was to delete .bash_logout from the gitlab-runner user’s home, but I also removed .bashrc and .profile .

How to work around `ERROR: Job failed: exit status 1` errors with GitLab CI’s shell executor.

Written by Jamie Tanna on Wed, 03 Jun 2020 21:13:41 BST , and last updated on Wed, 02 Mar 2022 13:34:19 UTC .

Content for this article is shared under the terms of the Creative Commons Attribution Non Commercial Share Alike 4.0 International, and code is shared under the Apache License 2.0.

Has this content helped you? Did it solve that difficult-to-resolve issue you’ve been chasing for weeks? Or has it taught you something new you’ll be able to re-use daily?

Please consider supporting me so I can continue to create content like this!

This post was filed under articles.

Interactions with this post

Below you can find the interactions that this page has had using WebMention.

Have you written a response to this post? Let me know the URL:

Do you not have a website set up with WebMention capabilities? You can use Comment Parade.

Источник

Upload artifact fails but jobs succeeds

Summary

Occasionally, after one of our build jobs is finished, it will start uploading the artifacts, and silently fail: the job succeeds but the artifacts are not uploaded and no errors are reported.

  • Jobs that depend on these artifacts then fail, which requires re-running the whole job again (as opposed to just re-running the upload)

Steps to reproduce

  • I have managed to reproduce the behavior (the helper crashing but job succeeding)
    • More details in this project https://gitlab.com/jpsamper/runner-helper-reproducer
    • In production, we usually see it when there are a lot of jobs running/uploading artifacts at the same time
      • We’ve seen it with as low as 10 jobs uploading 1.5GB zipped (4-5GB unzipped) concurrently
  • By using a custom gitlab-runner-helper with a lot more print statements, we have found that the logs stop after invoking r.client.Do (i.e. if we add a print statement right before and right after, the one right after never appears)
    • Naturally, this is the behavior when something goes wrong, when the artifact is uploaded correctly, we see both print statements

Actual behavior

If I understand correctly, the function call linked above is invoking Do from the net/http package, and that call seems to be crashing the gitlab-runner-helper with no additional error message/return code/etc.

Expected behavior

  • If an artifact upload fails, the job fails or retries
  • An informative error message too, ideally

Relevant logs and/or screenshots

When everything works as expected:

And when it doesn’t:

Environment description

  • Gitlab Runner with docker executor kubernetes executor
  • Latest docker version
  • Default config.toml

Used GitLab Runner version

We’re currently on gitlab-runner 13.3.0 but have been seeing this since at least 12.9.0

Источник

Container killed while running / Output logs missing in GitLab console

Summary

The job output is not completely displayed in GitLab console. That happened for successful and failed jobs.

Context

The script’s job simply call a bash script:

Output

The GitLab job console output the following:

As one can see, the final echo Job completed with code $exit_code did not show up. I have also seen this behavior with a successful job. When following the container with git logs -f , the output also stops in the middle of nowhere.

So, I’m not sure if sometimes the container gets killed too early, resulting in a exit code 1, or if it is a job failure in my script , since I have no way to access the error logs. Also it is possible that some flush is missing because sometime the job is still successful even if I don’t see the end of the logs.

Reproducibility

This happens with gitlab-runner 12.10.2 but:

  • it happens always on the same job (we have multiple jobs of the same size in the same stage that are running concurrently).
  • it happens only on one runner. If the job is executed on another runner (by pausing the problematic one), the job completes normally.
  • on the problematic runner, the crash occurs almost always for that job, but sometimes it passes.
  • the crash happen even if it is the only job running on the server (we have 4 executors on this runner).

I could see this happen directly: I was following the executor with docker logs -f . Suddenly, the logs stops and I get back to the shell. Then a docker logs just tell that no such container exists, meaning the runner just deleted it directly after he crashed.

More information

  • We are running GitLab 12.10.3, with 2 runners version 12.10.2.
  • The problem has also been seen on gitlab-runner 12.10.1 and 12.9.0 (but with a GitLab 12.10.3 instance)

It looks like related to our job that could be flaky, but that’s not the case (as said, this kind of error did never occured with previous GitLab versions and even with a flaky code, we should see the last echo line). Also, the same job on a stable branch (which had no modification since we updated GitLab) fails with the exact same behavior.

We updated the system’s runner and rebooted it, pruned all the containers, but nevertheless the error is still present.

At this point, it is very hard to get a deeper understanding of this problem because:

  • we have multiple other jobs with similar, even longer tests that run without any problem.
  • this same behaviour has been seen on both runners. If I shut down the runner and the job is executed by the other one, it succeeds, even with partial logs.
  • it really looks like either gitlab-runner «returns» too early, omitting some log from the container, or either kills it prematurely.
  • could it be related to #25348 (closed) ? 🤔

Configuration

We use Docker version 18.09.1, build 4c52b90 and docker-compose version 1.21.0 with the following configuration:

Источник

Make it possible to control build status using exit codes

Update

We’ve open a separate issue #273157 (closed) to explore additional ways on how to solve this issue — Please add your comments to this issue only if the proposed solution does not fit your needs

Description

It may be an interesting feature to be able to control build status using .gitlab-ci.yml and exit codes.

Proposal

Implement control for exit codes as follows, based on the list of possible ones that are supported (failed, warning, success):

script_exit_codes are applied to the job based on the first non-zero exit code encountered in the script, or the last zero if all exit codes were zero.

  • If success: is not defined, it is evaluated as success: [0] . If it is defined, and you want 0 to be a success, it must be included in your array.
  • If warning: is not defined, it is evaluated as warning: []
  • If canceled: is not defined, it is evaluated as canceled: []
  • If a job is set to allow_failure: true , all failure states will be also treated as warnings.

Invalid configurations:

The following configuration should be considered invalid and a syntax error should be returned because of duplicate values ( 1 in this case). Both success and warning should have mutually exclusive values.

References

Idea from @ayufan during Slack conversation 🙂

Sequencing

  1. Add script_exit_codes to the YAML keywords
  2. Include script_exit_codes in the /request jobs response
  3. Add support for canceled state. This should already be done as part of gitlab-runner#4843
  4. The runner should compare the exit code with the ones defined in script_exit_codes (if available) before sending the status.

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Источник

gitlab runner выдает в конце сообщение «Очистка файловых переменных 00:01 ERROR: Job failed: exit code 1»

Несмотря на то, что все мои шаги проходят успешно, Gitlab CI показывает это — «Очистка файловых переменных 00:01 ОШИБКА: задание не выполнено: код выхода 1»

И терпит неудачу в самом конце. Также интересно, что это происходит только для моей основной ветки. Он успешно работает в других ветках. Кто-нибудь сталкивался с этой проблемой и нашел решение?

4 ответа

Обзор

Это свело меня с ума, и я до сих пор не знаю, какой ответ правильный. Я сам столкнулся с этой проблемой и потратил на нее часы. Я думаю, что GitLab что-то испортил с подстановкой команд (показывает новый выпуск вчера), хотя я могу ошибаться насчет проблемы или ее сроков. Кроме того, похоже, что это происходит только для некоторых замен команд, а не для других. Я изначально подозревал, что это может быть связано с выводом в /dev/null , но не собирался углубляться. Он всегда выходил из строя сразу после того, как была инициирована подстановка команды.

Мой код

У меня был код, похожий на ваш (сокращенная версия ниже), я пытался манипулировать им несколькими способами, но каждое использование подстановки команд приводило к одному и тому же сообщению об ошибке:

Я предпринял следующие попытки:

Обе эти версии успешно работали на моем локальном компьютере, но не работали в GitLab (у меня могут быть опечатки выше — пожалуйста, не разбирайтесь, это уменьшенная версия моей реальной программы).

Как я это исправил

Вместо того, чтобы использовать подстановку команд $(. ) , я выбрал замену процесса , и, похоже, она работает без проблем.

Я бы попытался заменить то же самое в вашем коде, если это возможно:

Проблема также может заключаться в строке внутри оператора if (эхо), вы можете заменить ее следующим:

Опять же, не совсем уверен, что это решит проблему для вас, поскольку я все еще не уверен, в чем причина, но это решило мою проблему. Удачи.

В моем случае мой сценарий завершился командой curl для URL-адреса, который вернул бы 403 Forbidden и, вероятно, повесил трубку

. если это кому-то поможет 🙂

Мы столкнулись с той же проблемой в GitLab v13.3.6-ee со следующей строкой скрипта, который мы используем для открытого нового запроса на слияние:

И, как заявил @ctwheels, изменив эту строку на это:

Источник

Источник

Pradeep Kumar

Error 1) open /root/.ssh/known_hosts: no such file or directory

Using SSH executor...

ERROR: Preparation failed: ssh command Connect() error:
getting host key callback: open /root/.ssh/known_hosts: 
no such file or directory

Will be retried in 3s ...

Enter fullscreen mode

Exit fullscreen mode

Solution:

Follow the steps to resolve:

1) Login to gitlab instance via SSH
2) Become sudo via: 

sudo su

Enter fullscreen mode

Exit fullscreen mode

3) Now, you need to connect gitlab instance to the host where runner is try to connect 

ssh <host-username>@<host-ip>

Enter fullscreen mode

Exit fullscreen mode

<host-username> and <host-ip> should match with the gitlab runner, it will ask for password then it will ask to accept key fingerprint.

Now, try to run the job with the runner. It should be working

Error 2) Job failed: prepare environment: Process exited with status 1.

If you are getting following error in your when running gitlab ci/cd job via gitlab-runner: 

ERROR: Job failed: prepare environment: Process exited with status 1. 
Check https://docs.gitlab.com/runner/shells/index.html#shell-profile-loading 
for more information

Enter fullscreen mode

Exit fullscreen mode

Solution:

Run following command: 

find / -name .bash_logout

Enter fullscreen mode

Exit fullscreen mode

and delete following files if exist 

sudo rm -r /home/gitlab-runner/.bash_logout
sudo rm -r /home/<username>/.bash_logout

Enter fullscreen mode

Exit fullscreen mode

Try to re-run the jobs it should be working.

Error 3) handshake failed: knownhosts: key is unknown

ERROR: Preparation failed: ssh command Connect() error: ssh Dial() error: ssh: handshake failed: knownhosts: key is unknown

Enter fullscreen mode

Exit fullscreen mode

Solution:

Solution A

Verify your login credentials

Solution B

Verify that SSH port is open

Solution C

Edit your runner and add disable_strict_host_key_checking = true 

sudo nano /etc/gitlab-runner/config.toml

Enter fullscreen mode

Exit fullscreen mode

[[runners]]
  name = "..."
  url = "..."
  token = "..."
  executor = "ssh"
  [runners.custom_build_dir]
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]
  [runners.ssh]
    user = "..."
    password = "..."
    host = "..."
    port = "..."
    disable_strict_host_key_checking = true

Enter fullscreen mode

Exit fullscreen mode

Then restart the gitlab-runner 

sudo gitlab-runner restart

Enter fullscreen mode

Exit fullscreen mode

Solution D

If you’re using WHM as your hosting control panel, enable following settings: 

SSH Password Authorization Tweak

Enter fullscreen mode

Exit fullscreen mode

Источник

Gitlab version: 10.0.1
Gitlab installed on Linux 3.10.0-327.el7.x86_64
Gitlab sonar plugin version: 2.1.0
SonarQube installed on Ubuntu 3.11.0-26-generic

See ‘.gitlab-ci.yml’ below

sonarqube_preview:
  script:
    - git config --global user.email "jenkins@test.com"
    - git config --global user.name "jenkins"
    - git checkout origin/development
    - git merge $CI_COMMIT_SHA --no-commit --no-ff
# For changes in Merge Request
    - mvn --batch-mode clean install sonar:sonar -Dmigration.skip=true -Dsonar.host.url=http://SONAR_URL:PORT/ -Dsonar.login=SONAR_LOGIN -Dsonar.password=SONAR_PASSWORD -Dsonar.analysis.mode=preview -Dsonar.gitlab.commit_sha=$CI_COMMIT_SHA -Dsonar.gitlab.ref_name=$CI_COMMIT_REF_NAME -Dsonar.gitlab.project_id=$CI_PROJECT_ID -Dsonar.sourceEncoding=UTF-8 -Dsonar.language=java -Dsonar.projectKey=SONAR_PROJECT_KEY -Dsonar.profile=SONAR_PROFILE -Dsonar.java.source=1.8 -Dsonar.projectName=SONAR_PROJECTNAME
  stage: test
  except:
    - master
    - development
    - /^hotfix_.*$/
    - /.*-hotfix$/
    - tags
  tags:
    - TEMP

sonarqube:
  script:
    - mvn --batch-mode clean install sonar:sonar -Dmigration.skip=true -Dsonar.host.url=http://SONAR_URL:PORT/ -Dsonar.login=SONAR_LOGIN -Dsonar.password=SONAR_PASSWORD -Dsonar.sourceEncoding=UTF-8 -Dsonar.language=java -Dsonar.projectKey=SONAR_PROJECT_KEY  -Dsonar.profile=SONAR_PROFILE -Dsonar.java.source=1.8 -Dsonar.projectName=SONAR_PROJECTNAME
  stage: test
  only:
    - development
  tags:
    - TEMP

See Pipeline Job log below

[INFO] 447 files indexed
[INFO] Quality profile for java: TEMP_Profile
[INFO] Sensor JavaSquidSensor [java]
[INFO] Configured Java source version (sonar.java.source): 8
[INFO] JavaClasspath initialization
[INFO] JavaClasspath initialization (done) | time=38ms
[INFO] JavaTestClasspath initialization
[INFO] JavaTestClasspath initialization (done) | time=4ms
[INFO] Java Main Files AST scan
[INFO] 429 source files to be analyzed
[INFO] 30/429 files analyzed, current file: /home/gitlab-runner/builds/82c2eccc/0/TEMP/TEMP/TEMP-ui/app/controllers/Application.java
[INFO] 34/429 files analyzed, current file: /home/gitlab-runner/builds/82c2eccc/0/TEMP/TEMP/TEMP-ui/app/controllers/Employees.java
[INFO] 36/429 files analyzed, current file: /home/gitlab-runner/builds/82c2eccc/0/TEMP/TEMP/TEMP-ui/app/controllers/Holidays.java
[INFO] 74/429 files analyzed, current file: /home/gitlab-runner/builds/82c2eccc/0/TEMP/TEMP/TEMP-ui/app/controllers/people/PersonGeneralInfoEdit.java
[INFO] 101/429 files analyzed, current file: /home/gitlab-runner/builds/82c2eccc/0/TEMP/TEMP/TEMP-ui/app/controllers/projects/WorkOrders.java
[INFO] 256/429 files analyzed, current file: /home/gitlab-runner/builds/82c2eccc/0/TEMP/TEMP/TEMP-ui/app/models/holder/reports/DaysInMonthHolder.java
[INFO] 378/429 files analyzed, current file: /home/gitlab-runner/builds/82c2eccc/0/TEMP/TEMP/TEMP-ui/app/persistence/PersonProjectRepository.java
[INFO] 385/429 files analyzed, current file: /home/gitlab-runner/builds/82c2eccc/0/TEMP/TEMP/TEMP-ui/app/persistence/ProjectReviewRepository.java
[INFO] 385/429 files analyzed, current file: /home/gitlab-runner/builds/82c2eccc/0/TEMP/TEMP/TEMP-ui/app/persistence/ProjectReviewRepository.java
[INFO] 385/429 files analyzed, current file: /home/gitlab-runner/builds/82c2eccc/0/TEMP/TEMP/TEMP-ui/app/persistence/ProjectReviewRepository.java
[INFO] 385/429 files analyzed, current file: /home/gitlab-runner/builds/82c2eccc/0/TEMP/TEMP/TEMP-ui/app/persistence/ProjectReviewRepository.java
[INFO] 385/429 files analyzed, current file: /home/gitlab-runner/builds/82c2eccc/0/TEMP/TEMP/TEMP-ui/app/persistence/ProjectReviewRepository.java
bash: line 54: 14887 Killed                  - mvn --batch-mode clean install sonar:sonar -Dmigration.skip=true -Dsonar.host.url=http://SONAR_URL:PORT/ -Dsonar.login=SONAR_LOGIN -Dsonar.password=SONAR_PASSWORD -Dsonar.analysis.mode=preview -Dsonar.gitlab.commit_sha=$CI_COMMIT_SHA -Dsonar.gitlab.ref_name=$CI_COMMIT_REF_NAME -Dsonar.gitlab.project_id=$CI_PROJECT_ID -Dsonar.sourceEncoding=UTF-8 -Dsonar.language=java -Dsonar.projectKey=SONAR_PROJECT_KEY -Dsonar.profile=SONAR_PROFILE -Dsonar.java.source=1.8 -Dsonar.projectName=SONAR_PROJECTNAME
ERROR: Job failed: exit status 1

I didn’t find any info about exception in all possible log files (GitLab, SonarQube etc)

Источник

# #python #powershell #gitlab #cicd

Вопрос:

Мой конвейер gitlab, который работает уже почти шесть месяцев, теперь неожиданно выходит из строя.

Каждая предыдущая строка выполняется успешно, а затем происходит следующее:

 Setting up curl (7.52.1-5 deb9u16) ...
$ curl -s https://deb.nodesource.com/setup_12.x | bash
Cleaning up project directory and file based variables 
ERROR: Job failed: exit code 1

Я ни за что на свете не могу понять, что изменилось. Я думал, что это может быть связано с этой проблемой, но у меня нет никаких проблем с сетью, тайм-аутов и т. Д.

Слегка запутанная версия моего .gitlab-ci.yml. Очевидно, что я использую .gitlab-ci.yml для настройки своих конвейеров, а также использую общие бегуны GitLab.

 
image: python:3.6-stretch

variables:
    ACCESS_KEY_ID: **********
    SECRET_ACCESS_KEY: **********

before_script:
  - apt-get update
  - apt-get install -y curl
  - curl -s https://deb.nodesource.com/setup_12.x | bash
  - apt-get install -y nodejs
  - apt-get install -y npm
  - npm install -g serverless
  - pip install  --upgrade awscli
  - python --version
  - nodejs --version

stages:
  - deploy

deploy:
  stage: deploy

  only:
  - master   # We will run the CD only when something is going to change in master branch.

  script:
    - npm install   # Archive the code repository.
    - pip install -r requirements.txt

    - cd services/service1/
    - sls deploy -v --stage production
    - cd ../../

    - cd services/service2/
    - sls deploy -v --stage production
    - cd ../../

    - cd services/service3/
    - sls deploy -v --stage production
    - cd ../../


  environment:
    name: master

Комментарии:

1. Если вы используете общие бегуны GitLab, предоставленные при использовании gitlab.com (в отличие от вашего собственного, автономного экземпляра GitLab), тогда вам следует обратиться в службу поддержки / поднять проблему . Эта ошибка, похоже, никак не связана с вашим определением конвейера.

Ответ №1:

Эта предпоследняя строка ( Cleaning up project directory and file based variables ) всегда присутствует в задании CI/CD, выполняется или не выполняется.

Скорее всего, происходит то, что последняя команда curl -s https://deb.nodesource.com/setup_12.x | bash терпит неудачу. К сожалению, поскольку вы загружаете файл удаления и передаете его в bash, вполне возможно, что ваш конвейер начнет случайным образом отказывать, потому что этот сценарий не гарантированно будет одинаковым каждый раз.

Чтобы проверить это, я создал чистую виртуальную машину ubuntu, запустил эту команду curl и получил следующую ошибку: введите описание изображения здесь

Ваш лучший способ исправить это в долгосрочной перспективе-создать контейнер, в котором есть все зависимости, необходимые для вашего CI, и сохранить их в реестре контейнеров для вашего проекта GitLab, а затем каждый раз извлекать этот контейнер. Это не только сэкономит вам минуты CI/CD, так как вам не нужно каждый раз запускать установки, но и предотвратит эту точную проблему, когда ваши зависимости изменяются под вами и вызывают ошибку. Также стоит отметить, что вы должны бытьочень осторожно передавайте внешне загруженный сценарий в bash, потому что этот сценарий может измениться, чтобы включить что угодно, и ваш CI просто неосознанно запустит его.

Источник

Понравилась статья? Поделить с друзьями:
  • Error java lang runtimeexception pipemapred waitoutputthreads subprocess failed with code 1
  • Error job failed exit code 127
  • Error java lang runtimeexception invalid id 4096 maximum id range exceeded
  • Error java lang nullpointerexception как исправить
  • Error java lang nullpointerexception mouseclicked event handler