A
я могу заванговать, что допустим изобретут патч для двоих, но жить оно скорей не будет к.м.к., ибо выгоды нет
Это просто не имеет смысла. Все равно, что пытаться менеджить гитовые репы на диске гитлабом и gitea одновременно. :)
Size: a a a
2020 March 23
A
Теоретически можно, но нахер не нужно
TF
Alexander
Теоретически можно, но нахер не нужно
"вас поняла, вычеркиваю.."
k
Alexander
И что он с ними будет делать?
Ну пользователям вседа можно будет получить к образам из интерфейса гитлаба, например.
С другой стороны харбор будет иметь доступ ко всем репозиториям гитлаба, соответсвенно сможет запускать garbage-collector и vulnerability scanning, при необходимости пользователю можно выделить права на доступ к своему репу через интерфейс харбора
С другой стороны харбор будет иметь доступ ко всем репозиториям гитлаба, соответсвенно сможет запускать garbage-collector и vulnerability scanning, при необходимости пользователю можно выделить права на доступ к своему репу через интерфейс харбора
k
Alexander
Можно, конечно, заранее создавать нужные проекты и rbac-и через api харбора, чтобы можно было через него потом получать доступ к образам, запушенным гитлабом. Но, ИМХО, проще уж тогда переехать целиком на гитлабный реджистри. Или поднять отдельный.
да вот в общем-то тоже потихоньку склоняюсь к тому чтобы отказаться от харбора в пользу гитлаба с external registry :-/
A
Ну пользователям вседа можно будет получить к образам из интерфейса гитлаба, например.
С другой стороны харбор будет иметь доступ ко всем репозиториям гитлаба, соответсвенно сможет запускать garbage-collector и vulnerability scanning, при необходимости пользователю можно выделить права на доступ к своему репу через интерфейс харбора
С другой стороны харбор будет иметь доступ ко всем репозиториям гитлаба, соответсвенно сможет запускать garbage-collector и vulnerability scanning, при необходимости пользователю можно выделить права на доступ к своему репу через интерфейс харбора
Гц сейчас и сам гитлаб умеет делать. А для сканирования уязвимостей можно и чего попроще сообразить, нежели целый отдельный сервис, умеющий многое помимо этого
R
вроде всегда был?
YD
Кстати, а давно gitlab-runner на go переписали?
АК
Ребят всем привет.
У нас когда где-то ломается шаг в pipeline - он же перестает весь работать?
Вообщем как можно чтобы скрипт(в разделе script) выполнился в любом случае.
Это отдельный шаг надо писать ?
У нас когда где-то ломается шаг в pipeline - он же перестает весь работать?
Вообщем как можно чтобы скрипт(в разделе script) выполнился в любом случае.
Это отдельный шаг надо писать ?
k
Ребят всем привет.
У нас когда где-то ломается шаг в pipeline - он же перестает весь работать?
Вообщем как можно чтобы скрипт(в разделе script) выполнился в любом случае.
Это отдельный шаг надо писать ?
У нас когда где-то ломается шаг в pipeline - он же перестает весь работать?
Вообщем как можно чтобы скрипт(в разделе script) выполнился в любом случае.
Это отдельный шаг надо писать ?
вроде как dependencies для этого завезли
https://docs.gitlab.com/ee/ci/yaml/#dependencies
https://docs.gitlab.com/ee/ci/yaml/#dependencies
A
вроде как dependencies для этого завезли
https://docs.gitlab.com/ee/ci/yaml/#dependencies
https://docs.gitlab.com/ee/ci/yaml/#dependencies
dependencies это про артефакты, ты наверное имел в виду needs
АК
Получается needs?
Тут просто усуглябляется что у меня джоба в контейнере еще вертится, и второй раз ради 1 строчки раскручивать контейнер не охота(хотя можно взять другой но все же), Окей спасибо сейчас почитаю
Тут просто усуглябляется что у меня джоба в контейнере еще вертится, и второй раз ради 1 строчки раскручивать контейнер не охота(хотя можно взять другой но все же), Окей спасибо сейчас почитаю