Size: a a a

2020 August 03

AS

Aleksey Shirokikh in ru_gitlab
может кто чо придумал ?
источник

ZA

Zagir Aknazarov in ru_gitlab
Aleksey Shirokikh
Как так получилось что giltab не выставляет в качестве переменной название environment в котором пошёл работать пайплайн.
У меня сложилось впечптление что он не сразу подхватывает переменную после её создания в настройках
источник

ZA

Zagir Aknazarov in ru_gitlab
Перезапуск помогал
источник

A

Aragroth in ru_gitlab
Peter Galonza
Всем привет.
Написал скрипт на python, который выводит в консоль функциями print() и logging.info(). Запускаю скрипт руками все хорошо. В консоли вывод от этих функций последовательно как в коде.
Когда скрипт запускает задача в pipeline, то в консоли лога задачи сначала все выводы logging.info(), а потом print(). Может кто сталкивался?
Это вроде из-за того, что модуль logging пишет инфу в stderror. Попробуй как здесь написано, перенаправить логирование в stdout. Могу наврать 🤪

https://stackoverflow.com/questions/14058453/making-python-loggers-output-all-messages-to-stdout-in-addition-to-log-file
источник

PG

Peter Galonza in ru_gitlab
Aragroth
Это вроде из-за того, что модуль logging пишет инфу в stderror. Попробуй как здесь написано, перенаправить логирование в stdout. Могу наврать 🤪

https://stackoverflow.com/questions/14058453/making-python-loggers-output-all-messages-to-stdout-in-addition-to-log-file
Попробую, а то уже начал думать, что не туда капаю.
источник
2020 August 04

И

Ильдар in ru_gitlab
Добрый день.

Подскажите пожалуйста.
Есть pipeline с 5 manual job.
Можно ли сделать ограничение на параллельный запуск job'ов?
Чтобы нельзя было запустить job, пока не отработает определенный(главный) job?
источник

VD

Vladimir Dzalbo in ru_gitlab
Ильдар
Добрый день.

Подскажите пожалуйста.
Есть pipeline с 5 manual job.
Можно ли сделать ограничение на параллельный запуск job'ов?
Чтобы нельзя было запустить job, пока не отработает определенный(главный) job?
распихать их в разные стейджи?
источник

И

Ильдар in ru_gitlab
Vladimir Dzalbo
распихать их в разные стейджи?
Попробую.
Это защитит от параллельного запуска?
Просто все job manual.
источник

VD

Vladimir Dzalbo in ru_gitlab
Да. По дефолту пока один стейдж не закончится, следующий не начнётся
источник

И

Ильдар in ru_gitlab
Vladimir Dzalbo
Да. По дефолту пока один стейдж не закончится, следующий не начнётся
Спасибо👍
источник

MG

Moe Green in ru_gitlab
подскажите - эти отступы огромные - это зачем и откуда в GitLab? это - он мне показывает, что у меня в коде реально появились такие отступы?
источник

MG

Moe Green in ru_gitlab
или это - GitLab просто визуально так отображает внесенные изменения, такими большими отступами?
источник

SC

Smoked Cheese in ru_gitlab
может ты там пробелы на табы заменил (или наоборот)?
источник

MG

Moe Green in ru_gitlab
Smoked Cheese
может ты там пробелы на табы заменил (или наоборот)?
вроде ничего не менял
источник

SC

Smoked Cheese in ru_gitlab
мб IDE переформатировала
источник

РК

Роман Кубинский... in ru_gitlab
Всем привет. Использую у себя на сервере shell-runner. Перед деплоем я хочу стопить старый контейнер и удалять его image. Но возникает проблема:

Перед деплоем ведь собирается новая версия контейнера, а когда я удаляю контейнеры через rm по $CI_REGISTRY_NAME, то удаляется и только что собранный контейнер (тупо стопить и удалять всё не могу, потому что одновременно крутятся и другие проекты)

В голову приходят только два варика:

1. Собирать новый контейнер на этапе деплоя после того, как удалил старые image/контейнеры. Но это довольной большой downtime + а что делать, если ошибка будет при сборке?

2. При сборке закачивать image на registry, а потом скачивать после удаления. Но тот же downtime + трафик гоняется большой

Можете подсказать хорошее решение для такой ситуации?
источник

MG

Moe Green in ru_gitlab
ну то есть - это gitlab показывает реальные отступы?
источник

AG

Andrey Gumilev in ru_gitlab
Роман Кубинский
Всем привет. Использую у себя на сервере shell-runner. Перед деплоем я хочу стопить старый контейнер и удалять его image. Но возникает проблема:

Перед деплоем ведь собирается новая версия контейнера, а когда я удаляю контейнеры через rm по $CI_REGISTRY_NAME, то удаляется и только что собранный контейнер (тупо стопить и удалять всё не могу, потому что одновременно крутятся и другие проекты)

В голову приходят только два варика:

1. Собирать новый контейнер на этапе деплоя после того, как удалил старые image/контейнеры. Но это довольной большой downtime + а что делать, если ошибка будет при сборке?

2. При сборке закачивать image на registry, а потом скачивать после удаления. Но тот же downtime + трафик гоняется большой

Можете подсказать хорошее решение для такой ситуации?
хорошая картинка на аватарке
источник

РК

Роман Кубинский... in ru_gitlab
Andrey Gumilev
хорошая картинка на аватарке
спасибо😂
источник

DV

Dmitry Vorobev in ru_gitlab
Роман Кубинский
Всем привет. Использую у себя на сервере shell-runner. Перед деплоем я хочу стопить старый контейнер и удалять его image. Но возникает проблема:

Перед деплоем ведь собирается новая версия контейнера, а когда я удаляю контейнеры через rm по $CI_REGISTRY_NAME, то удаляется и только что собранный контейнер (тупо стопить и удалять всё не могу, потому что одновременно крутятся и другие проекты)

В голову приходят только два варика:

1. Собирать новый контейнер на этапе деплоя после того, как удалил старые image/контейнеры. Но это довольной большой downtime + а что делать, если ошибка будет при сборке?

2. При сборке закачивать image на registry, а потом скачивать после удаления. Но тот же downtime + трафик гоняется большой

Можете подсказать хорошее решение для такой ситуации?
Миникуб 😅
источник