Зачем устанавливать последнюю версию Chrome каждый раз, когда нажимается код - gitlab-ci - PullRequest
Новая
       5

Зачем устанавливать последнюю версию Chrome каждый раз, когда нажимается код - gitlab-ci

0 голосов
/ 28 июня 2018

Я видел много примеров файлов gitlab-ci.yml, где в процессе сборки люди устанавливают последнюю версию chrome. Таким образом, это означает, что при каждом отправке в хранилище сервер загружает новую версию Chrome для запуска этого экземпляра. Например, вот что у меня сейчас в файле gitlab-ci.yml: 

# Installs Chrome
- wget -q -O — https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add - 
- echo ‘deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main’ | tee /etc/apt/sources.list.d/google-chrome.list
- apt-get update
- apt-get install google-chrome-stable -y

Зачем люди это делают? Разве это не замедлит и, возможно, не остановит ваши сборки, если многие разработчики одновременно запускают код? Почему я вижу это, а не просто загружаю chrome на сервер заранее, чтобы ваши сборки работали быстрее?

Ответы [ 2 ]

0 голосов
/ 28 июня 2018

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

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

0 голосов
/ 28 июня 2018

В свете вашего ответа на мой комментарий я могу придумать три возможных объяснения:

  • Человек, создавший gitlab-ci.yml, не думал о возможности создания своего пользовательского изображения с помощью Chrome
  • Человек, создавший gitlab-ci.yml, не знает, как создавать собственные образы Docker
  • Лицо, создавшее gitlab-ci.yml, решило, что не хочет беспокоиться о создании новой версии настраиваемого образа каждый раз, когда выпускается новая версия Chrome - возможно, потому что, по их мнению, CI - это то, что вы настраивали один раз и затем забудьте об этом, если не будет сообщений об ошибках.

Редактировать: Я не собирался обвинять кого-либо в унынии или неумелости. Позвольте мне уточнить:

  • Не думая о конкретном решении данной проблемы в данное время, автоматически не делает человека неумелым. Я уверен, что каждый по крайней мере один раз в своей жизни решает проблему каким-то образом, только чтобы потом осознать или указал на это, что есть более быстрое / лучшее / более элегантное решение и удивляться, почему они не думают об этом потому что это так очевидно. Никто не на 100% все время.
  • Не знание конкретного инструмента не делает человека неумелым. Насколько я знаю, понимание Docker не является обязательным условием использования Gitlab CI (или любого другого CI в этом отношении). Человек, настраивающий CI, может не знать об этом, если он не используется где-либо еще в проекте, и у него может не быть времени на его изучение, учитывая время, отведенное для задачи настройки CI (что обычно не делается ими, но кто-то выше в иерархии).
  • Мое последнее замечание могло бы быть сформулировано лучше, я признаю. Я имел в виду, что, по моему мнению, CI - это нечто, конфигурируемое с целью автономного запуска, если не произойдет что-то непредвиденное или внешние условия не изменятся. Например, я настроил несколько заданий Jenkins для разных проектов по обслуживанию тестовых сред. Базовый шаблон всегда один и тот же - извлекать код из репозитория, собирать его, запускать тесты, архивировать журналы в тестовой среде и, наконец, развертывать новую сборку в тестовой среде. Задание всегда настроено на отправку электронных писем в заранее определенный список людей в случае сбоя. После того, как настройка завершена, я настроил для нее какой-то триггер (таймер или веб-крючок) и забуду об этом, если только я не получу электронное письмо о сбое или изменился способ построения или развертывания проекта. Я не думаю, что это делает меня ленивым - я думаю, что это делает меня эффективным, так как у меня теперь есть больше времени для других задач - задач, которые не могут быть легко автоматизированы (если вообще).
...