Как стать автором
Обновить

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

Спасибо за перевод!
А о GitHub Actions у сообщества какое мнение?
Кроме отсутствия самостоятельного развёртывания системы, перед GitLab CI есть минусы?

Привязка к гитхаб?

А в гитлаб ci будто нет привязки к гитлабу?
Да, я знаю, что можно через дополнительные функции пользоваться сборкой гитлаба, а код хранить в битбакете или гитхабе. Но… такое себе

Pull-сборка, это только Gitlab EE, к сожалению.

Если мы говорим про https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/ — то да
Но можно взамен использовать мирроринг репозитория https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html или внешние способы пропушить изменения в гитлаб репо (например, со стороны битбакета) и тогда при наличии gitlab-ci.yaml триггернется пайплайн. Костыли? Да, но зато премиум не нужен. Вообще удивительная вещь — жить на бесплатном гитлабе (или на стартере) вроде как можно, но эта жизнь полна боли и отчаяния, если нужно что-то из платных функций

Пока гитхаб щупал только на своих мелких проектах, но мне нравится больше чем gitlab CI( с которым правда работал посдений раз года 2 назад)
Мне кажется что проще разделять сборку от деплоя, удобная работа с готовыми сценариями из маркета, более интуитвный интерфейс. Хотелось бы пощупать на более сложный проектах.
Чувствуется сильное влияние azure devops.
На первый взгляд при выборе gitlab CI или github CI выбрал бы github.
По поводу самостоятельного развертывания, есть self-hosted runners.

Вставлю свои пять копеек, мы используем у себя частично (есть также jenkins, и совсем немного bibtucket pipelines).

Так вот, github actions все еще страдает мелочными проблемами, даже несмотря на версию v2.

Список досадных мелочей и проблем, с которыми я встретился:
  1. конструкция if: always(), позволяет выполнить шаг даже если задача была отменена или завершилась с ошибкой. Вполне возможно, что я уже придираюсь, но эта конструкция выглядит слишком «программистской», возможно стоило переименовать
  2. Рекомендуемая конструкция по установки env var в райнтайме (подразумевая «простоту» установки):
    run: echo "::set-env name=TARGET_BRANCH::$(echo ${GITHUB_BASE_REF##*/})"
  3. Когда писал свой github actions, обнаружил что job context и данные из Job API для нее же немного различаются: например, поле name. Какое-то взято из поля name в yml, какое-то из имени самого файла ¯\_(ツ)_/¯
  4. Для pull request в job context сообщение коммита всегда зафиксирована (Merge from «branch1» to «branch2»), т.е. если ваш коллега будет коммитить в открытый пуллреквест, вы так и получите одно и тоже сообщение в уведомлении. Сообщение последнего коммита можно таки получить из Job API, но не все разработчики actions для уведомлений это делают
  5. уведомления (slack, email, teams). Если в jenkins pipeline можно настроить post step, в bitbucket pipelines — post, то здесь уведомление это один из шагов. Будьте любезны не забыть if: always() если хотите чтобы уведомление пришло в случае ошибки или отмены
  6. для тех кто пишет свой actions: лично для меня было квестом определить во время job run, процесс завершился с ошибкой или нет? Как я понял, есть два способа понять, из step context.conclusion или Job API. Оба как я понял, eventually consistent, т.е. даже если вы запросите текущий статус, не факт что актуальное значение будет известно на текущий момент. Т.е. если повезет получите success/failed, а в худшем in_progress
  7. Github Actions UI: странные решения по переходам в ссылках. Допустим есть у вас коммит с failed status, где-то в середине пулреквеста. Вы решили посмотреть что же там, наводите на failed status, вам предлагается перейти по ссылке для деталей. После перехода отображается детали самого последнего билда, а не того по которому вы переходили ¯\_(ツ)_/¯

Плюсы для меня:
  • Типовые сценарии добавляются буквально за минуты (автоподбор сценария в зависимости от исходного кода вообще пушка, надеюсь будет в будущем еще умнее)
  • Есть конвенция, где располагать файлы для workflows, i.e в папке .github/workflows. Унифицирует процесс для всех проектов использующих GA
  • Подробная документация как для использования, так и для создания новых actions
  • Много выбора github actions в marketplaces. Но тут как с npm пакетами, вполне может быть какой-то шлак, или автор может забросить в любой момент. Ищите значок Verified Creator, чаще они производят качественные и продуманные actions
  • Github — это Microsoft, и у них получилось удачно включить все их сервисы в Ms Teams (аналог слака). Так что я надеюсь на очень крутую интеграцию и с github в ближайшем будущем

Те мелочи, которые я перечислил, не смертельны, с ними вполне можно сносно существовать, просто они портят достаточно неплохое первое впечатление от продукта. Буду благодарен, если кто-то нашел решение с уведомлениями. Спасибо

Что значит «самостоятельное» развёртывание? Покупаете гитхаб Энтерпрайз и вроде у вас все actions в периметр организации появляются автоматически, нет ?

Отличный вопрос по Github Actions. Для большинства случаев Actions вполне хорошо справляются тем более если проект на гитхабе, то даже дергаться не прийдется.
НЛО прилетело и опубликовало эту надпись здесь
Сейчас работаю с azure devops-пока для меня лучший CI(сраванию с hudson/jenkins, gitlab CI, bitbucket CI, github CI).
Github CI много взял от azure devops-вполне возможно что через некоторое будет удобнее(не вижу смысла майкрософту поддерживать 2 очень похожих продукта, думаю все фичи пстепенно перкочуют в гитхаб и он станет основным инструментом от MS)
У меня пока как раз наоборот. Gitlab в приоритете.
Azure, пока нет yaml pipeline в releases, вызывает крайнее неудобство тыканьем мышкой при создании или настройке их. Вы смирились или есть более изящные методы?
НЛО прилетело и опубликовало эту надпись здесь
Это хорошо когда pipelin'ов немного. Но когда много проектов, и что-то нужно оптимизировать, то тут приходит боль. Пока все откроешь, перетыкаешь мышкой, каждый pipeline, каждый stage, каждый task, каждый job.
НЛО прилетело и опубликовало эту надпись здесь
Багованное недоделанное нечто.
1) Нет кеша для сборки докера -> каждый запуск пайплайна долго билдим образы.
2) Нельзя наследовать джобы, поэтому много копипаста для разных пайплайнов
3) Странное поведение при прокидывании секретов в енвы, иногда вместо секрета получаем SOME_ENV="${SOME_SECRET_NAME}"
4) Какие-то неадекватные лимиты в packages (для бесплатной версии), поэтому для хранения образов надо подключать Dockerhub
Команда из flipper zero, вообще, заморочились и сделали workflow для девайса своего как я понял. blog.flipperzero.one/september-progress
А о GitHub Actions у сообщества какое мнение?

После 3 лет работы с Gitlab CI — Github Actions — недоделанный обрубок. Про кеши ниже написали, но самое большое недоумение вызывает то, что нельзя ретригать 1 джоб. Это вообще бред, особенно если бесплатный аккаунт для пет проекта. Постоянные сетевые задержки из-за которых джобы фейлятся и надо перезапускать весь пайплайн. Docker-compose очень глючно работает, вообще запускать что-то в docker-dind невозможно. Короче очень сырой проект, по сравнению с Gitlab CI

Сравнение нерелевантное, встречаются технические ошибки. Было бы хорошо, чтобы перед отправкой эту статью посмотрел хотя бы штатный девопс.

Например gitlab это не система контроля версиями, а система код ревью.

Писать что gitlab-ci не нужно устанавливать, а дженкинс нужно — некорректно.
gitlab же нужно устанавливать?

Опять gitlab-CI это CI к gitlab, а дженкис это CI к любой системе, в том числе и гитлаб.

История дженкинса начата гораздо раньше 2011, ибо еще в 2008 он уже считался одним из лучших CI инструментов (тогда он назывался Hudson)

GitLab CI/CD может полностью контролировать Git-репозитории. Речь идёт об управлении ветками репозиториев и о некоторых других возможностях. А вот Jenkins, хотя и умеет работать с репозиториями, не даёт такого же уровня контроля над ними, как GitLab CI/CD.

Можно привести конкретные примеры?
Поскольку все системы контроля версий интегрируются с CI примерно одинаково, у всех есть API, и приводя такой тезис, следовало бы привести пример что можно в GitlabCI и нельзя в дженкинс, и на оборот.

Я не то, чтобы хвалю Дженкинс, но хотелось бы не обзор неточного перевода, а обзор сравнений более технический.
«gitlab же нужно устанавливать?» — видимо, имеется ввиду, что можно использовать центральный gitlab, как сервис, и там будет CI. Но при этом можно установить свой (в отличие от связки GitHub + Actions), и это тоже отражено
Ну не у всех же стоит центральный gitlab
У кого-то битбакет, у кого-то геррит, у кого-то гитхаб, кто-то вообще обходится чистым гитом
Имеется введу что можно использовать gitlab.com и там свои репо держать и пользоваться их ранерами.

А кто-то имеет опыт с GitLab CI/CD для github? То есть со всего GitLab использовать только CI/CD

А смысл? Вообще гитхабовский CI где-то настраивал для выполнение внешних скриптов, уверен что настроить можно для работы с гитхабом, но в чем смысл если на гитхабе есть CI как минимум сравнимый по возможностям, но ненужны эти пляски с бубном?
Потому что GitLab CI/CD является отраслевым стандартом (пусть, возможно, №2), у многих есть заготовки, многие умеют что-то с ним делать и т.п., а GitHub Actions молодой претендент со всеми «вытекающими»?

Кто сказал, что гитлаб — отраслевой стандарт? Это информация от смузи-хипстеров, которые ничего другого в жизни не видели, или серьезных аналитиков (ну, скажем, гартнера)? И самое главное — в какой из функциональностей (хранение кода/сборки)

Ну, когда исследовали рынок (Европа, Украина, Россия, Беларусь) аутсорс "девопса", то все по умолчанию предлагали gitlab как основу, входящую в базовый тариф. Любой каприз за ваши деньги, но за gitlab получается вс' равно платишь.

Недавно искал работу, около 35 компаний и 50 собеседований, про Jenkins кроме Сбербанка и его аутсорсеров спросили в двух местах; про Gitlab CI/CD спрашивали в каждом втором месте.

Это, наверное, успех маркетинговой стратегии Gitlab.
Но вообще удивительного в этом ничего нет — мелкие компании не имеют денег на то, чтобы строить полноценно свою инфру. Поэтому они подсаживаются на gitlab.com — быстрый способ начать работу. А потом уже подсели и уже опыт есть работы на этой платформе и не хочется переучиваться или пересаживаться на что-то новое

Хочется-не хочется — дело десятое. Когда "продаешь" необходимость CI в принципе, то аргументов много. Когда "продаёшь" необходимость переключиться на другую CI, то часто ответ на вопрос "сколько нам это будет стоить" не очень хорошо выглядит по сравнению с ответом "что это нам даст, чего сейчас нет".


Да и сами сайты CI/CD систем продают прежде всего CI/CD в принципе, а вот преимущества перед конкурентами не подают значимых.

Используем GitHub (git + PRs, минимальный платный тариф), зачатки CI сейчас на TeamCity, но меня от него воротит прям… Как-то то ли непонятна его философия (пока впечатление, например, что CD только для галочки там), то ли UI убогий для типовых задач, то ли ещё что. То ли просто на подсознательном уровне не устраивает, что в команде используется инструмент, который никто толком не знает с не очень понятными намерениями вендора насчёт него.


Вот и думаю есть ли смысл поднимать GitLab только ради CI/CD. А с гитхабом смущает отсутствие опции self-hosted в принципе. Как хранилище кода — терпимо, как клей для инфраструктуры — как-то не хочется даже не вендор-лока (от него, увы, никуда), а хост-лока. Ну, например, артефакты и кэши грузить в Киев из Франции...

А с гитхабом смущает отсутствие опции self-hosted в принципе.

это не так. Я выше писал — гитхаб энтерпрайз покупаешь и получаешь локальный гитхаб

Как-то цен не видно даже на https://github.com/pricing а, главное, такая фича даже не вынесена в описание…

Как не вынесена? Вынесена! Просто она не считается самой основной!


А можно поинтересоваться, в чём именно сомнения насчёт намерений вендора? Продукт живёт, развивается, поддерживается, есть публичный роадмап (https://www.jetbrains.com/teamcity/roadmap/), что ещё хотелось бы увидеть в плане коммуникаций? (Я из команды TeamCity.)

Я не против Тимсити, но Тимсити выглядит дороговато на фоне Gitlab runner's и GoCD. Говорю прямо, как есть. В остальном тимсити полностью устраивает.

На какой-то из конференций онлайн в этом году было, что вы, JetBrains, запускаете что-то новое, Workspace кажется, что в части CI/CD навскидку очень сильно пересекается с функциональностью TeamCity. И даже в роадмапе вашем как-то про CD особо ничего в глаза не бросается.

Можно и так. Только смысла мало, как мне кажется.

Поддержка JavaScript'a в фичах удивила… Да, интерфейс запуска билдов задач в Jenkins можно расширить/модифицировать/дополнить при помощи JavaScript, но киллер-фичей является поддержка Groovy (как в интерфейсе, так и в пайплайнах).

Для кого киллер-фича, для кого дополнительній барьер.

Gradle по сути Groovy, так что интеграция инструментов сборки это плюс.

Вот гуглить пришлось, что такое Gradle

И как Вам Gradle?
Gradle был придуман программистами для программистов.

yaml/bash/ansible — админами для админов

Если у вас девопс-инженер пришел из разработчиков, он будет хвалить. Если из админов — то хвалить осторожно.
yaml/bash/ansible — админами для админов

yaml был придуман программистом Кларком Эвансом, программистом по имени Ingy döt Net, и программистом по имени Oren Ben-Kiki.


Баш был написан программистом по имени Brian Fox.

В ТО время, программисты и админы были одним человеком — инженером.

Сравнение очень удивило. Нельзя сравнивать специализированный инструмент и комбайн. Окей, положим, что мы из комбайна (гитлаб) рассматриваем только Gitlab-ci, но и здесь сравнение однобокое. Потому что, во-первых, можно заказать дженкинс в облаке (cloudbees?) и скинуть с себя необходимость его поддержки, а гитлаб, как я понял, из статьи, в первую очередь рассматривается облачный. И это либо сценарий использования уже готовых shared раннеров с их ограничениями, либо подключение своих (вопросы безопасности и хотя раннеры бесплатные, но все равно стоимости underlying железа или виртуалок). А установка гитлаба в он-премис окружениях — это тот ещё адок. С одной стороны — докер омнибас и поехали, а с другой — ну, кто делает нормально? С бекапами, отказоустойчивым постгресом и пр.? Ну, я отказываюсь понимать.
Я уж не говорю о том, что в сравнении не участвует целый десяток очень интересных продуктов — помимо всяких трависов и circle-ci — незаслуженно обошли concourse и spinnaker (оба члены CNCF). Забыли про Zuul (не тот, а другой) и GoCD. А для гитопса есть FluxCD, ArgoCD, pipecd.dev
В сравнении не рассказывается, что хотя дженкинс и очень расширяем, но это и является его обратной стороной. Иногда подобрать рабочую комбинацию плагинов становится сложно. А в гитлабе другая проблема — вроде все просто, но когда копнёшь — баш в ямле поддерживать это тот ещё адок. Хорошо, если у тебя стартап и работает полтора землекопа. А когда 2000 разрабов и ты кровавый Энтерпрайз? Гитлабу ещё катастрофически не хватает нормального интерфейса. В Дженкинсе можно сделать для разрабов минимальный интерфейс с комбобоксами, в котором можно выбирать, например, релиз, который уедет на прод. В гитлабе? Ну, никак, без костылей или внешних средств. Ну, ок. Давайте гитлаб обмажем rundeck’ом ещё, который прекрасно покрывает этот кейс. Но, извините, платить за гитлаб тогда? Увольте!


А! Ещё забыл. Если кто пользуется продуктами jfrog, то у них есть свои «pipelines» для сборок кода

А когда 2000 разрабов и ты кровавый Энтерпрайз?

Но, извините, платить за гитлаб тогда? Увольте!

Это как в том анекдоте: «Солидная фирма возьмёт в аренду степлер».

Правильно — мы боимся CAPEX и совершенно не боимся OPEX :-)

Добавил бы от себя:
гитлабовский "сидисиай сиди и собирай" хорош до тех пор пока ты идёшь по пути меньшего сопротивления.
Мы разрабатываем софт под Эльбрусы. И на них нет докера, нет и слава богу. НО гитлабовский сиай хоть в теории и может работать с ssh ранерами вместо докера, на практике не будет работать выгрузка артефактов, и ещё пара более мелких проблем, и главная проблема что всем пофиг… "не юзаешь докер ссзб", и пофиг что у тебя нет технической возможности… есть куча исполнителей (вагрант, ssh, параллелс) но их функционал ограничен а ишьюс о проблемах в них зачастую остаются без реакции.
Не знаю как дела обстоят в дженкинсе, и мне честно говоря лень править гитлаб. придумал элегантный костыльный способ обойти эти проблемы и хай оно живёт… но печально всё это господа..

Все так — потому что политика гитлаба — больше фич, чтобы охватить бОльшую массу потребителей. А баги… как-нибудь сами когда-нибудь закроются. Типичный EEE политика, как у M$.
При этом подкупает — создатель Гитлаба — практически наш соотечественник (из Украины). Гитлаб сам же собирается на Гитлабе — полный dogfooding.

Насчет эльбруса на самом деле очень интересно. Теоретически выглядит, что можно докер крутить на x86 машинках, а в самом пайплайне ssh'шиться на узлы с эльбрусом. Либо — неужели на Elbrus не работают cgroups (v2)/namespaces? Вообще выглядит крутой идеей — запустить кубернетес на эльбрусе. А потом налепить значок импортозамещения и назвать чем-нибудь типа "ХОРРОВОД — отечественная система управления контейнерами" (и зарегать домен horrorwood :-D)

Взяли и приписали недостаток Эльбруса в недостатки Гитлаба. А если на Эльбрусе, например, компилятора какого-то языка не будет — тоже Гитлаб будет виноват, что не смог на нём проект собрать?

не понял, при чём тут эльбрус?
речь шла про то что часть экзекбюторов недоделана и/или багована а ишью игнорятся.
а то что на эльбрусе дефицит инструментария… ну так не только на e2k такая беда..

Эльбрус тут при том, что Гитлаб тут точно не при чём. Я уже годы гоняю Gitlab CI/CD вот именно без докера и всё нормально работает, в том числе и артефакты.
Я уже годы гоняю Gitlab CI/CD вот именно без докера и всё нормально работает, в том числе и артефакты.

не работает нормально. Спорить не хочу, многие эксперты это мнение подтверждают (что ssh executor — нелюбимое дитя Gitlab, а shell не обеспечивает "чистоту" сборок)

Можешь рассказать как ты сделал выгрузку артефактов из ssh экзекутора без ранера?

В официальной документации прямо же говорится:
If you want to upload job artifacts, install gitlab-runner on the host you are connecting to via SSH

Запускай его хоть в докере и выгружай артифакты куда требуется.

Ага, удачи тебе запустить ранер на ос куда его не поставить, на архитектуре под которую его не собрать..


Как будто нельзя было на ssh executor задействовать scp или sftp, но нет же…

А с ранера почему это не задействовать?

Вручную, прописав в after_scripts — пожалуйста (что собсна и делаем)
Только почему это было не сделать частью самого экзекутора непонятно…

Можете доcтавлять через pipe напрямую по ssh без scp

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

Если она не делает, то что вы хотите это не значит что она не работоспособна. Я же выше указал, что нет у неё этого функционала.

Извините, но я согласен с 13werwolf13 Отсутствие этого функционала делает эту фичу в его конкретном кейсе неработоспособной. Если так подумать — админ gitlab может вообще все руками реализовать — и кэширование артефактов, и подгрузку их, и сборки, и деплой. И все на баше в ямле. Только… за что деньги уплочены? Если мы про платный гитлаб говорим?

Я с вами согласен, что это очень полезная и не сильно затратная опция для добавления функционала. Но деньги уплочены ровно за то, что написано в функционале. Спорить по этому поводу бессмысленно.
Платным гитлаб не пользовался, ставил свой, в контейнерах и сервер и рунеры.
админ gitlab может вообще все руками реализовать
— это скорее плюс чем минус.

В данном кейсе бесплатный ce, но это роли не играет. В поисках истины я общался с теми кто использует платную ee версию и там ровно те же проблемы (включая то что issues по екзекуторам отличным от докера и кубера игнорятся и иногда закрываются без ответа)

(включая то что issues по екзекуторам отличным от докера и кубера игнорятся и иногда закрываются без ответа)

ну, хорошо, что хотя бы гитлаб не исповедует принцип докера — давайте мы старый репо закроем, открой новый, а в нем ишьюс нет, а раз так, то нет и проблем :-D

А что с выгрузкой артефактов не так? Хоть на «луну» выгружай.
Мы разрабатываем софт под Эльбрусы. И на них нет докера

неожиданно. и почему там нет докера?

1) потому что ещё никто не заморачивался попытками портировать
2) потому что "а зачем?"

а, я забыл, что докер на го написан.


P. S. ваши аргументы не выдерживают никакой критики, конечно.

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

а для гитлаба оно, как я понимай, по выше чем для jenkins а при прочих равных....

их невозможно сравнивать по этому критерию, потому что дженкинс — это просто система управления задачами (сборками и тестами), а гитлаб — комбайн

Хм. Я понимаю, что гитлаб комбайн, но даже в простом виде, когда я его ставил себе на срвер в 14 году, то ему требовалось дофига ресурсов. (Тогда про ci cd еще не слышно было).
А кто что хорошего плохого может про drone сказать? По сравнению с jenkins ом.

Еще раз — нельзя напрямую сравнивать гитлаб и jenkins.
Гитлаб устанавливаешь — сразу подавай 2-4 ядра и 4-6 гига под сам гитлаб, и еще отдельно раннеры.
Дженкинс же — легко можно и на более слабую машину загнать (но все равно код где-то нужно хранить!!!)
Drone — бесплатный — никак не масштабируется https://drone.io/enterprise/opensource/#features
В остальном — годно.
Я бы смотрел на более мощные решения. Хотя бы начиная от GoCD

А в каком месте GoCD похож на авианосец? :-)

Не знаю. Про авианосец я про гитлаб имел в виду…
А gocd сейчас посмотрю, что за он.

НЛО прилетело и опубликовало эту надпись здесь

А у Вас нет претензий к нагромождению ямл якорей, include, extends, к чему провоцирует гитлаб?
Сама идея изолировать шаги в докер контейнерах — она на самом деле прекрасна. Т.к. позволяет реально на стандартной x86 платформе расширяться неограниченно. Но такой же подход и concourse, поэтому какого-то ноу-хау у гитлаба не наблюдается.


Ну и ещё интерфейс Дженкинса выглядит как поделие студента. Что не добавляет удобства использования.

да, страшноват снаружи, это факт )))

Ну и ещё интерфейс Дженкинса выглядит как поделие студента. Что не добавляет удобства использования.
я думаю это последнее, к чему стоит придираться в контексте CI/CD. На моей памяти в Gitlab интерфейс переделывали раз 5, причем в большинстве случаев становилось хуже и неудобно, имхо

Ну, когда 20 раз на дню надо запускать/апрувить пайплайны ручками, то UI/UX становится важной частью

> Самостоятельное развёртывание системы
А CloudBees?
Имхо это сравнение теплого с мягким.
И Gitlab, и Jenkins — оба шикарные комбайны с не очень пересекающимся функционалом и прекрасно работают в связке.
А как CI Jenkins намного сильнее и гибче, а Gitlab это и SCM с ролевой моделью доступа, и docker registry, и issue-tracking, и wiki
Gitlab это и SCM с ролевой моделью доступа, и docker registry, и issue-tracking, и wiki

именно! Но при этом все в нем работает "так себе". Вместо docker registry — лучше взять JFrog Artifactory или VMware harbor (если мы не про облако), вместо issue tracking традиционно используется JIRA, а вместо WIKI — Confluence...

Некоторые вещи, на раз-два делающиеся в Jenkins очень сложно сделать в Gitlab. Например, набор комбобоксов с выбором опций сборки (Debug/Release; gcc/clang и т.д.). Можно, конечно, руками все переменные прописать, но это надо постоянно помнить, какие именно переменные и значения подставлять. Или в Gitlab есть какой-нибудь способ сделать это без боли?

вам ниже gecube привел пример костыля как это можно сделать. Но, конечно, костыльно а не комбобоксы, не поспоришь
Немного удивило про поддержку в таблице, что у Jenkins ее нет а у gitlab есть.
Учитывая что большую часть проблем что с одним что с другим приходится решать все равно через community (в гитлабе в ишьюсах люди пишут свои костыли как обойти недоработки Gitlab CI) — может быть имелась в виду коммерческая поддержка?
И к этой ситуации выше есть как раз комментарий 13werwolf13, что проблемы CI «не решаются» — на самом деле решаются но долго, вопрос приоритизации

«Нельзя протестировать результаты объединения веток до их фактического объединения» уже написал VolCh — но эта фича доступна только в платных планах

«Для каждой задачи нужно описывать и загружать/выгружать артефакты.» — без использования DAG артефакты достаточно описать, они будут доступны следующему стейжу по умолчанию, если не изменяет память. (мне удобнее зависимости задач прописывать, поэтому верю документации без проверки)

Ну и много вопросов к таблице, как это все на самом деле относится к CI как инструменту?:
«Мониторинг производительности приложений, Поддержка JavaScript»
«Интеграция с другими инструментами, Уникальные особенности, Установка» — несравнимые вещи для дженкинса, который отдельный инструмент и gitlab-ci, который часть платформы

ага, костыли и велосипеды вроде такого


вариант определить переменные - через расписание, которое можно потом дергать руками


Мне кажется, это несколько не то, что хочется. Допустим, есть три переменные, каждая из которых принимает 3 значения. Допустима любая комбинация. Это надо 27 расписаний создавать, или я идею не уловил?

Если Вы хотите выбирать из 27 комбинаций — к сожалению, да.
Либо вводить ручками. Либо снаружи rundeck — ну, не завезли в гитлаб удобного способа выбораа значений из предопределенного списка

Среди широко известных особенностей Jenkins можно отметить простоту настройки

Самая смешная строчка в статье. Дженкинс — это такой Линукс на десктопе в мире CI/CD. Действительно, он может всё, но для этого нужно изрядно попотеть, походить по жирам и гитхаб-репозиториям в поисках таких же страдальцев. И всё равно он будет вас регулярно радовать сюрпризами, когда отвалятся базовые плагины после апгрейда вашей жиры или какого-то ещё сынтегрированного ПО. Но для сборки какого-нибудь махрового легаси на неожиданной платформе другого варианта нет.

Нельзя протестировать результаты объединения веток до их фактического объединения.

Эм, кто сказал? А как же это? Да, за деньги, но ведь есть...


При описании стадий CI/CD-конвейера в них пока нельзя выделять отдельные этапы.

Поясните, что имеется в виду?

к сожалению, у автора точно так же, я не понял.
С другой стороны, ru_vds ссылается на статью на DZone которые ссылаются на оригинал на lambdatest
В обоих статьях до перевода явно сквозит то, что что сравнение инструментов производилось из разреза DevOps Testing, в оригинале она даже заканчивается словами «Счастливого тестирования».
Возможно, с точки зрения QA специалиста, пользующегося данными инструментами, какие то пункты, про которые пишут в комментариях будут иметь смысл. Сам я не могу посмотреть с точки зрения тестирования на эти инструменты — не занимаюсь тестированием.

Ну, я полез в оригинал. Лучше бы не лез.


  1. High Availability Deployments
    It is widely used and one of the newest open-source CI/CD tools available. Installation as well as configuration for GitLab CI/CD is easy. It is a free and self-hosted CI tool built into GitLab. GitLab CI/CD gradually evolved as one of the most popular free CI/ CD tools used for automation of deployments.

Первое, что я вижу — HA deploy. Простой. Ага. На раз два. Ложь. HA только в платном гитлабе. В бесплатном — его нет, только если самому из говна и палок его не собирать. Облачный — это вообще отдельная история. Еще вопрос является ли apt install gitlab (или docker run омнибас пакет) продакшен инсталляцией вообще.


  1. Auto-Scaling CI Runners
    Auto-scaling GitLab CI runners can easily manage and save 90% on EC2 costs. This is truly essential, particularly for a parallel testing environment. Also, for organization level or project level runners this is usable across repositories.

только для облачного, в он-премис ты сам устанавливаешь gitlab runner. Или о чем они конкретно говорят? docker-machine? Кстати, если подкинете ссылочку — буду признателен


  1. Active Community Support
    The active and progressive community is one of the major plus-points for GitLab CI/ CD. All the support is provided out-of-the-box and doesn’t require modification in additional plugin installation.

???? типа — наличие открытого баг трекера? Ну, так это еще не означает, что тебе там кто бы то ни было поможет.....


В переводе:


При описании стадий CI/CD-конвейера в них пока нельзя выделять отдельные этапы.

в оригинале:


Stages within phases aren’t yet supported.

о! И все становится ясно. Во-первых, перепутаны phases/stages — в гитлабе вообще нет термина phases. Есть stages/jobs. И, да, упорядочение джобов ВНУТРИ stages — это вообще отдельная боль (они по умолчанию все параллельны)

о! И все становится ясно. Во-первых, перепутаны phases/stages — в гитлабе вообще нет термина phases. Есть stages/jobs. И, да, упорядочение джобов ВНУТРИ stages — это вообще отдельная боль (они по умолчанию все параллельны)

В гитлабе есть Directed Acyclic Graphs (DAG). Полагаю, частично может решить боль.

с autoscaling я думаю речь идет про autoscaling on AWS: Gitlab скейлит раннеры на EC2 и на fargate.

Про HA — я подозревал, что так и есть, обычное дело.

И спасибо про пояснение про phases\stages, я протупил. При использовании DAG(needs: keyword) они планируют добавить возможность зависимостей джобов и внутри одного стейжа тоже (сейчас джоба может зависеть только от джобы из предыдущего стейжа)
с autoscaling я думаю речь идет про autoscaling on AWS: Gitlab скейлит раннеры на EC2 и на fargate.

принимается, я был неправ — это работает и с облачным гитлабом, и с он-премис.


При использовании DAG(needs: keyword) они планируют добавить возможность зависимостей джобов и внутри одного стейжа тоже (сейчас джоба может зависеть только от джобы из предыдущего стейжа)

строго наоборот. Чтобы упорядочить джобы внутри стадии — достаточно сделать зависимость через artifacts (dependencies: ключ). А needs — он позволяет не дожидаться окончания stage, чтобы запустить джобу из следующей stage (вот здесь DAG и получается). И эта функция уже реализована (!)
В результате пайплайн выглядит как радуга (буэ)


image

Скорее всего вы правы. Меня, видимо, смутило, что про такую зависимость говорится не в разделе dependencies: а в разделе needs:
needs: is similar to dependencies: in that it must use jobs from prior stages, meaning it’s impossible to create circular dependencies. Depending on jobs in the current stage is not possible either, but support is planned.

при этом в разделе dependencies: — ни слова =)
В Jenkins при запуске тестов я могу указать какие-либо параметры:
image

я знаю что в gitlab есть переменные, но я не хочу каждый раз заходить туда, хотелось бы кнопку как в дженкинсе, чтобы я мог запускать тесты(не по расписанию, и не автоматически после merge-request)

я правильно понял, что в gitlab нельзя сделать такой же удобный запуск ui-тестов, как Jenkins?

Рекомендую перейти на использование Rundeck :-) и весь гуй на нем фигачить.


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

если каждый раз надо менять параметры:


Если же есть пресеты переменных — есть вариант описать все комбинации в Schedules, но не делать их активными. Тогда их можно будет триггерить руками.


schedules

Используем больше Jenkins но сейчас мигрируем в gitlab ci, из плюсов jenkins проще заниматься дебагом, больше возможностей для кастомизации, но его сложнее поддерживать если у вас несколько продуктовых направлений, требуется унификация, gitlab ci згачительно дороже дебаг и эмуляция цепочек stage й

Общие слова и никакой конкретики. Вполне возможно, что вы просто не изучили полностью фичи Gitlab CI.

действительно, отладка пайплайнов в гитлабе - это отдельная боль. Полностью согласен с коллегой. С другой стороны, а может и не надо пытаться делать сложные и неподдерживаемые пайплайны? Я просто видел пайпы с кучей стейджей, 100500 условий в when, и инклюдами и экстендами. Достаточно сложно бывает понять - что же автор подразумевал. А потом в случае изменения структуры проекта (например, изменили структуру веток) - сидишь и гадаешь, почему это пайплайн ведет себя не так. Это обратная сторона высокой степени гибкости...

действительно, отладка пайплайнов в гитлабе — это отдельная боль.

Но может вы готовить их не умеете? Я с Gitlab CI работаю уже последних лет 5, наверное. И с каждым релизом они становятся все лучше и лучше. За последние 2 года я не испытывал НИКАКИХ проблем с отладкой. Что я делаю не так? Понятно, что если вы наговнокодили архитектуру вашего CI, то потом и заблудитесь в нём, ну так не надо говнокодить...


Достаточно сложно бывает понять — что же автор подразумевал.

Это не проблема Gitlab CI, это проблема конкретного автора. Но даже в этом случае, в Gitlab есть возможность собрать merged YAML и посмотреть все правила целиком, как их видит Gitlab. Т.е. даже в случае с глубокой иерархией include'ов проблем проанализировать не возникнет.


Единственный случай, когда с дебагом пайплайнов в Gitlab CI могут возникнуть проблемы — это динамические пайпланы (в одном из моих проектов я такое использовал, было удобно с некоторыми "но"). Их вы не можете визуализировать и смерджить средствами гитлаба. Но и там есть решение — берете сгенерированный динамический конфиг и временно делаете статическим.


P.S. Если хотите, могу помочь вам упростить и ускорить ваши пайплайны так, чтобы вы в них не блудили, а они работали быстро и без сбоев :)

Не надо мне помогать ) я сторонник KISS подхода и стараюсь делать пайпы максимально простыми ) А Вы, похоже, являетесь аффилированными лицом )))

С чем соглашусь - да, возможности по отладке гитлаба за последние годы стали лучше. И в целом возможностей в нем стало больше. Те же rules - на голову выше, чем when. Но все равно логика авторов (гитлаба) иногда бывает весьма особенной, да и баги они фиксят по несколько лет ) Мне не нравится этот фокус на фичах, когда куча вещей ещё не сделана по уму. Та же поддержка cp1251 (которой нет), например )

Изменилось время - раньше я был обеими руками за гитлаб, пока они были в «догоняющих» и предоставляли реально более интересный и богатый функционал, чем альтернативные решения. Сейчас же ситуация не так однозначна - и гитхаб, и битбакет подтянулись ) И ценники тоже сравнялись )))

Но все равно киллер фича в виде прямого доступа к гитлаб апи остаётся )))

Не надо мне помогать ) я сторонник KISS подхода и стараюсь делать пайпы максимально простыми )

Тогда откуда жалобы? KISS-KISS'ом, но есть вещи, которые поддаются тонкой оптимизации. Например, соединив Docker Multi Stage билды и цепочку стейджей в Gitlab CI вкупе с кэшированием слоёв можно сократить время сборки образов с получаса до пары-тройки минут.


Вы, похоже, являетесь аффилированными лицом )))

Нет, не являюсь. Но я очень люблю Gitlab CI, и уже в нескольких компаниях, с которыми у меня был контракт, показал, как его надо готовить. Когда я туда приходил, там от него плевались (использовали, но плевались), а когда уходил, очень радовались, что такой инструмент у них есть.


Сейчас же ситуация не так однозначна — и гитхаб, и битбакет подтянулись ) И ценники тоже сравнялись )))

В плане CI предпочитаю только self-hosted решения. С битбакетом распрощался давно, не знаю, что там сейчас, но Github Actions еще как до Луны пешком до функционала Gitlab CI.

Например, соединив Docker Multi Stage билды и цепочку стейджей в Gitlab CI вкупе с кэшированием слоёв можно сократить время сборки образов с получаса до пары-тройки минут.

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

К тому же, не весь мир замкнут на докер и кубер.

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

Спокойно отношусь. Инструмент и инструмент ) со своими плюсами и минусами.

В плане CI предпочитаю только self-hosted решения. С битбакетом распрощался давно, не знаю, что там сейчас, но Github Actions еще как до Луны пешком до функционала Gitlab 

Ну, каждому своё ) мне облачные нравятся, но обычно есть дополнительные требования. Например, «нельзя хранить код на чужих ресурсах», но это от утечек все равно не спасёт ) и тогда уже можно придумывать как удовлетворить эти требования.

И потерять возможность хранения артефактов на уровне самого гитлаба. :)

Если коротко, это не так. Во-первых, не всегда что-то из образа надо доставать. Во-вторых, если всё же нужно, это делается примерно так:


docker run -v "$(pwd)":/opt/mount --rm --entrypoint cp $CONTAINER_REF_SHA-builder -r release/ /opt/mount/

Есть и другие способы. Но не всегда нужно иметь на выходе какие-то артефакты, потому что собирать вы можете образ с приложением на PHP или Python, где не будет готового бинарника.


Если же хотите подробностей, то надо больше конкретики с вашей стороны.


К тому же, не весь мир замкнут на докер и кубер.

Даже если вы не используете Kubernetes, использование докера сильно облегчает жизнь при локальной разработке.

Во-вторых, если всё же нужно, это делается примерно так:

Вы прекрасно иллюстрируете - как делать не надо. Вообще в пайплайне не нужно вызывать докер ) сборку мы делаем dockerless со средствами вроде kaniko - меньше точек отказа и не нужны избыточные привилегии, но каждый решает для себя насколько это приемлемо.

Я уж не говорю о том, что kubernetes и docker executor’в самодостаточны и прекрасно позволяют сделать сборку в изолированном окружении. Повторяемую, чистую и с возможностью сохранения артефактов без дополнительных действий.

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

Опять же повторюсь, что ну весь мир замкнут на докере ) Целевым артефактам может быть образ операционной системы, deb/rpm пакет, просто бинарник для разных платформ. И все эти артефакты выстраиваются в иерархию. Понятно, что получив бинарник - мы дальше можем его и в deb/rpm или в докер образ перепаковать ) в зависимости от Задачи и целевой среды

Вы прекрасно иллюстрируете — как делать не надо.

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


И вообще, некрасиво сначала сказать "потерять возможность хранения артефактов на уровне самого гитлаба", а потом когда вам указали на неправоту ваших слов, начать говорить "так делать не надо". Я вам дам второй способ, но следом вы заявите "ну весь мир замкнут на докере". Какой бы я вам рецепт ни подсказал, вы его будете отметать его нерелевантными аргументами. Это называется по-английски biased opinion.


сборку мы делаем dockerless со средствами вроде kaniko — меньше точек отказа и не нужны избыточные привилегии

Там свои грабли, и если вы это действительно по полной используете, вы и без меня это знаете.


Опять же повторюсь, что ну весь мир замкнут на докере

Но с ним легче, чем без него.

Тем не менее - за что любят гитлаб - за практически неограниченные возможности по доработке за счёт публичного гитлаб апи )))

Спасибо за статью, она для нас как раз кстати! Сейчас только выбираем себе инструмент для CI/CD и как раз выбор встал между Jenkins (из-за его популярности) и GitLab CI/CD (так как часть репозиториев с нашими проектами находятся в GitLab, плюс нет необходимости разворачивать отдельный сервер под это). Хотелось бы задать несколько вопросов на этом этапе, которые, как по мне, достойны участвовать в сравнении этих продуктов.

1. Возможно ли использовать GitLab CI/CD в случае, если часть репозиториев находится не на GitLab или GitHub, а на таких как JetBrains Space, Bitbucket и т. д.?

2. Возможно ли в GitLab CI/CD сделать deploy «безагентным»?

3. Каким образом в GitLab CI/CD можно доставить артефакты на множество хостов, к примеру на 4 бэкенда?

4. О бесплатности GitLab CI/CD, есть ли какие-либо ограничения в бесплатной версии или лимит на использование бесплатной версии?

Если у вас свой гитлаб и вы хотите запускать свои тесты на том же сервере, то это плохая затея. "Тяжелые" тесты могут подвешивать и сам гитлаб.


  1. Насколько я знаю, нет. Пару лет назад изучал этот вопрос, и было нельзя. Но, возможно, что-то изменилось.
  2. Что значит безагентный деплой?
  3. Как напишете скрипт для CI, так и будет работать.
  4. Одно из ограничений — нельзя запустить тесты перед мерджем. Это такой юзкейс, когда вы гарантированно можете проверить, что после мерджа у вас не будет проблем (по крайней мере покрытых тестами). Это можно ручками делать, ребейзя ветку разработчика на базовую ветку репозитория, но если разработчиков много, получится гонка за последним коммитом. Но в целом ограничение некритичное.

Добавлю 5 копеек.

1 Премиум фича

3 Там обычный yaml. Выбираете любимый shell при установке раннера и делаете хоть scp хоть Invoke-RestMethod в стадии after_script

4 Гуглится элементарно же.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий