Также можно использовать функцию проброса порта в современных SSHD/SSH, но эта методика не рекомендуется, так как еще довольно много устаревших SSHD, которые не поддерживают эту функцию.
Непонятно. Можно подробнее про неподдерживаемый проброс порта?
Если у них в правилах голосования указано, что не больше одного голоса с ip адреса в сутки, то да, ваши действия противоречат правилам и голоса могут обнулить. Если правил нет или в них не указано какие голоса принимаются, то понятно, что организаторам честное голосование не нужно и скорее всего сами будут накручивать.
Если сливать именно после коммита (git commit), то достаточно git хуков в локальном репозитории. Если же после push или после принятия MR, то хуки в gitlab. Ещё есть кнопка merge when build succeeds — но это наверно другая история.
По вашей ссылке сказано, что проблема из-за версий glibc и скорее всего в официальном gradle image старая версия glibc, либо проблема из-за использования alpine с его musl-libc — мы тоже на эти грабли наступили, правда в другом случае https://github.com/flant/dapp/issues/164.
Я так понял, вам было бы интересно узнать, как не перекачивать лишний раз java-артефакты или вообще чтобы скачивать только те, у которых версия изменилась? Немножко за рамками темы статьи на самом деле, но попробую ответить.
Мы в основном не используем возможности gitlab-а по сборке через docker, а используем свою утилиту dapp. В ней реализована поддержка сборки отдельных образов и копирование файлов из этих образов в финальный. На поверхности это похоже на multi stages в последних версиях docker, но есть и существенные отличия, как минимум dapp знает про git и dapp собирает образы по стадиям, что даёт возможность пересобирать только те стадии, для которых изменились указанные файлы.
Для примера в вашем случае в Dappfile будет описан отдельный образ в котором живёт gradle (можно указать, что он на основе официального gradle), куда при сборке подключится .gradle и где выполнится gradle build по исходникам.
После из этого образа скопируются указанные war, jar, ear или вся папка target в указанное место в финальном образе.
Т.к. dapp знает про git, то можно на одной стадии попросить gradle скачать свежие версии зависимостей, если изменился build.gradle (времязатратная стадия, но изменения редки, поэтому будет пересобираться не часто), а на следующей стадии gradle будет собирать проект, если изменились исходники в src.
Костылик с BUILD_ENV тоже использовали, но начиная с 8.15 появились CI_ENVIRONMENT_NAME и CI_ENVIRONMENT_SLUG.
Ну и хотел бы уточнить, как у вас происходит сборка сборочного образа? То есть в репозитории есть Dockerfile с описанием образа сборки и Dockerfile с описанием образа приложения. В какой момент и как собирается сборочный образ? Это отдельная задача в пайплайне? Как вы ставите тэг, если вдруг сборочный образ обновился? В общем интересен этот процесс.
Похоже, что нужно аккуратно ставить тэги или руками запускать сборку сборочного образа или даже менять .gitlab-ci.yml, когда изменится тэг сборочного образа. В силу объёмности нашего проекта, мы используем свою утилиту dapp для сборки и описание в двух Dockerfile не требуется, за обновлениям сборочного образа следит сам dapp. Но теперь в самом docker из коробки есть multi stages и похоже этот способ (с двумя Dockerfile) перестаёт быть актуальным. Что думаете?
Согласен, про REST API невнятно вышло. Зачем вообще он упомянут? Вот есть такой тикет https://gitlab.com/gitlab-org/gitlab-ce/issues/21911 — он про права пользователей на запуск задач, на запуск задач в определённых environment, на доступ к секретным переменным, на доступ к раннерам. Когда это будет в gitlab, то права пользователям будем выдавать в интерфейса gitlab-а и не надо будет никаких "самописных с боку систем с REST API".
Переменная GITLAB_USER_EMAIL это email того, кто запускает задачу в пайплайне, а не email последнего коммитера. Ваш вариант пригодился бы, как решение проблемы с правкой .gitlab-ci.yml, однако email последнего коммитера в общем случае не обязан совпадать с email того, кто пушит.
В достаточно большом проекте эти трёхэтажные Yaml-ы делегированы как раз devops-инженерам. А в небольшой команде обязательно кто-то будет заниматься непрофильной, но тем не менее важной деятельностью. Если разработчики начали заниматься деплоем и это отнимает их время, то почему бы не отдать devops на аутсорс, благо сейчас много кто этим занимается.
Быстрое развёртывание окружений предлагали ребята teatro, упомянутые в описании gitlab flow, но похоже они пропали куда-то. И как вариант, telepresence.io — локально работающее приложение как-будто работает в удалённом кластере, но ещё не пробовали.
Лок файлов похоже доступен только EE пользователям. .gitlab-ci.yml в отдельной ветке создаст пайплайн только для этой ветки. В двух словах: про безопасность gitlab ci есть несколько задач и возможно будет даже какое-то стандартное решение, но пока мы сделали свой патч, про это будет в следующей части.
when не подходит тем, что on_failure/on_success работает только для автоматических задач и то, только в момент, когда создаётся пайплайн. Если автоматическая задача упадёт, то следующие не запустятся, но даже, если поправить проблему и перезапустить упавшую задачу, то следующие за ней не пойдут в работу. Нам это не слишком мешает, больше мешает, что ручные задачи можно запустить когда угодно. Подробнее про все эти ограничения опять же в следующей части.
Про опциональное выполнение задач скажу так:
У нас такой потребности не возникает, потому что фронт и бэк в разных репозиториях и вообще можно сказать микросервисность, когда один фронт использует API нескольких бэков.
В статье упомянуто, что для сборки используем dapp. В вашем сценарии, когда фронт и бэк в одном репозитории, при правильно написанном Dappfile, образ фронта не будет собираться автоматически, если изменения только в исходниках бекенда.
Как вариант вместо git log можно попробовать файлы-флаги. Скрипт сборки будет проверять, скажем, что в корне репозитория есть .do-not-build-front и не запускать сборку фронта. На следующей стадии можно будет не запускать тесты для фронта. В следующей части будет с примерами, как использовать похожие файлы-флаги.
Вообще проблема условного выполнения пайплайна нами тоже ощущается, но пока что хватает названий веток/тэгов. Однако этого всё равно мало, очень хочется иметь возможность перезапустить билд с другими параметрами.
В общем хороший вопрос-то, за что минусы? Статья же висит в хабе разработки.
Про цикл разработки уже были комментарии от коллег вот в этом треде: https://habrahabr.ru/company/flant/blog/331188/#comment_10274996
С точки зрения devops-инженера всё живёт именно в gitlab — коммит в infra_*, пуш в git, выкат в своё окружение, проверка.
С точки зрения разработчика push в feature_* происходит, когда фича готова к интеграционному тестированию. То, что можно прогнать локально на среднем железе и быстро — то лучше делать локально, ведь не каждую строчку кода надо тестировать селениумом? В каждом проекте нужно приходить к некоему компромиссу — что запускать локально, какие сервисы локально разворачивать, а что проще пушнуть и потом смотреть логи в gitlab-е.
То есть часть #0 ещё более индивидуальна, чем части #1 и #2. Но тема конечно актуальная, тут сложно спорить, рано или поздно тоже статью напишем.
P.S. Есть ещё один вариант, который снимет вопросы про тесты и развёртывание окружения на локальной машине разработчика — применение web IDE.
Ну и представлять, что стрелочки можно рисовать в существенно большем количестве размерностей, нежели 2 или 3.
На пальцах скалярное произведение можно представлять как меру того, насколько один вектор похож на другой.
Секундный сэмпл — это вектор размерностью 44100.
Попробую соорудить аналогию для иллюстрации процесса:
Пусть есть две строки с пробелами и словом где-то между пробелами (пробелы ест парсер, пусть будет минус), например, s1 = "----------Slovo---"
s2 = "-------Slovo------"
Теперь примем, что строки s1 и s2 — это вектора размерностью 18, а значения координат это ASCII коды символов. Дальше из s2 получим 18 векторов с помощью циклического сдвига: s [0] = "-------Slovo------"
s [1] = "--------Slovo-----"
s [2] = "---------Slovo----"
s [3] = "----------Slovo---"
s [4] = "-----------Slovo--"
...
s [8] = "vo-------------Slo"
...
s[17] = "------Slovo-------"
s[18] = "-------Slovo------" == s[0]
Теперь остаётся подсчитать 18 раз скалярное произведение строки s1 с каждым из полученных векторов и запомнить тот вектор и его индекс, где будет наибольшее скалярное произведение. Полученный индекс будет сдвигом «Slovo» в строке s2 относительно строки s1.
Для массового производства слишком сложно. Хим процессы в больших ваннах проще и дешевле.
А для хобби есть вот такой проект печаталки проводящими чернилами (и как бонус — тот же станок может сверлить и наносить надписи): www.kickstarter.com/projects/voltera/voltera-your-circuit-board-prototyping-machine
Эх, вот бы они на годик раньше компанию стартанули, а не в начале 2015, когда $1200 оказались конским ценником даже для хобби, на которое вроде как ничего не жалко ;]
На скорости 1.5х нормально было смотреть.
Непонятно. Можно подробнее про неподдерживаемый проброс порта?
Если сливать именно после коммита (git commit), то достаточно git хуков в локальном репозитории. Если же после push или после принятия MR, то хуки в gitlab. Ещё есть кнопка merge when build succeeds — но это наверно другая история.
Если используется директива image: то команды будут запускаться через указанный там образ. И вот в этом образе может не быть команды git.
По вашей ссылке сказано, что проблема из-за версий glibc и скорее всего в официальном gradle image старая версия glibc, либо проблема из-за использования alpine с его musl-libc — мы тоже на эти грабли наступили, правда в другом случае https://github.com/flant/dapp/issues/164.
Я так понял, вам было бы интересно узнать, как не перекачивать лишний раз java-артефакты или вообще чтобы скачивать только те, у которых версия изменилась? Немножко за рамками темы статьи на самом деле, но попробую ответить.
Мы в основном не используем возможности gitlab-а по сборке через docker, а используем свою утилиту dapp. В ней реализована поддержка сборки отдельных образов и копирование файлов из этих образов в финальный. На поверхности это похоже на multi stages в последних версиях docker, но есть и существенные отличия, как минимум dapp знает про git и dapp собирает образы по стадиям, что даёт возможность пересобирать только те стадии, для которых изменились указанные файлы.
Для примера в вашем случае в Dappfile будет описан отдельный образ в котором живёт gradle (можно указать, что он на основе официального gradle), куда при сборке подключится .gradle и где выполнится gradle build по исходникам.
После из этого образа скопируются указанные war, jar, ear или вся папка target в указанное место в финальном образе.
Т.к. dapp знает про git, то можно на одной стадии попросить gradle скачать свежие версии зависимостей, если изменился build.gradle (времязатратная стадия, но изменения редки, поэтому будет пересобираться не часто), а на следующей стадии gradle будет собирать проект, если изменились исходники в src.
Костылик с
BUILD_ENVтоже использовали, но начиная с 8.15 появилисьCI_ENVIRONMENT_NAMEиCI_ENVIRONMENT_SLUG.Ну и хотел бы уточнить, как у вас происходит сборка сборочного образа? То есть в репозитории есть Dockerfile с описанием образа сборки и Dockerfile с описанием образа приложения. В какой момент и как собирается сборочный образ? Это отдельная задача в пайплайне? Как вы ставите тэг, если вдруг сборочный образ обновился? В общем интересен этот процесс.
Похоже, что нужно аккуратно ставить тэги или руками запускать сборку сборочного образа или даже менять .gitlab-ci.yml, когда изменится тэг сборочного образа. В силу объёмности нашего проекта, мы используем свою утилиту dapp для сборки и описание в двух Dockerfile не требуется, за обновлениям сборочного образа следит сам dapp. Но теперь в самом docker из коробки есть multi stages и похоже этот способ (с двумя Dockerfile) перестаёт быть актуальным. Что думаете?
Согласен, про REST API невнятно вышло. Зачем вообще он упомянут? Вот есть такой тикет https://gitlab.com/gitlab-org/gitlab-ce/issues/21911 — он про права пользователей на запуск задач, на запуск задач в определённых environment, на доступ к секретным переменным, на доступ к раннерам. Когда это будет в gitlab, то права пользователям будем выдавать в интерфейса gitlab-а и не надо будет никаких "самописных с боку систем с REST API".
Переменная GITLAB_USER_EMAIL это email того, кто запускает задачу в пайплайне, а не email последнего коммитера. Ваш вариант пригодился бы, как решение проблемы с правкой .gitlab-ci.yml, однако email последнего коммитера в общем случае не обязан совпадать с email того, кто пушит.
В достаточно большом проекте эти трёхэтажные Yaml-ы делегированы как раз devops-инженерам. А в небольшой команде обязательно кто-то будет заниматься непрофильной, но тем не менее важной деятельностью. Если разработчики начали заниматься деплоем и это отнимает их время, то почему бы не отдать devops на аутсорс, благо сейчас много кто этим занимается.
Быстрое развёртывание окружений предлагали ребята teatro, упомянутые в описании gitlab flow, но похоже они пропали куда-то. И как вариант, telepresence.io — локально работающее приложение как-будто работает в удалённом кластере, но ещё не пробовали.
Лок файлов похоже доступен только EE пользователям. .gitlab-ci.yml в отдельной ветке создаст пайплайн только для этой ветки. В двух словах: про безопасность gitlab ci есть несколько задач и возможно будет даже какое-то стандартное решение, но пока мы сделали свой патч, про это будет в следующей части.
when не подходит тем, что on_failure/on_success работает только для автоматических задач и то, только в момент, когда создаётся пайплайн. Если автоматическая задача упадёт, то следующие не запустятся, но даже, если поправить проблему и перезапустить упавшую задачу, то следующие за ней не пойдут в работу. Нам это не слишком мешает, больше мешает, что ручные задачи можно запустить когда угодно. Подробнее про все эти ограничения опять же в следующей части.
Про опциональное выполнение задач скажу так:
Про цикл разработки уже были комментарии от коллег вот в этом треде: https://habrahabr.ru/company/flant/blog/331188/#comment_10274996
С точки зрения devops-инженера всё живёт именно в gitlab — коммит в infra_*, пуш в git, выкат в своё окружение, проверка.
С точки зрения разработчика push в feature_* происходит, когда фича готова к интеграционному тестированию. То, что можно прогнать локально на среднем железе и быстро — то лучше делать локально, ведь не каждую строчку кода надо тестировать селениумом? В каждом проекте нужно приходить к некоему компромиссу — что запускать локально, какие сервисы локально разворачивать, а что проще пушнуть и потом смотреть логи в gitlab-е.
То есть часть #0 ещё более индивидуальна, чем части #1 и #2. Но тема конечно актуальная, тут сложно спорить, рано или поздно тоже статью напишем.
P.S. Есть ещё один вариант, который снимет вопросы про тесты и развёртывание окружения на локальной машине разработчика — применение web IDE.
Секундный сэмпл — это вектор размерностью 44100.
Попробую соорудить аналогию для иллюстрации процесса:
Пусть есть две строки с пробелами и словом где-то между пробелами (пробелы ест парсер, пусть будет минус), например,
s1 = "----------Slovo---"
s2 = "-------Slovo------"
Теперь примем, что строки s1 и s2 — это вектора размерностью 18, а значения координат это ASCII коды символов. Дальше из s2 получим 18 векторов с помощью циклического сдвига:
s [0] = "-------Slovo------"
s [1] = "--------Slovo-----"
s [2] = "---------Slovo----"
s [3] = "----------Slovo---"
s [4] = "-----------Slovo--"
...
s [8] = "vo-------------Slo"
...
s[17] = "------Slovo-------"
s[18] = "-------Slovo------" == s[0]
Теперь остаётся подсчитать 18 раз скалярное произведение строки s1 с каждым из полученных векторов и запомнить тот вектор и его индекс, где будет наибольшее скалярное произведение. Полученный индекс будет сдвигом «Slovo» в строке s2 относительно строки s1.
W.Schwarze получил значение 338,6⋅10-6 кал/см⋅сек⋅град при 0°С что в СИ примерно равно 0,1418 Вт/м⋅К и примерно соответствует современному значению. Теплопроводность воздуха принималась тогда 58,3⋅10-6 кал/см⋅сек⋅град при 0°С.
А для хобби есть вот такой проект печаталки проводящими чернилами (и как бонус — тот же станок может сверлить и наносить надписи): www.kickstarter.com/projects/voltera/voltera-your-circuit-board-prototyping-machine
Эх, вот бы они на годик раньше компанию стартанули, а не в начале 2015, когда $1200 оказались конским ценником даже для хобби, на которое вроде как ничего не жалко ;]
А можете привести примеры вопросов, которые задают уже не junior, а senior-ам на собеседованиях? Чтобы было куда стремиться дальше.