Size: a a a

2021 May 25

p

ptchol in DevOps
ты можешь запрещать мёрдж к примеру, но билд проверять на работоспособность
источник

p

ptchol in DevOps
ттоесть build \ lint могут быть двумя отдельными "условиями"
источник

RA

Ruslan Abdullaev in DevOps
линт просто ради галочки, знакомая ситуация)
источник

p

ptchol in DevOps
не ради галочки.
источник

p

ptchol in DevOps
у нас к примеру десяток разных чеков и пока все они не пройдут merge PR'а невозможен, но это не отменяет того что билд можно делать в параллель.
источник

DS

Dmitry Sergeev in DevOps
В jenkins как угодно крути, в параллель пускай, навешивай try на линт и т.д.
источник

N

Nikita in DevOps
Линтер внедряется в большой Легаси проект. И он будет выдавать много вещей связанных не с тем, что ты делал, а что делали до тебя. И это не совсем правильно валить все из-за линтера. К примеру когда надо быстро выпустить багфикс и нет времени копаться и смотреть где что не так в старом коде.

Поэтому и хотелось бы дать возможность разрабу решать,что делать в ситуации когда линтер ругается
источник

N

Nikita in DevOps
Но на проекте gitlab.....
источник

АП

Антон [R13 🍆 Ivelok]... in DevOps
А в чём противоречие?
источник

D

Denis 災 nobody in DevOps
Думаешь, если линтер ругается, и можно игнорить, большинство разрабов не будут забивать? Просто потому, что могут и "а чо он" и "там всё нормально, мамой клянусь"
источник

DS

Dmitry Sergeev in DevOps
мне кажется это разрабам решать. Это же не проблемы девопса. Код разрабов, пусть и отключают линт если им это надо. Девопсу то какое дело до этого =)
источник

D

Denis 災 nobody in DevOps
Лодка общая.
источник

ЕО

Евгений Омельченко... in DevOps
Можно запускать линтер только на изменённом коде
источник
2021 May 26

n

not a cake in DevOps
Здравствуйте. Пришел, и сразу с вопросом: можете порекоммендовать способ сборки артефактов CircleCI в одно место? Есть несколько джоб, некоторые на виртуалках, каждая дает некие файлы, через store_artifacts делаю их доступными для загрузки с браузера. Мне потом надо получить их все в одном месте, в одной джобе, чтоб грубо говоря упаковать в один архив. Так вот, я пока вижу два варианта: через persist_to_workspace + attach_workspace, либо через кэш (привязать например кэшированный элемент к хэшу коммита по которому был билд, а не к хэшу какого-то файла как обычно). Может кому приходилось подобное делать? Мне не надо решения, просто совет какой-нибудь.

P.S. Что за бот с капчой тут используется?
источник

DS

Dmitry Sergeev in DevOps
используйте внешние хранилище для артифактов. artifactory, nexus какой-нибудь. Наверняка удобней будет это все объеденять
источник

n

not a cake in DevOps
Внешний сервис для обмена артефактами в пределах одного workflow? Кроме того, я скорее всего не имею возможности внешние сервисы подключать
источник

SI

Sasha Ibraimov in DevOps
Ребятки, вопрос по azure devops.
У меня есть два пайплайна, которые собирают js клиентов. Я хочу иметь разную версионность этих клиентов, но проблема в том, что нужно получать этих клиентов одним архивом, в  одной папке, условно Clients/A и Clients/B, и мне нужно формировать Clients. zip. Но проблема в том, что когда я запускаю первый пайплайн, собирается А. в архиве я получаю  только папку A, но когда я запускаю второй пайплайн я получаю в архиве только папку B, папка А удаляется. Как вообще тут поступить? Я пытался отдельно хранить этих клиентов, но так тоже не вышло, потому что как я понимаю для каждого запуска пайплайна используется новый агент. Может в случае подписки я смогу для всех пайплайнов использовать одного агента?
источник

DS

Dmitry Sergeev in DevOps
источник

SI

Sasha Ibraimov in DevOps
А если я храню как артефакты? Точнее тут $(Build.ArtifactStagingDirectory). Это не одно и то же?
источник

II

Igor Ignatev in DevOps
подтягивайте артифакты из другого пайплайна а в б и наоборот
источник