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

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

Если мы говорим про 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, есть on-premises и есть бесплатная версия. Если конечно нет предвзятого отношения к продуктам Майкорсофт, что очень часто встречается)
Сейчас работаю с azure devops-пока для меня лучший CI(сраванию с hudson/jenkins, gitlab CI, bitbucket CI, github CI).
Github CI много взял от azure devops-вполне возможно что через некоторое будет удобнее(не вижу смысла майкрософту поддерживать 2 очень похожих продукта, думаю все фичи пстепенно перкочуют в гитхаб и он станет основным инструментом от MS)
У меня пока как раз наоборот. Gitlab в приоритете.
Azure, пока нет yaml pipeline в releases, вызывает крайнее неудобство тыканьем мышкой при создании или настройке их. Вы смирились или есть более изящные методы?
я честно говоря вообще не понимаю yaml. Настраивал все билды визуально(за это и люблю собственно Azure Devops(ex-TFS)), когда плотно devops-ил. Иногда что то вручную смотрел ради интереса в json.
Именно удобный интерфейс на мой взгляд главное преимущество TFS перед тем же TeamCity. Скрипты то примерно везде работают плюс минус одинаково.
Недавно был искренне удивлен что всеми любимый TeamCity не поддерживал до последней версии conditional steps; a у нас собственно на работе сейчас не последняя версия и пригодилась бы эта фича, в AzureDevOps(TFS) например условие можно прописать прямо в браузере уже начиная с 2017 версии
Это хорошо когда pipelin'ов немного. Но когда много проектов, и что-то нужно оптимизировать, то тут приходит боль. Пока все откроешь, перетыкаешь мышкой, каждый pipeline, каждый stage, каждый task, каждый job.
Так обычно у каждой команды свои билды, даже в крупных компаниях, в частности в сбере у нас было так и в барклайс сейчас точно так же, то есть это 20-30 однотоипных билдов отилчающихся парой переменных. И все одинаковые шаги можно вынести в базовый билд дефинишен
Багованное недоделанное нечто.
1) Нет кеша для сборки докера -> каждый запуск пайплайна долго билдим образы.
2) Нельзя наследовать джобы, поэтому много копипаста для разных пайплайнов
3) Странное поведение при прокидывании секретов в енвы, иногда вместо секрета получаем SOME_ENV="${SOME_SECRET_NAME}"
4) Какие-то неадекватные лимиты в packages (для бесплатной версии), поэтому для хранения образов надо подключать Dockerhub
Сравнение нерелевантное, встречаются технические ошибки. Было бы хорошо, чтобы перед отправкой эту статью посмотрел хотя бы штатный девопс.

Например 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://www.jetbrains.com/teamcity/roadmap/), что ещё хотелось бы увидеть в плане коммуникаций? (Я из команды TeamCity.)

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

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

Поддержка JavaScript'a в фичах удивила… Да, интерфейс запуска билдов задач в Jenkins можно расширить/модифицировать/дополнить при помощи JavaScript, но киллер-фичей является поддержка Groovy (как в интерфейсе, так и в пайплайнах).
Gradle по сути Groovy, так что интеграция инструментов сборки это плюс.
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 разрабов и ты кровавый Энтерпрайз?

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

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

Добавил бы от себя:
гитлабовский "сидисиай сиди и собирай" хорош до тех пор пока ты идёшь по пути меньшего сопротивления.
Мы разрабатываем софт под Эльбрусы. И на них нет докера, нет и слава богу. НО гитлабовский сиай хоть в теории и может работать с 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 экзекутора без ранера?

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


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

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

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

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

Извините, но я согласен с 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 сейчас посмотрю, что за он.

"с плагинами могут возникать сложности" — очень мягко сказано, плагины в дженкинсе это карточный домик. С одной стороны, конечно, очень хорошо, что функциональность можно неограниченно расширять. С другой стороны, мне больше по душе гитлаб — он в этом плане довольно спартанский и вынуждает делать красиво. У меня достаточно претензий к плагинам, в частности, они выглядят как-то неконсистентно — например, в одном случае можно легко настроить билд по пушу в определенный бранч, а в другом — хрен.
Ну и ещё интерфейс Дженкинса выглядит как поделие студента. Что не добавляет удобства использования.

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


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

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

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

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

Имхо это сравнение теплого с мягким.
И 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: — ни слова =)
Only those users with full accounts are able to leave comments. Log in, please.