Телеграмм чат группы ru_gitlab страница 2630

2019 December 31

k

с такой логикой и внешние МР имеют те же проблемы

Нет, идеальный вариант если бы аппрув мердж реквеста создавал бы бренч в оригинальном репо и фетчил бы в него эти изменения

источник

20:19пожаловаться #1

A

Andor in ru_gitlab

по-моему ты усложняешь

источник

20:19пожаловаться #2

A

Andor in ru_gitlab

я бы просто сделал в гитлабе группу, в которой сделал группы per-developer и пусть они туда гоняют форки твоего проекта
в верхней группе сделал шаред-раннеры и всё

источник

20:20пожаловаться #3

A

Andor in ru_gitlab

vars можно в топ-левел группе сделать

источник

20:21пожаловаться #4

A

Andor in ru_gitlab

вощем не люблю когда сложно, люблю когда просто

источник

20:21пожаловаться #5

k

kvaps in ru_gitlab

Andor

я бы просто сделал в гитлабе группу, в которой сделал группы per-developer и пусть они туда гоняют форки твоего проекта
в верхней группе сделал шаред-раннеры и всё

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

источник

20:26пожаловаться #6

k

kvaps in ru_gitlab

Тогда уж проще добавить всех разработчиков в один проект и отказаться от внешних МР, как и было предложено раньше

источник

20:26пожаловаться #7

A

Andor in ru_gitlab

Ты переусложняешь для паранойи?

источник

20:26пожаловаться #8

A

Andor in ru_gitlab

kvaps

Тогда уж проще добавить всех разработчиков в один проект и отказаться от внешних МР, как и было предложено раньше

Верно, так обычно проще для управления

источник

20:27пожаловаться #9

A

Andor in ru_gitlab

А vars в твоём репо и vars в общей группе могут быть и разные

источник

20:27пожаловаться #10

A

Andor in ru_gitlab

Потому что задачи разные

источник

20:27пожаловаться #11

k

kvaps in ru_gitlab

Andor

А vars в твоём репо и vars в общей группе могут быть и разные

как и для разных environmets в пределах одного репо

источник

20:28пожаловаться #12

A

Andor in ru_gitlab

kvaps

как и для разных environmets в пределах одного репо

Этим сложнее управлять, чем форками

источник

20:28пожаловаться #13

A

Andor in ru_gitlab

Имхо

источник

20:28пожаловаться #14

k

kvaps in ru_gitlab

Andor

Ты переусложняешь для паранойи?

Проще когда у тебя пайплайн работает только в одном репо

источник

20:28пожаловаться #15

A

Andor in ru_gitlab

Небольшая разница

источник

20:29пожаловаться #16

A

Andor in ru_gitlab

Не руками ж настраивается

источник

20:29пожаловаться #17

k

kvaps in ru_gitlab

kvaps

Нет, идеальный вариант если бы аппрув мердж реквеста создавал бы бренч в оригинальном репо и фетчил бы в него эти изменения

Смотри в этом кейсе вопрос только аппрува:

К примеру: тебе пришёл МР, ты его отревьювил, нажал аппрув, у тебя сразу же создалась одноимённая ветка в оригинальном репо, в неё втянулись изменения из форка, для неё автоматом запустился пайплайн в контексте основного репо.

Девелопер что-то у себя поменял? - пока не нажмёшь аппрув пайплайн для ветки не запустится.

источник

20:33пожаловаться #18

A

Andor in ru_gitlab

А потом девелопер допушил в ветку фикс какой-нибудь штуки

источник

20:34пожаловаться #19

k

kvaps in ru_gitlab

При этом тебе не понадобятся ни шаред-раннеры, ни группа для проекта, девелопер не будет иметь никакого доступа к vars

источник

20:34пожаловаться #20