Cleaning up project directory and file based variables error job failed exit code 1

Overview

This drove me crazy and I’m still not sure what the appropriate answer is. I just ran into this issue myself and sunk hours into this issue. I think GitLab messed something up with command substitution (shows a new release yesterday), although I could be wrong about the issue or its timing. It also seems to only occur for some command substitutions and not others, I initially suspected it might be related to outputting to /dev/null, but wasn’t going to dive too deep. It always failed immediately after the command substitution was initiated.

My code

I had code similar to yours (reduced version below), tried manipulating it multiple ways, but each use of command substitution yielded the same failure message:

Cleaning up file based variables          00:01
ERROR: Job failed: exit code 1

Attempts I’ve made include the following:

- folders=$(find .[^.]* * -type d -maxdepth 0 -exec echo {} ; 2>/dev/null)
- >
  while read folder; do
      echo "$folder"
  done <<< "$folders"

And …

- >
  while read folder; do
      echo "$folder"
  done <<< $(find .[^.]* * -type d -maxdepth 0 -exec echo {} ; 2>/dev/null)

Both those versions succeeded on my local machine, but failed in GitLab (I might have typos in above — please don’t scrutinize, it’s reduced version of my actual program).

How I fixed it

Rather than using command substitution $(...), I instead opted for process substitution <(...) and it seems to be working without issue.

- >
  while read folder; do
      echo "$folder"
  done < <(find .[^.]* * -type d -maxdepth 0 -exec echo {} ; 2>/dev/null)

I would try to substitute the same in your code if possible:

- >
  while read dir; do
      # the rest goes here
  done < <(git log -m -1 --name-only -r --pretty="format:" "$CI_COMMIT_SHA")

The issue might also be the line inside the if statement (the echo), you can replace that with the following:

read SERVICE < <(echo "$dir")

Again, not exactly sure this will fix the issue for you as I’m still unsure what the cause is, but it resolved my issue. Best of luck.

Cleaning up file based variables error job failed exit status 1

# #python #powershell #gitlab #cicd

Вопрос:

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

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

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

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

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

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 When Building Image with Kaniko #1624

Actual behavior
I am getting an error when building image with Kaniko in GitLab CI.

Our image build script is this:

Our Dockerfile is this:

Expected behavior
It shouldn’t give any errors in dotnet restore phase because the .csproj file should be there with path src/our_app_name.csproj , I do not get any errors when building directly with docker build .

To Reproduce
Steps to reproduce the behavior:

1. Use given dockerfile and a dotnet project with the same name.
2. Use given GitLab CI script.

Additional Information

• Dockerfile — Provided.
• Build Context — GitLab CI.
• Kaniko Image (fully qualified with digest) — gcr.io/kaniko-project/executor:debug with digest sha256:e00dfdd4a44097867c8ef671e5a7f3e31d94bd09406dbdfba8a13a63fc6b8060 .

Triage Notes for the Maintainers

The text was updated successfully, but these errors were encountered:

Источник

Gitlab CI / CD дает сбой при «Очистке каталога проекта и переменных на основе файлов» с сообщением «ОШИБКА: сбой задания: код выхода 1»

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

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

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

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

Предпоследняя строка ( 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 просто неосознанно запустит его.

Источник

Unexpected failures on semgrep analyzer

Summary

semgrep is now returning proper exit codes correctly which is causing a spike in reported failure rates. This is to be expected but we appear to be failing in certain unclear cases.

Most recently, semgrep is returning a exitcode 3 on https://cdn.jsdelivr.net/npm/chart.js@3.5.1/dist/chart.min.js which is causing a failure. I would guess this is due to the file being considered unparseable due to either LoC size or some other constraint.

In other cases, semgrep is returning exitcode 2 when rule evaluations timeout, see default —timeout of 30sec

In other cases, semgrep is returning exitcode 2 when ignore annotations to not match rules that are currently loaded. See https://gitlab.com/chris-semgrep/semgrep-exit-status-2

Steps to reproduce

1. Download https://cdn.jsdelivr.net/npm/chart.js@3.5.1/dist/chart.min.js
2. Run docker run -it —rm —volume «$PWD»:/tmp/app —env SECURE_LOG_LEVEL=debug —env CI_PROJECT_DIR=»/tmp/app» registry.gitlab.com/gitlab-org/security-products/analyzers/semgrep:2 /analyzer analyze /tmp/app
3. Observe exit code

Example Project

• exit status 3 JS syntax error reproducible with https://gitlab.com/gitlab-com/gl-security/engineering-and-research/gib (Internal)
• exit status 2 nosemgrep annotation mismatch reproducible with https://gitlab.com/chris-semgrep/semgrep-exit-status-2

What is the current bug behavior?

Semgrep fails with exitcode 3 for unknown error

What is the expected correct behavior?

Semgrep doesn’t fail

Relevant logs and/or screenshots

Output of checks

This bug happens on GitLab.com

Possible fixes

Either rescue this specific exit code (if semgrep is best-effort) or file upstream on failing file

Источник

Uploading artifacts as «archive» to coordinator failed after upgrade from 14.0.5 to 14.1.2

Summary

The artifact upload feature of gitlab CI no longer works after upgrading gitlab-ee (14.0.5 => 14.1.2) and gitlab-runner (14.0.1 => 14.1.0). We haven’t had any trouble with this feature until this specific upgrade.

We have found these similar (below), but have found no workarounds or other helpful information. No other issues appear to reference this failure in relation to a version upgrade.

We use AWS s3 for storage and none of the artifacts are large.

Steps to reproduce

Perform the upgrade as described above.

Example Project

What is the current bug behavior?

All jobs which use artifact storage are now failing with the following message:

What is the expected correct behavior?

Artifacts should be uploaded without failure.

Relevant logs and/or screenshots

I was able to find some requests in the logs (redacted): /var/log/gitlab/gitlab-workhorse/current :

There were no exceptions written to /var/log/gitlab/gitlab-rails/exceptions_json.log .

Output of checks

Results of GitLab environment info

System information System: Ubuntu 18.04 Proxy: no Current User: git Using RVM: no Ruby Version: 2.7.2p137 Gem Version: 3.1.4 Bundler Version:2.1.4 Rake Version: 13.0.3 Redis Version: 6.0.14 Git Version: 2.32.0 Sidekiq Version:5.2.9 Go Version: unknown

GitLab information Version: 14.1.2-ee Revision: 0bf9b154 Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: PostgreSQL DB Version: 12.6 URL: https://gitlab.example.com HTTP Clone URL: https://gitlab.example.com/some-group/some-project.git SSH Clone URL: git@gitlab.example.com:some-group/some-project.git Elasticsearch: no Geo: no Using LDAP: yes Using Omniauth: no

GitLab Shell Version: 13.19.1 Repository storage paths:

• default: /var/opt/gitlab/git-data/repositories GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell Git: /opt/gitlab/embedded/bin/git

Expand for output related to GitLab environment info

Results of GitLab application Check

Checking GitLab subtasks .

Checking GitLab Shell .

GitLab Shell: . GitLab Shell version >= 13.19.1 ? . OK (13.19.1) Running /opt/gitlab/embedded/service/gitlab-shell/bin/check Internal API available: OK Redis available via internal API: OK gitlab-shell self-check successful

Checking GitLab Shell . Finished

Gitaly: . default . OK

Checking Gitaly . Finished

Sidekiq: . Running? . yes Number of Sidekiq processes (cluster/worker) . 1/1

Checking Sidekiq . Finished

Checking Incoming Email .

Incoming Email: . Checking Reply by email .

IMAP server credentials are correct? . Checking example-gitlab@example.com yes Init.d configured correctly? . skipped MailRoom running? . skipped

Checking Reply by email . Finished

Checking Incoming Email . Finished

LDAP: . Server: ldapmain LDAP authentication. Success LDAP users with access to your GitLab server (only showing the first 100 results) Checking LDAP . Finished

Checking GitLab App .

Git configured correctly? . yes Database config exists? . yes All migrations up? . yes Database contains orphaned GroupMembers? . no GitLab config exists? . yes GitLab config up to date? . yes Log directory writable? . yes Tmp directory writable? . yes Uploads directory exists? . yes Uploads directory has correct permissions? . yes Uploads directory tmp has correct permissions? . yes Init script exists? . skipped (omnibus-gitlab has no init script) Init script up-to-date? . skipped (omnibus-gitlab has no init script) Projects have namespace: . Redis version >= 5.0.0? . yes Ruby version >= 2.7.2 ? . yes (2.7.2) Git version >= 2.31.0 ? . yes (2.32.0) Git user has default SSH configuration? . yes Active users: . 378 Is authorized keys file accessible? . yes GitLab configured to store new projects in hashed storage? . yes All projects are in hashed storage? . yes Elasticsearch version 7.x (6.4 — 6.x deprecated to be removed in 13.8)? . skipped (elasticsearch is disabled)

Checking GitLab App . Finished

Checking GitLab subtasks . Finished

Expand for output related to the GitLab application check

Источник

Cleaning up file based variables error job failed exit code 1

# #python #powershell #gitlab #cicd

Вопрос:

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

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

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

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

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

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 просто неосознанно запустит его.

Источник

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, изменив эту строку на это:

Источник

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, изменив эту строку на это:

Источник

/ bin / bash: строка 117: kubectl: команда не найдена gitlab-ci

Я не могу использовать команду kubectl внутри файла gitlab-ci.yml .

Я уже выполнил шаги, упомянутые в документе, чтобы добавить существующий кластер в документ.

Они нигде не упомянули, как я могу использовать kubectl .

Я попробовал конфигурацию ниже.

Но я получаю ошибку ниже,

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

Когда я удаляю изображение, я получаю эту ошибку.

Я просмотрел весь документ и не смог найти ни одного примера или ссылки, объясняющей эту часть.

Подскажите, пожалуйста, как мне выполнить развертывание в существующем кластере k8s.

Я просмотрел этот документ, и я используя определенные переменные в моем gitlab-ci.yml для обновления контекста kubectl.

Но все равно не работает.

Ошибка, которую я получаю,

2 ответа

Чтобы автоматизировать развертывание с существующим кластером, вам необходимо выполнить следующие шаги:

1. Добавьте свой кластер в проект gitlab.

Следуйте этому документу и добавьте ваш существующий кластер

2. Создайте свой проект и отправьте его в докер или любой реестр

3. Примените свой deployment.yml к кластеру

Чтобы использовать kubectl внутри gitlab-ci.yml , вам нужно изображение с kubectl . Тот, который вы использовали, будет работать.

Но kubectl внутри контейнера не имеет представления о контексте кластера, который вы добавили ранее.

Теперь здесь свою роль играет переменная среды gitlab.

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

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

Кроме того, при создании кластера gitlab по умолчанию создает переменные среды для этого кластера, см. здесь.

Важно отметить, что он также добавляет переменную среды KUBECONFIG .

Чтобы получить доступ к вашему кластеру Kubernetes, kubectl использует файл конфигурации. Файл конфигурации по умолчанию kubectl находится в

/.kube/config и называется файлом kubeconfig .

Файлы kubeconfig организуют информацию о кластерах, пользователях, пространствах имен и механизмах аутентификации. Команда kubectl использует эти файлы для поиска информации, необходимой для выбора кластера и взаимодействия с ним.

Порядок загрузки соответствует этим правилам:

Если установлен флаг —kubeconfig , то загружается только данный файл. Флаг может быть установлен только один раз, и слияние не происходит.

Если установлена ​​переменная среды $KUBECONFIG , то она анализируется как список путей файловой системы в соответствии с обычными правилами разграничения путей для вашей системы.

В противном случае используется файл $/.kube/config , и слияние не происходит.

Итак, команда kubectl может использовать переменную KUBECONFIG для установки контекста см. здесь.

Итак, ваша работа по развертыванию будет выглядеть, как показано ниже,

Источник

Gitlab CI / CD дает сбой при «Очистке каталога проекта и переменных на основе файлов» с сообщением «ОШИБКА: сбой задания: код выхода 1»

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

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

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

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

Предпоследняя строка ( 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 просто неосознанно запустит его.

Источник

    - >
     for dir in $(git log -m -1 --name-only -r --pretty="format:" "$CI_COMMIT_SHA"); do 
     if [[ -f "$dir" ]]; then 
     SERVICE=$(echo "$dir")
     # helm install the service
     fi
     done
    - echo "deployed" 

4 ответа

Лучший ответ

- folders=$(find .[^.]* * -type d -maxdepth 0 -exec echo {} ; 2>/dev/null)
- >
  while read folder; do
      echo "$folder"
  done <<< "$folders"

- >
  while read folder; do
      echo "$folder"
  done <<< $(find .[^.]* * -type d -maxdepth 0 -exec echo {} ; 2>/dev/null)

- >
  while read folder; do
      echo "$folder"
  done < <(find .[^.]* * -type d -maxdepth 0 -exec echo {} ; 2>/dev/null)

- >
  while read dir; do
      # the rest goes here
  done < <(git log -m -1 --name-only -r --pretty="format:" "$CI_COMMIT_SHA")

read SERVICE < <(echo "$dir")

curl -s "$ENV_URL/hello" | grep "hello world"

COUNTBRANCHES=`echo ${LISTMR} | grep -o ""source_branch":"${CI_COMMIT_REF_NAME}"" | wc -l`;

read COUNTBRANCHES < <(echo ${LISTMR} | grep -o ""source_branch":"${CI_COMMIT_REF_NAME}"" | wc -l);

This post is not the end, for we will continue to add more troubleshooting guides as we continue our exploration with DevOps tools.

Last updated 30 Jan 2023